As the community manger for two different open source projects, I have witnessed first hand two development methodologies that are dissimilar. In this week’s blog post, I detail the two methodologies and look to you, the reader, for ideas on other methodologies or ways that these processes can scale or be improved. For those of you looking for a more general open source blog post, you may want to pass on today’s article. I have chosen to call the two methodologies based on existing well-known open source communities that follow the specific process. The name chosen is not a comment on those communities, but merely a way to categorize the processes.Ubuntu Developer Methodology Linux Developer Methodology Both of these methodologies are used successfully in open source and are able to scale to meet the challenges within a community. However, I have been thinking that there may be other ways to handle development processes and am interested in learning about other ideas that have been tried? I am also looking to find ways to tweak these models to better serve the development community especially at a massive scale. I am looking forward to reading your feedback this week.Finally, I am taking a week off for vacation and will not be posting next Wed. I will return on the 23rd.
Developers following this process submit Blueprints into an online system detailing a feature they plant to create along with information on the design. Community members are able to comment on the Blueprint and provide feedback on the idea as well as design. A team or individual community member approves the Blueprint and the developer then writes the code. Using the Blueprint online system, the community is able to monitor status of the feature as it is written, made available for code review and test. Once a Blueprint finishes the development lifecycle it is then added to the main code tree.
Developers in this process submit their feature idea directly to the community and a known gatekeeper who is responsible for allowing code into a specific portion of the project. They can choose to discuss their design idea or simply create the code and send to the gatekeeper for acceptance. The gatekeeper can leverage the wider community or simply accept or decline the feature. In this methodology, the gatekeeper has the final say and is not usually over-ruled.