1. Community Development at the
Apache Software Foundation
BOSC 2010, Boston, July 2010
Open Bioinformatics Foundation
Ross Gardler
@rgardler
rgardler@apache.org
Vice President, Community Development
The Apache Software Foundation
2. ● History of The Apache Software Foundation
● Accident or design?
● The Apache Way
● Flexibility and invariants
● Scaling the foundation
● From 8 to 2500+
● Surviving the future
● A collection of projects or collaboration between
experts?
4. Founding of Apache
● Started as “Apache Group” (8 members)
● Resumed work on NCSA httpd in Feb 1995
● UIUC put httpd in public domain, but essentially
abandoned it
● Chose permissive licensing
● Informal corporate structure, until...
5. Creation of the Foundation
● Incorporated with 21 members in 1999
● ~2,500 committers, 291 members, and 53 emritus
members today
● Membership-based organisation
● 501(c)3 publish charity status
6. Apache's mission
The Apache Software Foundation provides
support for the Apache community of open source
software projects. The Apache projects are
characterised by a collaborative, consensus
based development process, an open and
pragmatic software licence, and a desire to create
high quality software that leads the way in its field.
7. Apache's tagline
We are more than a group of
projects sharing a server, we are a
community of developers and users
8. Or to put it another way...
● Let developers focus on what they do best
● Code
● Document (if only...)
● Foundation exists to do the rest
● “The Apache Way”
● Open development vs. open source
● All technical decisions about a project are made in
public (mailing lists)
9. Indirect financial support
● Apache does not pay for development
● Voluntary contributions only
● Many (not all) developers are paid by a third-
party to work on the project
● Foundation bears indirect support costs
● Infrastructure, legal, publicity, etc.
11. We're a meritocracy
● Everyone has a voice
● Do stuff and get a vote
● Merit is not transferable between projects
● Merit across multiple projects or at foundation
level earn you membership
12. Decision Making
● Who makes decisions?
● Community consensus via debate and code
● Occasionally a vote is required
● +1, +0, -0, -1
● Everyone in the community has a vote
● “binding” vote given to committers
● All technical votes cast on public lists
13. Rule of Lazy Consensus
● Trusted parties can just get on with it
● They know when a change will be controversial
● State what you intend to do and why
● Start doing it
● If no-one objects to the idea commit the code
● There's always code review
15. Growth of the Foundation
● Started with just HTTP Server in 1995
● The model “felt” repeatable
● Today, we have over 70 top-level projects
● >30 in Incubator
● It took over 15 years to get there...
● … but it wasn't smooth ...
16. Jakarta “Foundation”
● Jakarta: “umbrella” for all Java efforts
● Successful as a brand in its own right
● Tomcat, Ant, Struts, etc.
● Started to copy the foundation org structure
● “mini”-board... but problems arose...
● who was responsible?
17. Importance of Oversight
● Jakarta issues led to a lot of navel gazing
● Ultimately agreed upon an extremely flat
organisational structure
● Very short communication lines
● Umbrella projects are bad!
● We killed jakarta: all projects became top-level
18. Board Oversight
● Projects submit quarterly board reports
● By far the most important board activity
● Looking for repeating community anti-patterns
● Emerging umbrella projects
● Undue commercial influence
● Stagnating community
● Etc.
● NOT concerned with technical issues
19. Foundation Structure
● Top-Level Projects ● Foundation
● Users ● Members
● Contributors – Cross-project
community
● Committers ● Board
● PMC – Oversight
– Technical
management
● Foundation projects
21. Community
● Diversity
● Minimum of 3 committers
● unrelated to one another outside the project
● Fully audited code
● CLAs on file
● No incompatible licences
● Practice The Apache Way
–
22. Generic and Reusable
● Don't (just) open source a complete application
● Open source the component parts
independently
● Encourage communities from outside your
domain
● Get enhancements to your libraries from others
● Or maybe, you can contribute to someone elses
26. Can the ASF scale further?
● More projects mean
● Small overhead on foundation
● More volunteers at foundation level
● But...
● more opinions on what “The Apache Way” is
● more potential for abuse of ASF brand
27. Managing growing pains
● Flat structures give power to “newbies”
● Low barriers to entry
● No entrance “exam”
● Can result in the “blind leading the blind”
● But, hierarchy is inefficient
● Higher barrier to entry creates a hierarchy
● So how do we ensure “The Apache Way”
survives?
● Without stagnating
28. The Apache Way has the answer
● Peer review is core to The Apache Way
● “Just get on with it, we'll object if necessary”
● Someone is watching
● Objections are supported by debate
– That's how we learn
● Mentoring is a small step from peer review
29. The Incubator
● Incubates new projects
● More specifically new project communities
● Mentors guide the project team
● Teach The Apache Way
30. Community Development Project
http//community.apache.org
● Google Summer of Code
● Code only
● Summer only
● Students only
● Apache Mentoring Project
● Any contribution
● Any time
● Anyone
31. Why do this in foundation projects?
● Let developers do what they do best: code
● But some volunteers want to help newcomers
● Good for recruiting
● Good for training
● Good for community
● Good for getting stuff done
33. Separation of Concerns
● Foundation
● Brand
● Infrastructure
● Legal
● Cross project community
● Projects
● Technical issues
● Project community
34. No leaders, just doers
● Give decision making power to the doers
● Use lazy consensus to avoid “management by
committee”
● Anyone with sufficient merit can veto
● But they should never need to
● Consensus through discussion
35. Generalise
● Don't just open source a complete application
● Open source components of the application
● Most applications address a niche
● You are not unusual in this
36. Educate
● Apache projects are successful because of
“The Apache Way”
● There are other ways
● But not in Apache
● Better to ensure newcomers understand
● Incubation for project communities
● Mentoring for individuals
