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

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

3. Open Source Overview What is Open Source?
Open Source Initiative ( 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

4. 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)
DoD – 2003 CIO memo
DHS – Science and Technology Directorate grants –
HHS – caBIG – 2004
Many more

5. Open Source Growth Number of Projects Lines of Code
Source: Deshpande, Amit; Riehle, Dirk – The Total Growth of Open Source-

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

7. 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

8. 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

9. 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.

10. 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!

11. 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

12. 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

13. 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

14. 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

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

16. 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

17. 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

18. 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

19. 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

20. References
CDC Open Source Policy –
Flashline Pattern Book for Open Source in the Enterprise (no longer online, for distributable copy under Creative Commons License)
Cathedral and the Bazaar by Eric Steven Raymond –
Code by Lawrence Lessig –
Open source project respositories: ;

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