Informal Collaboration (1995)● Apache Group– 8 people– sharing code on abandoned NCSA httpd● Apache web server releases– 0.6.2 (first public release) April 1995– 1.0 released 1stDecember 1995
A Foundation (1999)● Commercial opportunities– Formal legal structure required● Membership based charity– IRS 501(c)3– Donations by individuals tax-deductible (in US)● Virtual world-wide organization● First ApacheCon March 2000– Apache 2.0 Alpha 1● First EU ApacheCon October 2000
Today● Hundreds of projects– Small libraries– Critical infrastructure– End user tools● Well defined project governance● Formal mentoring● Accelerating growth
The ASF, By Numbers● Projects = 113● Incubating Projects = 34● Board/President Committees = 10● Board Members = 9● Foundation Members = ~500● PMC Committee Members = ~1500● Committers = ~3400● ICLAs = ~5100
Org structure● Member-based corporation - individualsonly● Members nominate and elect newmembers● Members elect a board - 9 seats● Semi-annual meetings via IRC● Each PMC has a Chair - eyes and ears ofthe board (oversight only)
Another way● A number of projects● Each responsible for their own code,community and direction● Board provides oversight, but has no sayon what code gets written, what directionprojects take, what new projects we shouldstart etc● Various support (eg infra, branding, press)to help projects focus just on their code +community
Labs● Members can start new “scratch” projects● Some graduate to TLPs (eg. Steve)● Most languish in obscurity, but give a placeto work out interesting problems
Incubator● Process for a project to enter the ASF● Legal: Can we release the code under ourlicense?● Community: Is the project sustainable?● Educational: Do they know how we dothings?
Attic● Graveyard?● Landfill?● Hopefully more like Grandmas attic whereyou can find cool stuff and repurpose ityears later.
Not all “Plain Sailing”● Jakarta “Foundation”– Jakarta was an “Umbrella” for all Java projects– Successful brand in its own right● Tomcat, Struts, Ant and many moreinnovations● Started to copy foundation structure– “Mini”-board … but problems arose …– Avalon: Who was responsible?
Importance of Oversight● Jakarta demonstrated that Umbrellas arebad– Flattened organisational structure– Jakarta projects became top level projects● All projects submit board reports quarterly– Community focused– Not technical focus● Board can, and does (occasionally)intervene– On community issues only
Bottom-up management● Board does not say “we want X”● Developers say “X is cool”– We enable developers to do cool stuff– Apache developers are at the forefront ofinnovation● Not interested in a single runner– We want relay teams– Community is critical to the Apache Way● Apache is about support communities
Example: Git● Various projects wanted to experiment withGit, whereas we had traditionally used svn● After much debate, Infrastructure providedGit for projects to try out● Board expressed concern about how itmight affect community dynamics, but inthe end it was up to the projectsthemselves● Projects now have the choice of SCM
So, why have a board?● The board exists because the state ofDelaware requires a 501 to have oversight● The Foundation exists to provide astructure to– Accept donations tax-free– Do fundraising activities– Sign contracts– Hire employees– Provide legal protection to projects
(nearly) All volunteer work● If you want something done– Volunteer on the appropriate committee● A few paid contractors - all the stuff werebad at or dont want to do– Press/Marketing– Infrastructure/Sysadmin– Administration/Conferences● No paid committers
Types of contribution● Any constructive contribution earns merit– Permissively licensed only● Not just code– Evangelism– Bug reports and triage– Testing– Documentation– Design feedback– User support– Etc.
All contributions are equal● Merit does not buy you authority– The community must still agree● Merit buys you privileges, e.g.– Commit access– Conflict resolution capabilities● Community agrees on direction● Individuals then make it happen
Decision Making● Most decisions are reversible● “If it didnt happen on the list, it didnthappen”● Uncontroversial or small changes– Lazy Consensus – assume its OK –JFDI● Controversial, irreversible or large changes– Propose then wait a minimum of 72hours
CTR/RTC● Commit Then Review– Small reversible changes– Project in active development● Review Then Commit– Large or Controversial changes– Stable/Maintenance branch
No Jerks Allowed!● Most people are nice– We all have bad days– Some are, well, Jerks● Trolls exist– DO NOT FEED● Dont become a poisonous person“How Open Source Projects SurvivePoisonous People (And You Can Too)” byBen Collins-Sussman and Brian Fitzpatrickhttp://video.google.com/videoplay?docid=-4216011961522818645
Community > Code● More than just a clever slogan● We can rewrite the code● Poisonous people spoil the fun
However ...● Many businesses rely on what we do forfun. So its important that projects be– Sustainable (See: Diversity)– Legal (patent, copyright, licenses, etc ...)– Available (See: Infrastructure)
Ways to Contribute● Documentation, Tutorials and Examples● Helping others with queries and questions● Issue / bug tracker triage● Testing new fixes, helping reproduceproblems● Bug Fixes and New Features● Writing add-ons and extensions● Mentoring, volunteering for the Foundation
Companies Contributing● Everyone at Apache is there as an individual● Companies cant buy access or committership● To get involved, need to put employees to workon the project, have them gain merit● BDFLs are not allowed, everyone has an equalvoice● Diversity of community means one companycant dominate● Means you can safely build your business on it
License● Apache License● Very permissive● We encourage you to give back, but wedont require it● This makes it very business-friendly
In Summary● It works!● Its the best way we know of to developOpen Source Software in a collaborative,open and meritocratic way● Some things can seem hard at first● But theres normally a reason why● Ask questions! Much is documented, butnot all, and not all in the same place● Learn, participate, improve!
The Apache WayRich Bowen / @rbowen /firstname.lastname@example.orgThanks for listening! Questions?A collaborative slidedeck with contributions fromNick Burch, Ross Gardler, Lars Eilebrecht,Justin Erenkrantz and Isabel Drost