The Apache Way
•Descargar como ODP, PDF•
3 recomendaciones•1,491 vistas
This session will provide an introduction to The Apache Software Foundation – it’s history, organization and principles, and how Apache projects work. You will learn about The Apache Way of managing meritocracy-based and community driven projects as is practiced by all of the 100+ Apache projects, the levels of participation in Apache projects, and how you can get involved. This talk will also touch on the how the Apache governance process and the permissive Apache 2.0 license help ensure longer-lived open source projects, and provide a different opportunity for engagement than some other source communities and license models. Shane Curcuru was elected as a Member of the ASF in 2002, and has been volunteering on public relations, conferences, brand management, and various other areas at Apache ever since. He also serves as a Director.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (11)
Destacado
Destacado (20)
Similar a The Apache Way
Similar a The Apache Way (20)
Último
Último (20)
The Apache Way
- 1. About: Apache The Foundation, The Apache Way, 100+ Apache Projects Shane Curcuru | @shanecurcuru Vice President, Brand Management The Apache Software Foundation http://communityovercode.com/2012/05/camelone-presentation/
- 2. Agenda ● Who am I: Introduction ● What is it: Apache Software Foundation ● How does it work: The Apache Way ● Who does the work: Apache projects ● Why Apache? – Compare / Contrast open source groups
- 3. Who am I: Introduction ● Shane Curcuru ● Apache Software Foundation – Member, Director – VP, Brand Management – PMCs: Community Development, Conferences; Apache OpenOffice Mentor Also an Applications Architect at IBM
- 4. What Is It? ● Who am I: Introduction ● What is it: Apache Software Foundation ● How does it work: The Apache Way ● Who does the work: Apache projects ● Why Apache? – Compare / Contrast open source groups
- 5. What is it: The ASF ● Membership-based corporation; Non-profit US 501(c)3 Charity ● Directors, officers all unpaid volunteers ● Paid contractors: sysadmins, press officer, EA ● Broad-based Membership of individuals ensures independence ➔ Collection 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 upon Appoint officers PMC request Report monthly Report quarterly PMCs Officers 100++ ~10 Define organizational & legal policies Committers Nominate, elect Vote for new committers project releases ~3,000 Write project code
- 7. Apache Board of Directors ● Elected by ASF Membership annually ● Long-time directors: Jim Jagielski, Greg Stein, Roy Fielding, Sam Ruby ● Newer directors: Bertrand Delacretaz, Doug Cutting, Shane Curcuru, Brett Porter, Dan Kulp ● Provide legal and organizational oversight
- 8. Apache Mission: What ● Provide open source software to the public free of charge
- 9. Apache Mission: What ● Provide open source software to the public free of charge – “Apache aims to provide a pragmatic, non-technical framework to it's projects.” - Justin Erenkrantz ● Let coders code; Foundation exists to do rest
- 10. Apache Mission: How ● Provide legal, organizational, and technical infrastructure for open source software development, and perform oversight to ensure project independence ● Provide shelter for individual volunteers from legal suits directed at Apache projects ● Provide a legal entity to serve as an independent recipient of donations
- 11. Budget and Sponsorship ● Annual budget: est. 790K USD in 2012 ● Sponsorship program ensures independence ● Primary budget categories: sysadmin contractors; hardware & bandwidth; publicity ● Apache does not pay for software development
- 12. Apache Sponsors ● Platinum: Citrix, Facebook, Google, Microsoft, Yahoo! ● Gold: AMD, Hortonworks, HP, IBM ● Silver: Basis Technology, Cloudera, Go Daddy, Huawei, Matt Mullenweg, PSW Group, SpringSource ● Bronze: AirPlus Intl., BlueNog, Digital Primates, FuseSource, Intuit, Liip AG SA Ltd., Lucid Imagination, Talend, Twitter, Two Sigma Investments, WANdisco ● Separately: Long-term hosting & bandwidth providers
- 13. Apache License ● Apache projects use the Apache License 2.0 ● Pragmatic and permissive – Maximum freedom for users ● Requires attribution “Give me credit” ● Includes patent grant ● Easily and frequently used by other groups
- 14. Contributor License Agreements ● AKA “ICLA” for Individuals – 4649 signed – ICLA required to become committer ● CCLA for Corporations – 318 signed ● Ensures that contributors have the right to contribute, and that ASF has right to license to the public under Apache license ● No copyright assignments – only a license
- 15. How does it work? ● Who am I: Introduction ● What is it: Apache Software Foundation ● How does it work: The Apache Way ● Who does the work: Apache projects ● Why Apache? – Compare / Contrast open source groups
- 16. The Apache Way ● Meritocracy – those who do, decide ● Peer-based – participate as individuals ● Oversight – responsible and independent ● Decisions – made by consensus ● Collaboration – public and asynchronous ● Participation – by individuals
- 17. Apache Way: Merit ● Merit is based on actual accomplishments within a project ● Existing community measures value ● Merit never expires ● Merit is not transferable
- 18. Apache Way: Peer-based ● Peer-based communities ● Developers represent themselves ● All committer/PMC votes equal +/-1 ● Healthy communities create healthy code ● Diverse communities survive
- 19. Apache Way: Oversight ● PMCs provide technical oversight of all project releases, new committers/PMC members – Ensure clean IP in all Apache releases ● Board provides organizational oversight of all Apache projects – Ensure PMCs function independently
- 20. Apache Way: Decisions ● Decisions made by consensus, discussion – If consensus is not obvious, then vote ● Votes are by +1 / +-0 / -1 ● All -1 or veto votes must have a reason – Releases may not be vetoed ● PMCs vote on all releases – Committers vote on code changes
- 21. Apache Way: Collaboration ● “If it didn't happen on the mailing list, it didn't happen.” - Roy Fielding ● Any discussions F2F, IRC, wherever must be reported back to mailing list ● All decisions must be made on-list, and with a 72+ hour window for voting/discussion ● Lists are asynchronous and publicly archived ●
- 22. Apache Way: Participation ● Committers participate as individuals – Expected to wear appropriate “hat” ● Releases must have three +1 votes – Ensures multiple and independent eyes ● Corporations are never made committers, members, nor PMC members
- 23. Who does the work? ● Who am I: Introduction ● What is it: Apache Software Foundation ● How does it work: The Apache Way ● Who does the work: Apache projects ● Why Apache? – Compare / Contrast open source groups
- 24. Apache Projects ● Over 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.”
- 25. Apache Projects: Incubator ● New project proposals are made to the Apache Incubator PMC – PMC votes to accept on community merits ● Incubation process ensures podling community understands Apache Way – No technical direction required by incubation ● PMC votes to graduate podlings to TLPs (Top Level Projects)
- 26. Apache Projects: Attic ● Projects that cannot reliably report and/or find three +1 PMC votes to create releases ● When community lacks participation or diversity – not for technical reasons ● Board votes to “box up” the project and place in the Attic ● All resources are read-only for posterity
- 27. Apache Projects: Technology ● Apache projects provide leading technology: – Webservers, Java tools & stacks, search, cloud, big data, build tools, CMS/web framework, databases, OSGi containers, graphics, foobles... – And end user Office suites! ● “Competing” project technology is OK – If an active community f ollowing t he Apache Way want s t o j oin, great !
- 28. Apache Projects: Development ● Apache never pays for development ● Some committers/PMC members are corporate sponsored; some are not – Consultants, authors, students, researchers ● Each Apache project is an independent community of committers and users
- 29. Apache Projects ● Diverse communities provide independence ● Planning activities happen on-list ● “Powerplant” checkins are counter-productive
- 30. Apache Projects: Join Now! ● To join a project, subscribe to the mailing list ● All productive input is appreciated ● PMC members nominate and vote new committers periodically ● Every project has different expectations ● Many ways to contribute: patches, bugs, documentation, training, graphics,...
- 31. Don't Feed The Trolls ● All-inclusive public discussions and archives sometimes bring out the worst in people – Don't 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
- 32. Why Apache? ● Who am I: Introduction ● What is it: Apache Software Foundation ● How does it work: The Apache Way ● Who does the work: Apache projects ● Why Apache? – Compare / Contrast open source groups
- 33. Apache and Eclipse Apache: Eclipse: ● Multiple projects ● Multiple projects ● Permissive license ● Semi-copyleft license ● Individual members ● Corporate backing ● Free to participate ● Membership dues One key difference: Eclipse governance & board includes Strategic Developers & Consumers – corporations.
- 34. Apache and Outercurve Apache: Outercurve/CodePlex: ● Multiple projects ● Multiple projects ● Permissive license ● Various licenses ● Individual members ● Corporate backing ● Board oversight ● Individual governance One key difference: Microsoft backing, and each project provides own style and set of governance.
- 35. Apache and Python Apache: Python: ● Multiple projects ● Single project ● Permissive license ● Permissive license ● Individual members ● Individual members ● Independent board ● Guido as BDFL One key difference: Python focuses on just the programming language.
- 36. Apache and FSF / GNU Apache: FSF / GNU: ● Multiple projects ● Multiple projects ● Permissive license ● Copyleft license ● License contribution ● Holds copyright ● Individual members ● Corporate staff One key difference: FSF advocates software freedom as ideology.
- 37. Apache and Mozilla Apache: Mozilla: ● Multiple projects ● Multiple projects ● Permissive license ● Semi-copyleft license ● Individual members ● Corporate staff ● No specific technical ● End user project focus focus One key difference: Mozilla's end user focus means different level of marketing, trademark, and release management.
- 38. Apache Similarities ● What's similar about these groups? ● Most explicitly adopted parts of Apache Way ● Voting; consensus & community; merit ● Independent foundations ● Several have explicitly noted the copying of their ways from Apache
- 39. Colophon ● Credits – Past Apache Way slides by Jim Jagielski – & Justin Erenkrantz – Collective wisdom of the Apache Membership ● Apache OpenOffice 3.4 Impress ● Open Sans fonts http://communityovercode.com/2012/05/camelone-presentation/
- 40. Thank You! • Questions? @shanecurcuru • Learn more about Apache: http://community.apache.org/
- 41. Apache's 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.”
Notas del editor
- 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 Apache Software Foundation, or ASF, is actually the most important, yet probably least interesting component here. But it's important to understand how the Foundation behind the projects ensures their longevity.
- 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.
- That's what the Foundation as a corporation itself is. Here is the how – how we require our projects to operate, so that they can remain independent and long-lived communities providing free software.
- 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.
- For those wondering “but where's the code”, you're right – the Foundation itself doesn't really do much interesting to the outside world, other than providing a stable home. It's the Apache projects that do the work!
- 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.
- This last bullet is critical for any development managers out there. “powerplanting”, or building a complete great new feature and then shoving it into a project is not a best practice. This bypasses the community, and often leads to resentment. Besides, who's to say if the community had had a chance to comment, that they wouldn't have come up with a better feature? Large engineering teams take note: make sure you're doing your techincal planning and discussions on the list . This allows the community to participate. IT also allows your other fellow employees – who are not yet committers – to show their individual merit to the community.
- 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.