Community Development at the
 Apache Software Foundation
     BOSC 2010, Boston, July 2010
    Open Bioinformatics Foundat...
●   History of The Apache Software Foundation
    ●   Accident or design?
●   The Apache Way
    ●   Flexibility and invar...
History of the ASF
Founding of Apache
●   Started as “Apache Group” (8 members)
●   Resumed work on NCSA httpd in Feb 1995
    ●   UIUC put h...
Creation of the Foundation
●   Incorporated with 21 members in 1999
    ●   ~2,500 committers, 291 members, and 53 emritus...
Apache's mission


    The Apache Software Foundation provides
support for the Apache community of open source
    softwar...
Apache's tagline



    We are more than a group of
 projects sharing a server, we are a
community of developers and users
Or to put it another way...
●   Let developers focus on what they do best
    ●   Code
    ●   Document (if only...)
●   F...
Indirect financial support
●   Apache does not pay for development
    ●   Voluntary contributions only
●   Many (not all)...
The Apache Way
We're a meritocracy
●   Everyone has a voice
    ●   Do stuff and get a vote
●   Merit is not transferable between project...
Decision Making
●   Who makes decisions?
    ●   Community consensus via debate and code
●   Occasionally a vote is requir...
Rule of Lazy Consensus
●   Trusted parties can just get on with it
    ●   They know when a change will be controversial
●...
Scaling the Foundation
Growth of the Foundation
●   Started with just HTTP Server in 1995
●   The model “felt” repeatable
●   Today, we have over...
Jakarta “Foundation”
●   Jakarta: “umbrella” for all Java efforts
    ●   Successful as a brand in its own right
    ●   T...
Importance of Oversight
●   Jakarta issues led to a lot of navel gazing
●   Ultimately agreed upon an extremely flat
    o...
Board Oversight
●   Projects submit quarterly board reports
    ●   By far the most important board activity
●   Looking f...
Foundation Structure
●   Top-Level Projects    ●   Foundation
    ●   Users                 ●   Members
    ●   Contributo...
What makes a good Apache
        project?
Community
●   Diversity
    ●   Minimum of 3 committers
    ●   unrelated to one another outside the project
●   Fully aud...
Generic and Reusable
●   Don't (just) open source a complete application
●   Open source the component parts
    independe...
CC- BY-NC-SA © 2010 Bertrand Delacrataz
CC- BY-NC-SA © 2010 Bertrand Delacrataz
Surviving the Future
Can the ASF scale further?
●   More projects mean
    ●   Small overhead on foundation
    ●   More volunteers at foundati...
Managing growing pains
●   Flat structures give power to “newbies”
    ●   Low barriers to entry
    ●   No entrance “exam...
The Apache Way has the answer
●   Peer review is core to The Apache Way
    ●   “Just get on with it, we'll object if nece...
The Incubator
●   Incubates new projects
    ●   More specifically new project communities
●   Mentors guide the project t...
Community Development Project
                   http//community.apache.org
●   Google Summer of Code
    ●   Code only
  ...
Why do this in foundation projects?
●   Let developers do what they do best: code
●   But some volunteers want to help new...
Summary
Separation of Concerns
●   Foundation
    ●   Brand
    ●   Infrastructure
    ●   Legal
    ●   Cross project community
●...
No leaders, just doers
●   Give decision making power to the doers
●   Use lazy consensus to avoid “management by
    comm...
Generalise
●   Don't just open source a complete application
●   Open source components of the application
●   Most applic...
Educate
●   Apache projects are successful because of
    “The Apache Way”
●   There are other ways
    ●   But not in Apa...
Questions
Upcoming SlideShare
Loading in …5
×

Gardler bosc2010 community_developmentattheasf

2,213
-1

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,213
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Gardler bosc2010 community_developmentattheasf

  1. 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. 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. 3. History of the ASF
  4. 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. 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. 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. 7. Apache's tagline We are more than a group of projects sharing a server, we are a community of developers and users
  8. 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. 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. 10. The Apache Way
  11. 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. 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. 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. 14. Scaling the Foundation
  15. 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. 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. 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. 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. 19. Foundation Structure ● Top-Level Projects ● Foundation ● Users ● Members ● Contributors – Cross-project community ● Committers ● Board ● PMC – Oversight – Technical management ● Foundation projects
  20. 20. What makes a good Apache project?
  21. 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. 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. 23. CC- BY-NC-SA © 2010 Bertrand Delacrataz
  24. 24. CC- BY-NC-SA © 2010 Bertrand Delacrataz
  25. 25. Surviving the Future
  26. 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. 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. 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. 29. The Incubator ● Incubates new projects ● More specifically new project communities ● Mentors guide the project team ● Teach The Apache Way
  30. 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. 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. 32. Summary
  33. 33. Separation of Concerns ● Foundation ● Brand ● Infrastructure ● Legal ● Cross project community ● Projects ● Technical issues ● Project community
  34. 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. 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. 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. 37. Questions
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×