Apache: Code, Community and Open Source
4 likes763 views
The Apache Software Foundation (ASF), established in 1999 as a non-profit organization, aims to provide legal, organizational, and financial support for open source software projects. It promotes a collaborative development process characterized by meritocracy, peer-based decision making, and responsible oversight, ensuring quality and community engagement. The ASF also emphasizes the importance of protecting the Apache brand and fostering diverse, healthy communities for successful software development.
Apache: Code, Community and Open Source
- 1. Apache:! Code, Community and Open Source! Jim Jagielski || @jimjag
- 2. Agenda! • Introduction • Overview of the ASF • The What and Why of “Open Source” • The Lessons Learned by the ASF - The Apache Way
- 3. Introduction! • Jim Jagielski – Longest still-active developer/contributor – Co-founder of the ASF – Member, Director and ex-President, ex-Chairman, … – Director: Outercurve and OSI (ex) – hacker! – Sr. Director, Tech Fellows Program @ Capital One
- 4. The ASF! • ASF == The Apache Software Foundation • Before the ASF there was “The Apache Group” • The ASF was incorporated in 1999
- 5. The ASF! • Non-profit corporation founded in 1999 • 501( c )3 public charity • Volunteer organization (The ASF doesn’t pay anyone to work on Apache projects) • Virtual world-wide organization - Membership of Individuals • Exists to provide the organizational, legal, and financial support for various OSS projects - let the developers develop
- 6. Structure of the ASF - legal! • Member-based corporation - individuals only • Members nominate and elect new members • Members elect a board - 9 seats • Semi-annual meetings via IRC • Each PMC has a Chair - eyes and ears of the board (oversight only)
- 7. ASF “Org Chart”! • Development Administrative Users Patchers/Buggers Contributors Committers PMC Members Members Officers Board ~400 9 ~160 ~4500 ~2000 Technical Oversight Organizational Oversight PMCs (TLPs) ~150 Elects ReportsAppoints Creates & Updates
- 8. Issues with Dual Stacks! • Despite clear differentiation, sometimes there are leaks – eg: PMC chair seen as “lead” developer • Sometimes officers are assumed to have too much power if they venture into development issues – “hats”
- 9. The ASF’s Mission! • Provide open source software to the public free of charge • Provide a foundation for open, collaborative software development projects by supplying hardware, communication, and business infrastructure • Create an independent legal entity to which companies and individuals can donate resources and be assured that those resources will be used for the public benefit
- 10. The ASF’s Mission! • Provide a means for individual volunteers to be sheltered from legal suits directed at the Foundation’s projects • Protect the ‘Apache’ brand, as applied to its software products, from being abused by other organizations • Provide legal and technical infrastructure for open source software development and to perform appropriate oversight of such software
- 11. Vision Statement! • The Apache Software Foundation provides support for the Apache community of open-source software projects. The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users.
- 12. Vision Statement,! Take 2! • Community created code • Our code should be exceptional
- 13. Why Open Source?! • Access to the source code • Avoid vendor lock-in (or worse!) • Much better software • Better security record (more eyes) • Much more nimble development - frequent releases • Direct user input
- 14. The draw of Open Source! • Having a real impact in the development and direction of IT • Personal satisfaction: I wrote that! • Sense of membership in a community • Sense of accomplishment - very quick turnaround times • Developers and engineers love to tinker - huge opportunity to do so
- 15. Open Source FUD! • No quality or quality control • Prevents or slows development • Have to “give it away for free” • No real innovation
- 16. What is Open Source?! • Open Source Licensing – OSI Approved • Free Software – As in Free Speech, not Free Beer • Open Source Methodology (secondary) – ala, the Apache Software Foundation
- 17. Open Source Licenses! • Give Me Credit – AL, BSD, MIT • Give Me Fixes – (L)GPL, EPL, MPL • Give Me Everything – GPL, AGPL
- 18. The Apache License (AL)! • A liberal open source software license - BSD-like • Business friendly • Requires attribution • Includes Patent Grant • Easily reused by other projects & organizations
- 19. License Differences! • Mainly involve the licensing of derivative works • Only really applies during (re)distribution of work • Where the “freedom” should be mostly focused: the user or the code itself • Be careful when mixing licenses!
- 20. One True License! • There is no such thing • Licensing is selected to address what you are trying to do • In general, Open Standards do better with AL-like license • If wide adoption is important to you: again AL.
- 21. The Apache Way! • Although the term is deprecated, “The Apache Way” relates to how the ASF (and its projects) work and operate • Basically, the least common denominators on how PMCs operate
- 22. Why focus on ASF ?! h"p://webmink.com/essays/#OBR h"p://www.zdnet.com/blog/open-‐source/oracle-‐gives-‐ openoffice-‐to-‐apache/9035
- 23. Basic Memes! • Meritocracy • Peer-based • Consensus decision making • Collaborative development • Responsible oversight • Individual Participation
- 24. Meritocracy! • “Govern by Merit” • Merit is based on what you do • Merit never expires • Those with more merit, get more responsibility • Provides incentive to Do More • It’s NOT a dirty word • aka “do-acracy”
- 25. Peer-based! • Developers represent themselves - individuals • Mutual trust and respect • All votes hold the same weight (no BDFL) • Community created code – Healthy communities create healthy code – Poisonous communities don’t • Feel as part of a community
- 26. Why Community -> Code! • Since we are all volunteers, people’s time and interests change • A healthy community is “warm and inviting” and encourages a continued influx of developers • Poisonous people/communities turn people off, and the project will die • Diversity ensures survivability • End result - better code, long-term code
- 27. Consensus decision making! • Key is the idea of voting – +1 - yes – +0 - no real comment – -1 - veto • Sometimes you’ll also see stuff like -0, -0.5, etc...
- 28. Voting! • The main intent is to gauge developer acceptance • Vetos must be justifiable and have sound technical merit • If valid, Vetos cannot be overruled • Vetos are very rare
- 29. Commit Process! • Review Then Commit (RTC) – A patch is submitted to the project for inclusion – If at least 3 +1s and no -1s, code is committed – Good for stable branches – Ensures enough “eyes on the code” on a direct-to- release path
- 30. Commit Process! • Commit Then Review (CTR) – A patch is committed directly to the code – Review Process happens post commit – Good for development branches – Depends on people doing reviews after the fact – Allows very fast development
- 31. Commit Process! • Lazy Consensus – variant of RTC – “I plan on committing this in 3 days” – Provides opportunity for oversight, but with known “deadline” – As always, can be vetoed after the fact
- 32. Collaborative Development! • Code is developed by the community • Voting ensures at least 3 active developers • Development done online and on-list – If it didn’t happen on-list, it didn’t happen
- 33. Collaborative Development! • Mailing lists are the preferred method – Archived – Asynchronous – Available to anyone - public list
- 34. Collaborative Development! • Other methods are OK, if not primary – Wikis – IRC – F2F • Always bring back to the list
- 35. Responsible Oversight! • Ensure license compliance • Track IP • Quality code • Quality community
- 36. Look Familiar?! • These concepts are not new or unique • Best practices regarding how the Scientific and Health community works
- 37. Publish or Perish! • In Open Source, frequent releases indicate healthy activity • What is collaborative s/w development other than peer review? • Think how restrictive research would be w/o open communication
- 38. The Apache Incubator! • Entry point for all new projects and codebases • Indoctrinates the Apache Way to the podling • Ensures and tracks IP
- 39. Contributor License Agreement! • aka: iCLA (for individual) • Required of all committers • Guarantees: – The person has the authority to commit the code – That the ASF can relicense the code • Does NOT assign copyright
- 40. Development! • The ASF never pays for development of projects • Some contributors are corporate sponsored, some aren’t but as far as the ASF is concerned it makes no difference! • Diversity == Independence • git-like mega merges are counter-productive • Code is one form of contributing, not the only form.
- 41. The ASF Is Vital! • Foundations (independent) are critical for widespread adoption of s/w • ASF: totally vendor neutral - Sponsors don’t control/ manage/direct the foundation nor projects • “There are other ways of doing things, what we’ve been doing has simply be proven to be one of the best.”
- 42. That’s It! • Thank you! • Any questions? – @jimjag – www.slideshare.net/jimjag – youtube.com/user/jimjagski