Open Source Development Processes

Open Source Development Process -- Jackie Fenn, Gartner Fellow, Emerging Technologies Team “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”

Open Source Perceptions 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? PERCEPTION: If you pay for something it is better IF YOU HAD THE OPTION OF PAYING FOR SOMETHING VERSUS GETTING IT FOR FREE, WHICH WOULD YOU CHOOSE?

Open Source Perceptions REALITY:  OSS is a licensing term distinct from the OS Development Process (OSDP)  Plenty of commercial vendors do OSS 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

Open Source Perceptions 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? PERCEPTION: Open Source Software is FREE WHEN IS FREE NOT REALLY FREE? 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 REALITY:  OS hype depends on the market It is established in enterprise computing Less so in other domains  As OS plateaus, confusion arises: More vendors glom on to the term Proliferation of licensing models PERCEPTION:  It seems everyone is claiming to be a true believer DID AL GORE CREATE OPEN SOURCE?  OSS one of the Top 10 technologies to watch in 2007  80% of commercial software will include OSS by 2012

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 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 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! 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 IS OPEN SOURCE SOFTWARE REALLY SUITABLE FOR MISSION CRITICAL APPLICATIONS?

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 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  OSDP needs to be a little more paranoid than Agile 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