Critical Success Factors for Adoption of Open Source Mike Perry, MSICS, CDC Brian Alexander Lee, BearingPoint

Agenda Open Source Overview Community Composition Licensing Project Governance & Change Control Case: CDC Open Source Policy

Open Source Overview What is Open Source? Open Source Initiative (http://www.opensource.org/docs/osd) defines 10 characteristics Free redistribution of runtime Availability of program source code Must allow derived works +7 more characteristics 72 different license versions certified by OSI that range from A-Z: Academic Free License to Zope Public License, but generally fall into these categories: Viral Requires that other projects be open source Non-viral Allows any usage Somewhere in between Allows limited usage by non-open source projects Free Redistribution Source Code Derived Works Integrity of Author’s Source Code No Discrimination Against Persons or Groups No Discrimination Against Fields of Endeavor Distribution of License License Must Not Be Specific to a Product License Must Not Restrict Other Software License Must be Technology Neutral (from A-Z: Academic Free License to Zope Public License

Open Source Overview It is not new It is not even new to government 1960/70s – ARPANET RFC (building blocks of the internet) 1980s – GNU Project (used extensively within Unix environments) 1990s – Linux, Apache, MySQL 15th anniversary of Debian Linux Apache is most widely used web server (49 of top 100 web sites) MySQL database bought for $1 billion It is not even new to government NSA – Security-Enhanced Linux (SELinux) - 2001 DoD – 2003 CIO memo DHS – Science and Technology Directorate grants – 2006-2008 HHS – caBIG – 2004 Many more

Open Source Growth Number of Projects Lines of Code Source: Deshpande, Amit; Riehle, Dirk – The Total Growth of Open Source- http://riehle.org/2008/03/14/the-total-growth-of-open-source/

Open Source Overview Benefits Negatives Costs savings Increased Quality Increased Security Increased Community Negatives New methods for support Culture Change

Open Source Key Principles Transparency All activities are open Discoverability All project output is described and made available Communication Everything is communicated in both directions Discoverability Communication Transparency

Community In open source software the community “owns” the software & process Usually seeded by an organization Non-profit Government agency Donated by commercial entity But becomes self-selecting Each project determines its own development methodology and rules of behavior

Typical Community Structure Steering Steering Committee Creates projects and guides community Project Management Committee Guides a specific project Committer Reviews and accept changes Contributor Proposes changes and/or volunteers time User Uses project(s) User User Committer Contributor User Individuals can belong to more than one group.

Community Collaboration Portal Provides a virtual workspace, meeting room, bulletin board, etc. Typical platforms include Plone (open source) – Community GForge (open source) – Software Development SharePoint (Microsoft) Many agencies already have one or more Portal servers: Leverage the existing infrastructure! Access for stakeholders, public may be appropriate This is a good place to collect stakeholder feedback!

Legal & Policy Determines license Determines support Selects applicable license for agency/state/city/etc Non-viral (BSD, MIT, Apache, Eclipse) Viral (GPL, Lesser GPL, Affero GPL) For example, caBIG developed new license through NIH to extend the BSD license with requirements specific to NIH Determines support 3rd party partnership Community designation

Governance Guide vs. Control In open source projects, participation is voluntary (but funding helps) so governance must guide the community rather than control it (because members all vote with their feet) So governance has different duties Establishes vision Creates/merges/destroys projects Picks a development model and licensing model Identifies requirements Governs community assets (mailing list, forum, web site, etc.) Works with other projects & organizations to design architecture Trust must be developed within the community

Organizational Composition Governance Organizational Composition Who participates in governance? Everyone can attend and view minutes. Only committee members can vote. Initially established by founding organization New members elected by governance committee

Responsible for interoperability Governance Responsible for interoperability Governance proposes vision and architecture to allow project(s) to interoperate with related projects Decides on level of interoperability – Syntactic + Semantic Governance monitors (or appoints someone within the community to monitor) existing and emerging standards Establishes change control procedures Defines the processes and procedures for changing project software Proposal Submission Review Inclusion in project

Example Change Control Process User Suggest Change Contributor Contribute change code Project Committee Review change Committer Functional Test Security Review Add change to project

CDC Open Source Policy If you are going to produce open source software, you need to make sure that it will be acceptable in your own IT environment There are also other business-based justifications for OSS We needed a comprehensive policy to govern how open source products can be used within CDC Developed by Enterprise Architecture, collaborating with relevant stakeholders for review: Information Technology Services Office (ITSO) – IT Infrastructure Office of the Chief Information Security Officer (OCISO) – Security Management Analysis and Services Office – Policy Office of the Chief Information Security Officer

CDC Open Source Policy: Development and Approval Enterprise Architecture Initial Draft ITSO IT Review OCISO Security Review MASO Contract Language CIO Approval Release Signed 08/29/2007 Entire Process Took 12 Months

CDC Open Source Policy Policy states that open source software will be treated with the same controls and procedures as COTS, GOTS, and Internally Developed software. Specifically: Comply with CDC/HHS architecture, IT, policies and standards Comply with federal rules and laws Comply with NIST Special Publications Meet CDC security policies OCISO/ITSO agreement for common configuration Must have vendor support for updates and revisions

Conclusion Successful open source projects require: Trusted project governance that understands the goals and vision of the organization A strong, active community that is able to carry out the vision Tools that will facilitate active communication and collaboration Appropriate licensing that allows participation in the community and use of software by stakeholders Successful open source policies require: Collaboratively developed rules & regulations Up-to-date, accessible catalog of approved-for-use open source projects and products Executive and line management buy-in, awareness and support

References CDC Open Source Policy – http://aops-mas-iis.cdc.gov/Policy/Doc/policy521.pdf Flashline Pattern Book for Open Source in the Enterprise (no longer online, email for distributable copy under Creative Commons License) Cathedral and the Bazaar by Eric Steven Raymond – http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar Code by Lawrence Lessig – http://codebook.jot.com/Book Open source project respositories: http://sourceforge.net ; http://www.google.com/codesearch

Questions? Contact Mike Perry – MPerry@cdc.gov Brian Alexander Lee – BALee@cdc.gov