The document discusses the history and operations of the Apache Software Foundation. It began in 1995 with 8 developers working on the Apache HTTP Server. It is now a large organization with over 2,500 committers across 70+ projects. The ASF operates under an open governance model called "The Apache Way" which emphasizes merit-based consensus decision making. It also discusses how the ASF scales its operations through project oversight, incubating new projects, and community education programs like mentoring.

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?

3. History of the ASF

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.

10. The Apache Way

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

14. Scaling the Foundation

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

20. What makes a good Apache
project?

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

23. CC- BY-NC-SA © 2010 Bertrand Delacrataz

24. CC- BY-NC-SA © 2010 Bertrand Delacrataz

25. Surviving the Future

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

32. Summary

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

37. Questions