The "Apache Way" is the process by which Apache Software Foundation projects are managed. It has evolved over many years and has produced over 100 highly successful open source projects. But what is it and how does it work?
In this session Ross Gardler will describe how an Apache project is managed. He will describe how the foundation provides an technical and legal infrastructure for each project and how the Apache Way provides the governance scaffolding for individual projects. This provides the framework for Apache projects which are then free to apply the Apache Way to ensure their project succeeds.
Having attended this session you will have a better understanding of the inner workings of both the foundation and its projects. With this understanding you will be better equipped to engage with and benefit from Apache projects.
Take control of your SAP testing with UiPath Test Suite
The Apache Way Explained
1. The Apache Way
Ross Gardler
@rgardler
rgardler@apache.org
A collaborative slidedeck with contributions from ${ASF_Members}
(in particular Justin Erenkrantz, Isabel Drost and Lars Eilebrecht)
2. Who is this Ross Gardler?
Ross Gardler
Director and EVP
The Apache Software Foundation
rgardler@apache.org
@rgardler
5. 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 1st December 1995
6. A Foundation (1999)
● Commercial opportunities
● Formal legal structure required
● Membership based charity
● IRS 501(c)3
● Donations by individuals tax-deductible (in US)
● First ApacheCon March 2000
● Apache 2.0 Alpha 1
● First EU ApacheCon October 2000
7. Today
● Hundreds of projects
● Small libraries
● Critical infrastructure
● End user tools
● Well defined project governance
● Formal mentoring
● Accelerating growth
14. 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 more innovations
● Started to copy foundation structure
● “Mini”-board … but problems arose …
● Avalon: Who was responsible?
15. Importance of Oversight
● Jakarta demonstrated that Umbrellas are bad
● Flattened organisational structure
● Jakarta projects became top level projects
● All projects submit board reports quarterly
● Community focussed
● Not technical focus
● Board can, and does (occasionally) intervene
● On community issues only
17. Don't pick winners, pick runners
● 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 of innovation
● Not interested in a single runner
● We want relay teams
● Community is critical to the Apache Way
● Apache is about support communities
18.
19. (nearly) All volunteer work
● If you want something done
● Volunteer on the appropriate committee
● A few paid contractors
● Press
● Infrastructure
● Administration
● No paid committers
22. 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.
23. 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
24. Decisions Making
Most decisions are reversible
●
“If it didn't happen on the list, it didn't happen”
●
Uncontroversial or small changes
●
● Lazy Consensus – assume it's OK – JFDI
Controversial, irreversible or large changes
●
● Propose then wait a minimum of 72 hours
25.
26. Finding that list!
● Listed on project website
● dev@project.apache.org
● Primary list
● commits@project.apache.org
● Automated source change notification
● users@proejct.apache.org (optional)
● User-to-user support
● http://mail-archives.apache.org
27. No Jerks Allowed!
● Most people are nice
● We all have bad days
● Some are, well, Jerks
● Trolls exist
● DO NOT FEED
● Don't become a poisonous person
“How Open Source Projects Survive
Poisonous People (And You Can Too)” by
Ben Collins-Sussman and Brian Fitzpatrick
http://video.google.com/videoplay?docid=-4216011961522818645
33. Thanks for listening! Question?
The Apache Way
Ross Gardler
@rgardler
rgardler@apache.org
A collaborative slidedeck with contributions from
Justin Erenkrantz and Isabel Drost
Notas del editor
50 minute slot 30 mins presentation 20 mins discussion We'll go from the history of the Foundation and the way it was set up, past the licensing philosophy at Apache, all the way to business models common around Apache projects. And of course, we'll look at how individuals can contribute in many different ways to an Apache project
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 (more later) Informal corporate structure until.. .
Creation of Foundation Incorporated with 21 members in 1999 ~2,300 committers, 274 members, and 52 emeritus members today Membership-based organization IRS 501(c)3 public charity status Donations by individuals tax-deductible
Starting new Apache projects Incubator - “podlings” can be nominated and eventually “graduate” to be a PMC Needs foundation member to mentor Usually legal and/or community issues Labs - once you are a committer, you can have a sandbox (shared mailing list, no non-committers, no releases)
Community departure? What happens when the community leaves? Unable to muster 3 votes for a release... ...no active committers... ...or fail to report to Board Move project into “Attic” No one has returned from attic...yet.
Each Apache project is independent Grouped as ‘top-level’ PMCs (TLP) Board: Social - not technical - guidance Some TLPs have ‘sub-projects’; discouraged Karma in one PMC doesn’t grant rights in another PMC - earn karma independently Note that lots of sub-projects are a warning sign
Jakarta “Foundation” Jakarta:“umbrella” for all Java efforts Successful as a brand in its own right Tomcat, Ant, Struts, etc.: great innovation Started to copy foundation org structures “Mini”-board...but problems arose... Avalon: who was responsible?
Importance of Oversight Jakarta issues led to a lot of navel-gazing Ultimately agreed upon an extremely flat organizational structure: umbrellas are bad! So, we killed Jakarta: spun-off projects Board requires all projects to submit reports each quarter: by far, most important thing that Board does in our monthly meetings.
Let a thousand flowers bloom Grassroots: interesting projects welcomed Board doesn’t say “We want X”, instead developers say “We think X is cool” Helped keep us at forefront of innovation Community support is essential - we are not interested in “solo” projects, but how can we help create a viable community?
No Jerks Allowed! Most people are nice; there are dingbats, or may just be someone having a bad day Trolls exist...don’t feed them. Don’t become a poisonous person.