Apache: The Open Source Way
•
2 recomendaciones•617 vistas
AFDEL presentation on Apache Way
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Similar a Apache: The Open Source Way
Similar a Apache: The Open Source Way (20)
Último
Último (20)
Apache: The Open Source Way
- 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. 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. /me Olivier Lamy (@olamy ) (twitter.com/olamy) https://www.slideshare.net/olamy Apache Software Foundation Member VP, Maven PMCs: Maven, Archiva, Tomcat, Sqoop, DirectMemory, Kalumet Commiter: Commons Jenkins etc.. (add bugs in various opensource projects) Also a Software Architect at Talend
- 4. Credits Slides largely inspired from Shane Curcuru presentation: http://communityovercode.com/2012/05/camelo ne-2012-presentation/
- 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 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 Appoint officers upon PMC request Report monthly Report quarterly PMCs Officers 100++ ~10 Define organizational & legal policies Committers Nominate, elect Vote for ~3,000 new committers project releases 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, Rich Bowen, Ross Gardler 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 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. The Apache Way How does it works 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
- 16. Apache Way: Merit Merit is based on actual accomplishments within a project Existing community measures value Merit never expires Merit is not transferable
- 17. Apache Way: Peer-based Developers represent themselves All committer/PMC votes equal +/-1 Healthy communities create healthy code Diverse communities survive
- 18. 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
- 19. 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
- 20. 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
- 21. Apache Way: Participation Committers participate as individuals Expected to wear appropriate “hat” Releases must have three binding +1 votes Ensures multiple and independent eyes Corporations are never made committers, members, nor PMC members
- 22. 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.”
- 23. 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)
- 24. 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
- 25. 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 ... 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: 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
- 27. 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,...
- 28. 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
- 29. 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
- 30. 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.
- 31. 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.
- 32. 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.
- 33. 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.
- 34. 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
- 35. 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.” “Community over Code”
- 36. Thank You! Questions? @olamy Learn more about Apache: http://community.apache.org/
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 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.