Transcript Open Source Development Processes: Suitable for Mission

Open Source
Development Processes
Open Source Development Process
“Open Source Software Development, which relies
on collective community action by enthusiasts,
will inevitably take over from proprietary software
development as the dominant business model”
-- Jackie Fenn, Gartner Fellow,
Emerging Technologies Team
Open Source Perceptions
IF YOU HAD THE OPTION OF PAYING FOR
SOMETHING VERSUS GETTING IT FOR FREE,
WHICH WOULD YOU CHOOSE?
PERCEPTION: If you pay for something it is better
REALITY:
 The person(s) motivated to make it better will make it
better
 What is more motivating - gainful employment or a
passion for changing the world?
Open Source Perceptions
WHO IS THE CUSTOMER FOR A HOBBYIST?
PERCEPTION: Open Source is a hobby
 All FOSS is written by two guys of questionable
hygiene who have lived in a garage eating pizza and
soda for the past 3 years
REALITY:
 OSS is a licensing term distinct from the OS
Development Process (OSDP)
 Plenty of commercial vendors do OSS
Open Source Perceptions
WHEN IS FREE NOT REALLY FREE?
PERCEPTION: Open Source Software is FREE
REALITY:
 TCO: how much does it cost to maintain?
• How long will those two guys in a garage stick around?
• Any longer than a vendor would?
Counter Argument: R. Leftkowitz (blogger r0ml)
 Why would you want the source?
• Providers can’t get it right so you need it?
 Who do you trust with modifications anyway?
• People who wrote it or people who never saw it before (YOU?!)
Open Source Perceptions
DID AL GORE CREATE
OPEN SOURCE?
PERCEPTION:
 It seems everyone is claiming
to be a true believer
REALITY:
 OS hype depends on the market
 OSS one of the Top 10
• It is established in enterprise computing technologies to watch in 2007
• Less so in other domains
 80% of commercial software will
 As OS plateaus, confusion arises:
include OSS by 2012
• More vendors glom on to the term
• Proliferation of licensing models
Open Source Perceptions
CAN YOU REALLY MAKE MONEY WITH THIS STUFF?
PERCEPTION:
 You cannot resell or repackage FOSS in your products without
making yours OS
• FOSS Licensing is a cross between an expression of commercial
concerns and developer religion.
REALITY:
 OSI now lists 65 licenses, up from about 31 in 2006.
• Models range from “GPL” to “LGPL” to “BSD” to “dual”
• Many variations exist due to IP and commercialization issues
– EXAMPLE: GPLv3
» GPL is the most viral flavor of OS license
» Microsoft-Novell signed an agreement 11/06 saying each will not claim
patent infringement on the other (Windows & SUSE Linux)
» FSF responded by making DRAFT 3 include specific clauses that say you
must extend such protections to all!
Open Source Perceptions
IS OPEN SOURCE SOFTWARE REALLY SUITABLE
FOR MISSION CRITICAL APPLICATIONS?
PERCEPTION: Open Source is only for non
“Mission Critical” Applications
 Users are getting accustomed to “just good enough”
 Mission critical means “zero tolerance” for failures
REALITY:
 Agile methods (which most OSS project adopt) focus
on injecting quality in the Development phase
 Every other software process methodology focuses
on everything BUT writing the source code!
Open Source Software Development
“Open Source” is a polymorphic term
 Refers to a distribution model for source code
 Refers to how software is licensed
 ..and also refers to a development process
Open Source as a Development Process
 Has its roots in Agile methods
• Code first
• People first
 …with some unique properties
• Developers are typically distributed
• Customer is “around” you, does not “live” with you
– Community versus communal
Open Source Development Process
1. Developers are typically distributed
 Wiki documentation becomes more important
 Good CM becomes absolutely crucial
•
•


You cannot just “go to the cube next door” to resolve issues
Dual-licensing models exacerbate this issue
You have to have more courage to do your
Refactoring and Code Reviews
Tool support is even more important
•
Another communication vehicle
Open Source Development Process
2. Customer is “around” you, does not “live” with you
 Product roadmap is critical
•
•

OSDP needs to be a little more paranoid than Agile
•

Although change happens, you need to define your scope
boundaries up front
Burden to please community can result in poor direction -->
feature and architectural drift
You may need to be a bit more defensive when integrating OS to
protect yourself from constant change
A part of Professional Responsibility is realizing that an
OS community may depend on you
•
This has been an issue for many OS projects, why?
– NOT because the developers lack professionalism in their code
– Professionalism means accountability --> for the documentation,
deployability, quality, and release cycles
•
Do not over-promise and under-deliver, even in OS!
OSDP Code Management
How/Who maintains the code?
 “Earn-as-you-go” style of contribution.
• Prove yourself to the community, earn “guru” status, and then
you can commit more code.
 Other open source projects have the “keys” to the
source repository held tightly by a small group.
• Commercial vendors often do this for their OS products
• Consortia often do this
Examples:
 Eclipse - consortia-driven with roadmap and projects
 ITK - New algorithms approved through a paper peer
review process including source code and data
 IGSTK - evolving; but for now the core components are
controlled while applications may be contributed
OS Anatomy
Know the anatomy of your open source releases
 More OS projects now give you OTS architecture not
just an OTS library
• Implications for integration and dependencies much higher
• Expected value is much higher
 Know who controls which parts of an “uber” project
• Open source releases often support areas for community
contributions (“contrib”, “plugin”, “project” etc.) that are
managed in a separate repository under different policies
Examples
 Eclipse kernel/workbench versus Eclipse plugins
 Postgres contrib features
 IGSTK core components versus applications/tools
OSDP Pros and Cons
OSDP / Agile Method Pros:





Focus on injecting quality as the code is being built
People-centric, and in OSS, community-centric
Emphasis on current Best Practices
Embraces change
The process, architecture and code are transparent
Cons:
 Relies on skilled & experienced developers
• Are successful XP projects successful because of the talent
level of the people, not for the process?
 Frustrating model for stakeholders
• Stakeholders want quality, cost, and schedule promises
 Frequently poor support for transition activities
• Deployment, Documentation, and Migration can be frustrating