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: Dont 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
Dont keep re-inventing the wheel and dont 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