Running Successful Open Source Projects


Published on

How to run a successful FOSS project and foster healthy Open Source Communities

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Running Successful Open Source Projects

  1. 1. Running a SuccessfulOpen Source ProjectJim Jagielski
  2. 2. AgendaIntroductionWhat exactly is “Open Source”“Running” a successful open source communityA History of the Apache Software FoundationRunning a successful open source projectApache HTTP Server, Tomcat, ...
  3. 3. IntroductionJim JagielskiLongest still-active developer/contributorCo-founder of the ASFMember, Director and ChairmanCTO/Chief Architect for the Covalent Division ofSpringSource
  4. 4. The draw of Open SourceHaving a real impact in the development and direction of ITPersonal satisfaction: I wrote that!Sense of membership in a communitySense of accomplishment - very quick turnaround timesDevelopers and engineers love to tinker - huge opportunityto do so
  5. 5. What is Open Source?Open Source LicensingOSI ApprovedOpen Source Developmentala, the Apache Software FoundationFree SoftwareAs in Free Speech, not Free Beer
  6. 6. What is Open Source?Basically, it’s a “new” way to develop, license and distributecodeActually, there was “open source” even before it was calledthatThe key technologies behind the Internet and the Web are allOpen Source based
  7. 7. Why Open Source?Access to the source codeAvoid vendor lock-in (or worse!)Much better softwareBetter security record (more eyes)Much more nimble development - frequent releasesDirect user input
  8. 8. Open Source FUDNo quality or quality controlPrevents or slows developmentHave to “give it away for free”No real innovation
  9. 9. The ASFASF == The Apache Software FoundationBefore the ASF there was “The Apache Group”The ASF was incorporated in 1999
  10. 10. The ASFNon-profit corporation founded in 1999501( c )3 charityVolunteer organizationVirtual world-wide organizationExists to provide the organizational, legal, and financialsupport for various OSS projects
  11. 11. The ASF - thenStarted with 21 members2 projectsAll servers and services donated
  12. 12. The ASF - nowWe have 259 members...>60 TLPs~25 Incubator podlingsTons of committers (literally)(Over 1650 people)Very large and growing infrastructure
  13. 13. The ASF’s MissionProvide open source software to the public free of chargeProvide a foundation for open, collaborative softwaredevelopment projects by supplying hardware,communication, and business infrastructureCreate an independent legal entity to which companies andindividuals can donate resources and be assured that thoseresources will be used for the public benefit
  14. 14. The ASF’s MissionProvide a means for individual volunteers to be shelteredfrom legal suits directed at the Foundation’s projectsProtect the ‘Apache’ brand, as applied to its softwareproducts, from being abused by other organizationsProvide legal and technical infrastructure for open sourcesoftware development and to perform appropriate oversightof such
  15. 15. How We WorkThe Apache Software Foundation provides support for theApache community of open-source software projects. TheApache projects are characterized by a collaborative,consensus based development process, an open andpragmatic software license, and a desire to create highquality software that leads the way in its field. We considerourselves not simply a group of projects sharing a server, butrather a community of developers and users.
  16. 16. How We Work, Take 2Community over codeOur code should be exceptional
  17. 17. Structure of the ASF - devVolunteer Driven OrganizationSoftware Projects are managed by Project ManagementCommittees (PMCs)PMCs vote in new PMC members and committersAt the end of the day: People / Individual focused
  18. 18. Structure of the ASF - legalMember-based corporation - individuals onlyMembers nominate and elect new membersMembers elect a board - 9 seatsSemi-annual meetings via IRCEach PMC has a Chair - eyes and ears of the board (oversightonly)
  19. 19. ASF “Org Chart”Development AdministrativeUsersPatchers/BuggersContributorsCommittersPMC MembersMembersOfficersBoard
  20. 20. The Apache WayAlthough the term is deprecated, “The Apache Way” relatesto how the ASF (and its projects) work and operateBasically, the least common denominators on how PMCsoperate
  21. 21. Basic MemesMeritocracyPeer-basedConsensus decision makingCollaborative developmentResponsible oversight
  22. 22. Meritocracy“Govern by Merit”Merit is based on what you doMerit never expiresThose with merit, get more responsibility
  23. 23. Peer-basedDevelopers represent themselves - individualsMutual trust and respectAll votes hold the same weightCommunity over codeHealthy communities create healthy codePoisonous communities don’t
  24. 24. Why Community > CodeSince we are all volunteers, people’s time and interestschangeA healthy community is “warm and inviting” and encouragesa continued influx of developersPoisonous people/communities turn people off, and theproject will dieEnd result - better code, long-term code
  25. 25. Consensus decision makingKey is the idea of voting+1 - yes+0 - no real comment-1 - vetoSometimes you’ll also see stuff like -0, -0.5, etc...
  26. 26. VotingThe main intent is to gauge developer acceptanceVetos must be justifiable and have sound technical meritIf valid, Vetos cannot be overruledVetos are very rare
  27. 27. Commit ProcessReview Then Commit (RTC)A patch is submitted to the project for inclusionIf at least 3 +1s and no -1s, code is committedGood for stable branchesEnsures enough “eyes on the code” on a direct-to-releasepath
  28. 28. Commit ProcessCommit Then Review (CTR)A patch is committed directly to the codeReview Process happens post commitGood for development branchesDepends on people doing reviews after the factAllows very fast development
  29. 29. Commit ProcessLazy Consensusvariant 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
  30. 30. Collaborative DevelopmentCode is developed by the communityVoting ensures at least 3 active developersDevelopment done online and on-listIf it didn’t happen on-list, it didn’t happen
  31. 31. Collaborative DevelopmentMailing lists are the preferred methodArchivedAsynchronousAvailable to anyone - public list
  32. 32. Collaborative DevelopmentOther methods are OK, if not primaryWikisIRCF2FAlways bring back to the list
  33. 33. Responsible OversightEnsure license complianceTrack IPQuality codeQuality community
  34. 34. The Apache IncubatorEntry point for all new projects and codebasesIndoctrinates the Apache Way to the podlingEnsures and tracks IP
  35. 35. The Apache License (AL)A liberal open source software license - BSD-likeBusiness friendlyRequires attributionIncludes Patent GrantEasily reused by other projects & organizations
  36. 36. Other LicensesGPL (copyleft)Derivative works also under GPLLinked works may also be under GPLViral nature may limit adoption
  37. 37. Other LicensesMPL / EPL / (L)GPLUsed mostly with platforms or librariesProtects the licensed code, but allows larger derivativeworks with different licensing“Give me fixes”
  38. 38. One True LicenseThere is no such thingLicensing is selected to address what you are trying to doIn general, Open Standards do better with AL-like license
  39. 39. Contributor License Agreementaka: iCLA (for individual)Required of all committersGuarantees:The person has the authority to commit the codeThat the ASF can relicense the codeDoes NOT assign copyright
  40. 40. Success Stories - HTTPDApache HTTP Server (“Apache”)Reference implementation of HTTPMost popular web server in existanceFound in numerous commercial web serversOracle, IBM,...Influenced countless more
  41. 41. Success Stories - HTTPDBy having a “free” and open source referenceimplementation, the drive to create a separate proprietaryversion was reduced.“Why spend time and money, when we can use this”This allowed HTTP (and the Web) to grow and STAY usable(compare to the old browser wars)
  42. 42. Success Stories - TomcatApache Tomcat (Servlet Container)The default standard servlet containerEach version maps to a specific spec.Bundled with numerous Java apps out thereLikely a major influence on the diminishing relevance ofJEE
  43. 43. Success Stories - OthersApache Geronimo (Server Framework - JEE )Not “just” a JEE serverApache Maven (Java project build/management tool)Another industry standardApache Logging, Axis, Struts, ...
  44. 44. Some Concluding ThoughtsTrust your developers AND your usersCommunication is keyOpen Source is NOT the Good Housekeeping Seal Of ApprovalBut don’t believe in all the FUD eitherSuccess is not measured in market share, but in adoption
  45. 45. Some Concluding ThoughtsOpen Source should have a viable business or emotionalreasonGive some thought to licensingMake it easier for developers and users to “join”Give them a reason to
  46. 46. Helpful linksThe Apache Software Foundationwww.apache.orgSpringSourcewww.springsource.comWant to help a great organization?
  47. 47. That’s ItThank you!Any questions?