• Save
Running Successful Open Source Projects
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Running Successful Open Source Projects

on

  • 412 views

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

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

Statistics

Views

Total Views
412
Views on SlideShare
412
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Running Successful Open Source Projects Presentation Transcript

  • 1. Running a SuccessfulOpen Source ProjectJim Jagielski
  • 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. IntroductionJim JagielskiLongest still-active developer/contributorCo-founder of the ASFMember, Director and ChairmanCTO/Chief Architect for the Covalent Division ofSpringSource
  • 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. What is Open Source?Open Source LicensingOSI ApprovedOpen Source Developmentala, the Apache Software FoundationFree SoftwareAs in Free Speech, not Free Beer
  • 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. 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. Open Source FUDNo quality or quality controlPrevents or slows developmentHave to “give it away for free”No real innovation
  • 9. The ASFASF == The Apache Software FoundationBefore the ASF there was “The Apache Group”The ASF was incorporated in 1999
  • 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. The ASF - thenStarted with 21 members2 projectsAll servers and services donated
  • 12. The ASF - nowWe have 259 members...>60 TLPs~25 Incubator podlingsTons of committers (literally)(Over 1650 people)Very large and growing infrastructure
  • 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. 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. 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. How We Work, Take 2Community over codeOur code should be exceptional
  • 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. 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. ASF “Org Chart”Development AdministrativeUsersPatchers/BuggersContributorsCommittersPMC MembersMembersOfficersBoard
  • 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. Basic MemesMeritocracyPeer-basedConsensus decision makingCollaborative developmentResponsible oversight
  • 22. Meritocracy“Govern by Merit”Merit is based on what you doMerit never expiresThose with merit, get more responsibility
  • 23. Peer-basedDevelopers represent themselves - individualsMutual trust and respectAll votes hold the same weightCommunity over codeHealthy communities create healthy codePoisonous communities don’t
  • 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. 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. 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. 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. 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. 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. 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. Collaborative DevelopmentMailing lists are the preferred methodArchivedAsynchronousAvailable to anyone - public list
  • 32. Collaborative DevelopmentOther methods are OK, if not primaryWikisIRCF2FAlways bring back to the list
  • 33. Responsible OversightEnsure license complianceTrack IPQuality codeQuality community
  • 34. The Apache IncubatorEntry point for all new projects and codebasesIndoctrinates the Apache Way to the podlingEnsures and tracks IP
  • 35. The Apache License (AL)A liberal open source software license - BSD-likeBusiness friendlyRequires attributionIncludes Patent GrantEasily reused by other projects & organizations
  • 36. Other LicensesGPL (copyleft)Derivative works also under GPLLinked works may also be under GPLViral nature may limit adoption
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Helpful linksThe Apache Software Foundationwww.apache.orgSpringSourcewww.springsource.comWant to help a great organization?www.marylandstateboychoir.org
  • 47. That’s ItThank you!Any questions?