Put the item people are least familiar with, but which is really most important, first. While the Apache Projects provide all the code, it's the Foundation and the Apache Way that enable them to do that – independently, and for the long-term.
Note that currently 100% of my time on Apache work is as an unpaid volunteer; my IBM job is completely unrelated (both technically and organizationally).
The most important thing to realize on this slide: while the Foundation provides a home for over 100 projects, each of those projects is really an independent community of developers and users.
Fundamentally, the organization is pretty simple. The Membership elects a Board of Nine Directors annually. The Board sets overall policy and provides oversight for all operations. Note especially that officers and PMCs report directly to the board. The President and VP, Infrastructure manage day-to-day operations – but only of the infrastrucutre itself, not of our projects. The most important thing to realize from this picture is (click) that everything to the left of the page only provides organizational oversight. All technical decisions are made on the right hand half – within the PMCs and projects individually.
Having both founding members – Jim and Roy – as well as a number of newer members – including Dan Kulp, who's also speaking here at CamelOne – ensures continuity and fresh ideas. The board provides organizational oversight through reviewing the monthly and quarterly reports from all foundation activities. This ensures that PMCs and officers are acting indepdnently on behalf of their projects. Note that “technical” is not something the board oversees or comments on (unless it's a security issue or the like).
So what is the purpose of the ASF? Fundamentally, that's it: provide software for the public good. But there's got to be more to the Foundation's mission, hasn't there?
It's really that simple. The Foundation's purpose is to serve as a stable and independent home for it's projects. The Foundation should only be there to handle the stuff coders don't want to do or aren't good at handling; everything else – and especially all technical decisions – are made by the coders in PMCs and projects.
These are the key services the Foundation provides to it's projects. Thinking of the ASF as a service provider to like-minded software development communities is a good metaphor.
Our annual budget has just about doubled in the past 4 years. Sponsors' annual donations from multiple sources ensures a steady stream of income, which helps to ensure indepdence from outside commercial influence. Along with system administrators to keep our dozens of servers running, expenses include publicity assistance that's available to our projects – including the press release today.
Thank you to our sponsors! Note that the majority of sponsors are recurring and strong supporters of our work, both financially and technically, in terms of their donations of code or their employee's engineering time to many Apache projects.
All Apache software should be useable under our license. This ensures maximum freedom for users. This also ensures that software released with our license is available to the public.
Apache ensures clean IP by ensuring that all contributions to our projects are properly licensed to us under the Apache License – and thus are properly licensed to you under the Apache license. Corporations are welcomed and encouraged to provide a CCLA, although it is not required. ICLAs are required for becoming a committer. Per policy, we do not accept modified ICLAs or CCLAs, or software grants. Note that Apache has never asked for copyright assignment, and doesn't particularly want It. All we need is contributions clearly under our license, so it's free to use – by us or by you.
Some of these are rules for Apache projects; many are best practices. These are all techniques that a community-driven project can maintain independence, and promote longevity for the project.
There is very little technical hierarchy in Apache projects. Merit defines what you can do within a project community. Truly, those who do the work get to decide. Note that each community measures merit – for example, the merit to become a committer – differently. Similarly, Merit is not transferable between individuals. Just because you're a committer doesn't mean your coworker – or boss – gets any merit within the project. Each individual needs to prove themselves publicly to the whole project community. Merit applies to the membership as well: new members are selected for the merit they've shown on multiple Apache projects, or on organizational goals.
This is a critical factor in maintaining independent and long-lived communities. People are expected to serve as individuals – not as representatives of their company. This doesn't mean you can't work on the code your company wants to add – but you do need to work within the project itself to get the code accepted. Diversity is the key to longevity. Having a useful technical project that has contributors from multiple employers means that even if your company happens to change business direction, there is still enough of a community to continue the project goals. And when we say all votes are equal, that's all. PMC chairs, Apache directors or members, whoever – all get one vote on projects they've earned merit on.
In terms of ensuring Apache projects may be freely used by all, PMCs have the most important role. PMCs are expected to ensure that all contributions to the project are properly licensed, and that all releases are tested and reviewed. PMCs are also expected to keep a diverse and healthy community; however in cases where PMC diversity or health have failed, the board is always reading their reports. In extreme cases – when a PMC cannot self-correct when it's issues are pointed out – the board will – and has – step in to make corrections. The board is a blunt instrument of last resort, but it does ensure independence from commercial influence for all Apache project communities.
For all the talk we have of voting – Google got the +1 from us, by the way – votes in healthy communites should be rare. Discussion and consensus is the best way to move a project forward. Since the projects have technical goals, this can often be a simpler discussion: does the new code/feature/change make the product better or not? Vetoes should be rare; when they are made they must have a specific and defensible technical reason. Every Apache release must be voted +1 by at least three PMC members. This ensures that the source code released is done as an act of the project of the Foundation, and not as individuals. Releases may not be vetoed; if at least three PMC members vote +1, then we might as well let the public use the code!
Collaboration must be public, open, archived, and timely. That is: timely, meaning plenty of time for a sufficient part of the community to have a chance to comment. These rules are not negotiable. While in some cases this may seem to slow the speed of progress, using lists and allowing time is critical to ensure the whole community can participate in decisions. 72 hours is the minimum, it's often good to wait longer if there is a discussion ongoing.
Again, these guidelines ensure independence in our project governance and releases. “ Hats” is a concept where people should explicitly state who they are representing at any particular time. PMC members should cast votes based on the merits within a project – while they may separately advocate for new ideas at the behest of their employer. It should be obvious to list readers who you are speaking on behalf of. Corporations or organizations are never given votes, made committers, members, or other positions at the ASF or at Apache projects. This ensures that all governance is by individuals – many of whom may be employed by various companies – but who also keep their Apache roles through job changes.
This is a great quote from today's press release by the ASF. We also have about a dozen past projects, and a number of other, non-code projects to assist with operations. Conferences committee, Community Development, and others are tasked to manage various operations like events and educating new contributors (Legal, Brand Management, Fundraising, and Marketing & Publicity are all officers, not PMCs)
Note that the Incubator operates as a PMC; that is it reports to the board on it's operations of mentoring and growing these new podling communities into Apache projects. Not all projects succeed. Failure is determined by community metrics – not technology choices. Note that failing to create an actual release can be a failure – code that can't be put together easily by end users is a requirement.
Any boxed up projects in the attic would be happy to have a new, fresh community come take them out. People are free to always fork the code. New communities – if they should appear – would likely go through the incubator to show they have sufficient diversity.
Apache does not have technical goals for it's projects, other than providing open source code for the public good. The Foundation exists to serve as a stable home for like-minded communities. Congratulations to the Apache OpenOffice podling on having it's 3.4 release of the previous OpenOffice.org code!
Apache does not pay for development on it's projects. If there isn't an interested community of people in the world already interested in coding a project then... it must not be an interesting project yet. Each Apache project is truly independent. While many share community members and norms / behaviors, some are very different, and social expectations may be different across projects.
Contributing to a project really is that easy: just join the list, and make your suggestion. Patches and well written bugs are especially appreciated in most projects, and are a simple way to show your merit and interest in the project.
This is a talk that is worth every community member's time to see once. A key point is: the most valuable things in an open source community are attention and focus. Don't let those be derailed by trolls.
Projects in outercurve supply their own governance, so the oversight – and ensured independence – of Apache is not there.
1. About: Apache The Foundation, The Apache Way,100+ Apache Projects Olivier Lamy | @olamy VP Apache Maven, ASF Member AFDEL Paris July 3rd 2012
2. AgendaWho am I: IntroductionWhat is it: Apache Software FoundationHow does it work: The Apache WayWho does the work: Apache projectsWhy Apache? Compare / Contrast open source groups
3. /meOlivier Lamy (@olamy ) (twitter.com/olamy)https://www.slideshare.net/olamyApache Software Foundation Member VP, Maven PMCs: Maven, Archiva, Tomcat, Sqoop, DirectMemory, Kalumet Commiter: CommonsJenkins etc.. (add bugs in various opensource projects)Also a Software Architect at Talend
4. CreditsSlides largely inspired from Shane Curcuru presentation: http://communityovercode.com/2012/05/camelo ne-2012-presentation/
5. What is it: The ASFMembership-based corporation; Non-profit US 501(c)3 CharityDirectors, officers all unpaid volunteersPaid contractors: sysadmins, press officerBroad-based Membership of individuals ensures independenceCollection of Apache project communities
6. Apache Org Chart Nominate, elect Members Directors annually Organizational ~400 Oversight Technical Board of Oversight Nominate, elect 9 Directors new members Create & update Appoint officers upon PMC request Report monthly Report quarterly PMCs Officers 100++ ~10Define organizational & legal policies Committers Nominate, elect Vote for ~3,000 new committers project releases Write project code
7. Apache Board of DirectorsElected by ASF Membership annuallyLong-time directors: Jim Jagielski, Greg Stein, Roy Fielding, Sam RubyNewer directors: Bertrand Delacretaz, Doug Cutting, Shane Curcuru, Brett Porter, Rich Bowen, Ross GardlerProvide legal and organizational oversight
8. Apache Mission: WhatProvide open source software to the public free of charge
9. Apache Mission: WhatProvide open source software to the public free of charge “Apache aims to provide a pragmatic, non-technical framework to its projects.” - Justin ErenkrantzLet coders code; Foundation exists to do rest
10. Apache Mission: HowProvide legal, organizational, and technical infrastructure for open source software development, and perform oversight to ensure project independenceProvide shelter for individual volunteers from legal suits directed at Apache projectsProvide a legal entity to serve as an independent recipient of donations
11. Budget and SponsorshipAnnual budget: est. 790K USD in 2012Sponsorship program ensures independencePrimary budget categories: sysadmin contractors; hardware & bandwidth; publicityApache does not pay for software development
12. Apache SponsorsPlatinum: Citrix, Facebook, Google, Microsoft, Yahoo!Gold: AMD, Hortonworks, HP, IBMSilver: Basis Technology, Cloudera, Go Daddy, Huawei, Matt Mullenweg, PSW Group, SpringSourceBronze: AirPlus Intl., BlueNog, Digital Primates, FuseSource, Intuit, Liip AG SA Ltd., Lucid Imagination, Talend, Twitter, Two Sigma Investments, WANdiscoSeparately: Long-term hosting & bandwidth providers
13. Apache LicenseApache projects use the Apache License 2.0Pragmatic and permissive Maximum freedom for usersIncludes patent grantEasily and frequently used by other groups
14. Contributor License AgreementsAKA “ICLA” for Individuals – 4649 signed ICLA required to become committerCCLA for Corporations – 318 signedEnsures that contributors have the right to contribute, and that ASF has right to license to the public under Apache licenseNo copyright assignments – only a license
15. The Apache Way How does it worksMeritocracy – those who do, decidePeer-based – participate as individualsOversight – responsible and independentDecisions – made by consensusCollaboration – public and asynchronousParticipation – by individuals
16. Apache Way: MeritMerit is based on actual accomplishments within a projectExisting community measures valueMerit never expiresMerit is not transferable
18. Apache Way: OversightPMCs provide technical oversight of all project releases, new committers/PMC members Ensure clean IP in all Apache releasesBoard provides organizational oversight of all Apache projects Ensure PMCs function independently
19. Apache Way: DecisionsDecisions made by consensus, discussion If consensus is not obvious, then voteVotes are by +1 / +-0 / -1All -1 or veto votes must have a reason Releases may not be vetoedPMCs vote on all releases Committers vote on code changes
20. Apache Way: Collaboration“If it didnt happen on the mailing list, it didnt happen.” - Roy FieldingAny discussions F2F, IRC, wherever must be reported back to mailing listAll decisions must be made on-list, and with a 72+ hour window for voting/discussionLists are asynchronous and publicly archived
21. Apache Way: ParticipationCommitters participate as individuals Expected to wear appropriate “hat”Releases must have three binding +1 votes Ensures multiple and independent eyesCorporations are never made committers, members, nor PMC members
22. Apache ProjectsOver 100 code-producing community driven projects 50+ Podlings in Incubation“Apache Projects include millions of lines of code overseen by an all-volunteer community across six continents. Apache technologies power more than half the Internet, petabytes of data, teraflops of operations, billions of objects, and enhance the lives of countless users and developers.”
23. Apache Projects: IncubatorNew project proposals are made to the Apache Incubator PMC PMC votes to accept on community meritsIncubation process ensures podling community understands Apache Way No technical direction required by incubationPMC votes to graduate podlings to TLPs (Top Level Projects)
24. Apache Projects: AtticProjects that cannot reliably report and/or find three +1 PMC votes to create releasesWhen community lacks participation or diversity – not for technical reasonsBoard votes to “box up” the project and place in the AtticAll resources are read-only for posterity
25. Apache Projects: TechnologyApache projects provide leading technology: Webservers, Java tools & stacks, search, cloud, big data, build tools, CMS/web framework, databases, OSGi containers, graphics ... And end user Office suites!“Competing” project technology is OK If an active community following the Apache Way wants to join, great!
26. Apache Projects: DevelopmentApache never pays for developmentSome committers/PMC members are corporate sponsored; some are not Consultants, authors, students, researchersEach Apache project is an independent community of committers and users
27. Apache Projects: Join Now!To join a project, subscribe to the mailing listAll productive input is appreciatedPMC members nominate and vote new committers periodicallyEvery project has different expectationsMany ways to contribute: patches, bugs, documentation, training, graphics,...
28. Dont Feed The TrollsAll-inclusive public discussions and archives sometimes bring out the worst in people Dont let them derail community“How Open Source Projects Survive Poisonous People (And You Can Too)” Ben Collins-Sussman & Brian Fitzpatrick http://s.apache.org/DontFeedTheTrolls
29. Why Apache?Who am I: IntroductionWhat is it: Apache Software FoundationHow does it work: The Apache WayWho does the work: Apache projectsWhy Apache? Compare / Contrast open source groups
30. Apache and EclipseApache: Eclipse:Multiple projects Multiple projectsPermissive license Semi-copyleft licenseIndividual members Corporate backingFree to participate Membership dues One key difference: Eclipse governance & board includes Strategic Developers & Consumers – corporations.
31. Apache and OutercurveApache: Outercurve/CodePlex:Multiple projects Multiple projectsPermissive license Various licensesIndividual members Corporate backingBoard oversight Individual governance One key difference: Microsoft backing, and each project provides own style and set of governance.
32. Apache and PythonApache: Python:Multiple projects Single projectPermissive license Permissive licenseIndividual members Individual membersIndependent board Guido as BDFL One key difference: Python focuses on just the programming language.
33. Apache and MozillaApache: Mozilla:Multiple projects Multiple projectsPermissive license Semi-copyleft licenseIndividual members Corporate staffNo specific technical End user project focus focus One key difference: Mozillas end user focus means different level of marketing, trademark, and release management.
34. Apache SimilaritiesWhats similar about these groups?Most explicitly adopted parts of Apache WayVoting; consensus & community; meritIndependent foundationsSeveral have explicitly noted the copying of their ways from Apache
35. Apaches Tagline“We are more than a group of projects sharing a server; we are a community of developers and users... sharing a common Apache Way of developing software.” “Community over Code”
36. Thank You!Questions? @olamyLearn more about Apache: http://community.apache.org/