The Open Source Development Model: Overview, Benefits and Recommendations

Dr. Ibrahim Haddad

 

The open source development model has unique characteristics that position it in some instances as a more superior model to develop software when compared to the traditional software engineering cascade model. In this article, Dr. Ibrahim Haddad presents an overview of the open source development model, its benefits and recommended practices.

Overview

Open source software development model has different processes and set of values from traditional proprietary software development model. The traditional software development process consists of six activities, illustrates in Figure 1: collecting and analyzing requirements, design a solution approach, develop the code, test, deploy and maintain. After each step is finished, the process proceeds to the next step.

 
 

 

 

 

 


Figure 1: Cascade Model of Traditional Software Engineering

 

The open source development model has key differences when compared to the traditional model of developing software (collect requirements, design, implement, test, release, and maintain).

 

The open source development model, illustrated in Figure 2, starts with an idea for a new project, a new functionality or capability to an existing open source software component. Next step is to provide a design for the implementation and then a prototype of the capability and translate it from an idea into running software. At the moment the software runs, it is released as development release, even though it may contain known and unknown bugs. This follows the spirit of release early and release often.

 

The software will be tested by the community who discuss the software through mailing lists and discussion boards and provide feedback, bug reports, and fixes through the project mailing list. The feedback is recorded and taken into consideration by project members and maintainers to improve the implementation and then a new development release will be available. This cycle happens as many times as needed until project members feel that the implementation is stable enough. When the implementation is released as stable, the development cycle continues to happen with the development release (also called development tree) until a newer stable release is available.

 

 
 

 

 

 

 

 

 


Figure 2: Open source development model

(Source: Bill Weinberg, Open Source Development Labs, 2006)

 

Some of the unique characteristics of the open source development model include:

 

·         Bottom up development: Project members who do the most work get the most say when it comes to making design and implementation decisions. Those that do the most work get the most say. Relationships between developers are very important

 

·         “Release early, release often”: Don’t wait to have a fully working version to make the code public and release a version of the software. This release philosophy allows for peer review, where all members of the community can comment and offer suggestions and bug fixes. It also allows having small incremental changes that are easier to understand and test. Open source projects tend to make a release available early to be used by the user community and then quickly update the releases as the software is modified. This practice is described as “release early, release often”. The open source community believes that this practice leads to higher-quality software because of peer review and the large base of users who are using and testing the software, accessing the source code, reporting bugs, and contributing fixes. A side benefit of having many people looking at the code is that the code is reviewed for adherence to coding style; fragile or inflexible code can also be improved because of these reviews.

 

·         Peer Review: Members of the open source project review the code, provide comments and feedback to improve the quality and functionality, and do early test to catch bugs and provide enhancements as early as possible in the development cycle. The result is an improved, high quality code.

 

·         Small, Incremental changes: In open source project development, often additional features are small and non intrusive for good reasons:

–        It is easier to understand small patches and code changes than making a large change in the code or a big architectural re-design.

–        The small changes are important because its helps focusing the testing phase which is cyclical and ongoing with every increment of the software.

–        A small change is less like to have unintended consequences.

 

·         Features that ignore security concerns are flagged: The open source community takes security very seriously and any development or capability that jeopardizes the security of the software is flagged and not included in the software until the security concern is dealt with.

 

·         Continuous quality improvement: This is due to the extensive peer review and quick bug fixes

 

·         Test projects: In many cases, test projects are created for large open source projects to create test suites and automate testing.

 

·         End user involvement in the entire process: In Figure 2, we notice that the users are actually involved in all the phases of development in the open source model.

Benefits of Adopting Open Source Working Methods

There are several open source development practices that corporate can benefit from adopting within their development environment that can lead to improvement in quality of code, communication, effectiveness and performance.

 

•         Using open development methods “ΰ la sourceforge”

–        Open source code tree: Make source code available for others to review and offer feedback and suggest improvements (peer review). Inside a company, this allows teams to works across organizational lines and allows others to add value to your software. Different users tickle different bugs, leading to higher quality. The practice of incrementally adding functions allows better testing and better chances to capture bugs. Cooperation is good and benefits all.

–        Open mailing list used for all project related discussions

–        Bug tracking system

–        Technical support tracking system

–        Patch tracking system

–        Feature request tracking system

 

•         Fast development cycle with small incremental changes

–        Adopt the “release early and release often” practice

–        Go through the cycle several times

–        Apply small incremental changes in the release to make it easier to understand and test

–        Faster development builds 

–        Lower Time to market     

•         Pay special attention to quality and security

 

•         Encourage re-use

–        Promote and encourage company developers to use Open Source software and tools in their development environment where it can meet their needs

–        Include Open Source software in products based on a set of criteria such as technical merits, the time-to-market advantage, and avoiding vendor lock-in situation

–        Code re-use improves Efficiency and increases cost savings

•         Build reusable software components

–        Don’t keep re-inventing the wheel and don’t act superior. If someone has already implemented the capability or feature you need, use it and build on top of it.

–        When you develop from scratch, keep reusing in mind and develop code in modules that can be used by others and by you for other situations without many modifications.

•         Respect and follow community coding style

–        The open source community follows a strict coding style to make it easier to understand the code, review it and revise it quickly.

•         Flag problems early and review with team

–        Hiding problems or bugs until you come up with a solution is not encouraged.

–        It is advised to report bugs or problems as early as they occur and the community will help you come up with a workaround or propose and help implement a better solution

–        Openness and honesty is key

·         Foster innovation

–        New ideas have a better chance if engineers have the source code to review and experiment with and build proof-of-concept and test different methods.

 

Closing

The open source development model has proved to be a successful model that allows faster development, faster testing, higher innovation, peer review, openness and transparency. Table 1 present the recommended best practices to adopt from the open source development model that allows best leverage as you incorporate these practices into your own development model.

 

 

Recommended Practices

Description

Increase team communication

 

Using mailing lists, chat software, wiki

 

End-user feedback

Involve the end-user to get feedback as you proceed

 

 

Peer review

Encourage peer review and provide an environment that welcomes feedback and suggestions

 

Release early and often

Adopt the release early and release often development practice for the many benefits it offers as compared to the traditional release model, and follow the model of continuous integration and automated test environments.

Transparency

Adopt transparency and openness through using open source code tree, bug tracking database, and mailing lists that are open within the whole company.

 

Good code designs

Build a minimal code base and add all functionalities and capabilities as separate modules to encourage reuse and ensure easier testing.

 

Table 1: Recommended best practices from the open source development model

In a follow-up article, we will discuss the differences in terms of culture, communication, and project hierarchy between open source projects and internal projects. Stay tuned.

About the author

Dr. Ibrahim Haddad is currently Director of Technology Portfolio Management at Motorola. Prior to Motorola, Dr. Haddad managed the Carrier Grade Linux and Mobile Linux Initiatives at the Open Source Development Lab (OSDL) which included promoting the development and adoption of Linux and Open Source software in the communications industry. He is the co-author of two books on Red Hat Linux and Fedora, a contributing editor of the Linux Journal, Linux Planet and Enterprise Open Source Magazine, and a featured speaker and panelist at industry conferences. He received his B.Sc. and M.Sc. in Computer Science from the Lebanese American University, and his Ph.D. in Computer Science from Concordia University in Montreal, Canada.