Roles in Open Source
Following my presentations about motivation and success in open source, comes a new one about the roles and life cycle in open source software development. Before going into details, I would like to thank Laura and Razvan for arranging this.
I have to say that I was pleasantly surprised, that the students have at least basic theoretical understanding about the software development process and roles involved. I will describe briefly the steps in this process. Please keep in mind that these steps should appear no matter what development methodologies you are using (waterfall, iterative etc), but they can differ in length or importance. The important part is the outcome, any of these steps can be viewed as a black-box that, given an input generates an output.
- Initiation. The first phase of a project after which we will end up having in our hands, the IDEA, or more formally a short description of the project. As opposed to a commercial product, where this comes usually from a business need or a client request, in open source, more often this will be (hopefully) an innovative idea. The owner here is the initator. If this comes from an internal business need, it can be called sponsor or from an external request, client.
- Economical analysis. Having the idea, a market research and/or feasibility study will follow. Intentionally, I used “economical” instead of “financial”, because unlike commercial products where profit is the main criteria, here other success criteria can be investigated and considered. This phase will answer to the question: “Should we start the project?”. The one that creates the documentation containing all the information for answering such a question here is the economical/financial analyst, but the initiator will give the final answer.
- Planning. And the answer is “Yes”, we have a project. The project manager will create the project plan, assemble the team, establish initial timelines. Its role starts here and it will continue throughout the entire project life, driving progress through all the other steps. In open source projects, it is harder to assemble a team and have a strict timeline. That is why the project manager role is ignored. Wrong. In an open source project, a PM has its value and in my opinion is the one of keeping the FOCUS and moving forward. With a clear mission in mind and keeping track of the current activities, he can discard undesirable actions that will make the project go on a side track and the team lose the focus and interest.
A higher overview role here is the product manager.
- Business analysis. Starting with the short description from the first phase, business analysts will conduct sessions where subject matter experts are involved and will gather the functional requirements. These can be formal documents or user stories like in agile development. Subject matter experts are usually non-technical persons that can offer valuable information about the domain of the application. E.g. in a medical software, the medical personnel can assume this role here.
Unfortunately, this role is usually overlooked in open source applications. That is happening because technical people like to start getting the job done and minimum knowledge is considered enough. Another reason is that SMEs think that, if being non-technical, they cannot involve in open source software applications.
- User interface design. There are lots of products that assured their success with a friendly user interface. Do you think a psychologist cannot find his place in the open source software world? Think again and your project could be a hit.
Of course, if you’re developing a SDK you may want to skip this step.
The output of this step will go into the functional requirements.
- Architecture. So far we haven’t been technical. Now it is time. The architects will use the functional requirements to create the technical specifications. These will define the entire system, infrastructure, technologies involved etc. Usually the architect role is assumed by a senior developer. Nothing wrong with that, but on a bigger project you may want at least a second opinion. By architect I refer to all kinds: solution, database, network etc
- Development. Finally at work🙂. Using functional and technical specifications, the developers will do their magic and transform them into a working application. Besides developers, we can have here working together web/graphic/media designers. Maybe now it is a good time to mention another role: functional manager. A bigger team, usually homogeneous, will also need a lead. His responsibilities will be to split the tasks to a finer granularity, provide guidance, be a reporting entry point etc. This is not only applicable to a team of developers, but could extend to teams of architects, project managers, business analysts etc. In open source projects moving to such a position will have as ground, meritocracy criteria, such as involvement in the project and knowledge.
- Quality assurance. An undesirable and hated step, maybe because it is done by the wrong people, the developers. The ones that will probably repeat the same mistake from the development phase during this phase too. That’s when testers are coming to the rescue. But the ones that really put things in order here are the test case writers. Having a test case for your application will save you of many headaches: it will ensure that you will not miss testing a feature, testing can be assigned to lower qualified personnel, bug reporting becomes easier and the list can go on.
Even though this step is described after development, it can start even before architecture. Test cases can be done using as input the functional requirements. Running the tests tough will happen after development. But even this can be modularized and parallelized.
This is the paradigm of Test Driven Development, even tough that refers more to unit testing.
- Implementation. In this phase we are talking about documentation, advertising and distribution. We have a final product and we deliver it to the customer.
Documentation. It refers to user manuals, tutorials, demos. It is not the technical documentation created during development phase. The content is created by documentation/content writers, but the presentation is made by (graphic/media) designers.
Advertising. An important factor in the success of every project, open source or commercial. In open source, innovative low-budget ways of promoting must be find and implemented. Viral is one of the key words here.
Distribution. It includes different aspects depending on the nature of the application: packaging, installation, infrastructure. Documentation also plays an important role here.
Don’t forget about sales. What? Sales in Open Source? Yes. Many business models are built on top of open source products. Either you offer paid support or enhancement development, you need the right people/skills to move the project forward.
- Maintenance. This is an ongoing phase and many projects were successfully because they mastered this step. Responsiveness is a must, I would say. Either we’re talking about bug fixing or technical support. Fortunately there are a lot of online tools that can make our life easier. Selecting the right one for you and your users, is not always the easiest thing.
- Finalization. Or in other words, retirement. A question is usually rising: “Do we really need this?”. Yes. If a project becomes obsolete, don’t just ignore it. State this in the official documentation and point to an alternative. It will make your users happier and save your community.
See how many skills are involved in creating a successful software system? Everyone can volunteer and find their place in the wonderful world of open source. It’s up to you to contribute and spread the word.