The open source development model has unique characteristics that make it in some instances a superior model for developing software compared to the traditional software engineering cascade model. As with other practices, the open source development model had its advantages and inconveniences. Will adopting the open source development model improve the way your corporate developers work and produce software? What are the best practices from the open source development model that we can use in a corporate environment?

The open source software development model has a different process and set of values than traditional proprietary software development model. The traditional software development process consists of six activities illustrated in Figure 1: collecting and analyzing requirements, designing a solution approach, developing the code, testing, deploying, and maintaining. After each step is finished, the process proceeds to the next step.

The open source development model has key differences 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 the idea for a new project, a new functionality or capability for an existing open source software component. The 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's released as a 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, which discusses 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 repeats as often as needed until project members feel the implementation is stable enough. When the implementation is released as stable, the development cycle continues with the development release (also called the development tree) until a newer stable release is available.

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 who 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. This release philosophy allows for peer review, where all members of the community can comment and offer suggestions and bug fixes. It also allows for 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 update the release 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 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 test to catch bugs and provide enhancements as early as possible in the development cycle. The result is high-quality code.
• Small incremental changes: In open source project development, additional features are often small and non-intrusive and for good reason:
  - It's easier to understand small patches and code changes than big changes in the code or big architectural redesigns.
  - The small changes are important because they help focus 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 involved in all phases of development in the open source model.