All Things Open 2015 Presentation - Bringing Commercial Software to Open Source
•Download as PPTX, PDF•
1 like•546 views
In this talk, Pivotal Software will share its experiences of being a primary sponsor for a dozen open source communities including Cloud Foundry, Spring, RabbitMQ, Redis, and its recent experience with open sourcing the core of its in-memory database Pivotal GemFire and its advanced enterprise SQL-on-Hadoop analytics engine Pivotal HAWQ. We will cover how these mature, blockbuster enterprise products have transitioned into Apache Software Foundation Incubator and have embraced the “Apache Way” governance model. Finally, with all of these communities and their products having highly varied histories, licensing, and governance models we will share some of the lessons we’ve learned in the fine art of delivering this phenomenal amount of open source innovation to the enterprise customers. Session outline: Reasons for Open Sourcing a Commercial Product Business + Legal choices: Licensing, Governance & Ownership Engineering Choices: Incorporating Components, Collaborative Tools Technical Steps in Bringing a Project to Open Source Pivotal’s Experience, from Commercially Supported OSS to Standalone Open Source Foundations, to ASF http://allthingsopen.org/talks/engineering-business-legal-choices-for-bringing-commercial-software-to-open-source-2/
Recommended
Recommended
More Related Content
Similar to All Things Open 2015 Presentation - Bringing Commercial Software to Open Source
Similar to All Things Open 2015 Presentation - Bringing Commercial Software to Open Source (20)
Recently uploaded
Recently uploaded (20)
All Things Open 2015 Presentation - Bringing Commercial Software to Open Source
- 2. SECTION1 Overview SECTION2 Business&LegalChoices SECTION3 Engineering&CommunityChoices SECTION4 Q&A Agenda
- 3. 1. Overview ● Whychoosetotakeyourcommercialsoftwaretoopensource? ● WhatOSSmodelwillaccomplishyourgoals? ● Howdoyouaddresstheweightofexistingcodeandculturalhistory? ● Whattypeofcommunitydoyouwanttocreate? ● Whatopensourcelicenseshouldyouattachtotheproject? ● Whatgovernanceanddevelopmentmodels?
- 4. 1.Overview|Pivotal’spathstoOpenSource VitalStats: 3.25MLinesofCode;5YEARS OF DEVELOPMENT VitalStats: 2MLinesofCode;12YEARS OF DEVELOPMENT VitalStats: 1.3MLinesofCode;15+YEARS OF DEVELOPMENT WHATIsIt?:Open sourcecloudcomputing platformasaservice WhatIsIt?:ApplicationDevelopment Platform WhatIs It?Distributed,in-memorydatabase forscale-outapplications WhatDoesItDo:Supportsthefull applicationlifecycle,fromdevelopment, throughtestingstages,todeployment, in multipleclouds LicenseType: Apache2.0 WhatDoesitDo?helps Developersbuild simple, portable,fastandJVM-basedcloud- nativeapplications LicenseType: Apache2.0 WhatDoesitDo?Featureselasticperformance, databaseconsistency,andresilient clustering LicenseType: Apache2.0
- 5. 5 2.Business&LegalChoices|OSSBusinessModels 1. “Pure”OpenSource 2. CommunityOpenSource 3. Services+SupportOpenSource 4. SubscriptionOpenSource 5. Multi-LicenseOpenSource
- 8. • CompanyOwnsIt: Advantages -Flexibility,youdeterminedevelopmentandgovernance modelsandlicensing,fasttracktocommits,goodwillassociated withtheOSSproject,Easylicensing,andeasieradoption Disadvantages -Noexistingcommunitytotapinto,distrustof single-vendoropensource 2.Business&LegalChoices|Choice#1:WhoOwnsIt?
- 9. • ExistingOSSFoundationOwnsIt: Advantages -Leverage existingbigdatacommunities,establisheddevelopmentand governancemodels,Apache2.0licenseaslicenseofchoice Disadvantages -ASFisaboutactivecommunities,nothosting;mostlyEnglish, projectswithnon-trivialinfrastructurerequirements,UI-centricprojectsnot doingwell,notaplaceforcorporatecollaboration,largescaleplatformprojects notagreatfit,projectswithalotofpatents 2.Business&LegalChoices|Choice#1:WhoOwnsIt?
- 10. • NewOSSFoundationOwnsIt: Advantages -Bringing togethercontributorscommittedtothegrowthofabroad, openecosystem;morecontroloverdevelopment,governancemodel;scaleofproject cannotnotbeaccomplishedwithoutwidespreadadoption, rapidinnovation Disadvantages -Singlevendorbaggage, cedingcontroloveryourproducts, enablingyourcompetition 2.Business&LegalChoices|Choice#1:WhoOwnsIt?
- 11. Licensesareastrategicintellectualpropertyweaponandshieldconsistingoflegaltoolsof copyrights,patentsandtrademarks 2.Business&LegalChoices|Choice#2:WhatOSSLicense?1. Isit anOSI-approvedlicense? 2. Dowewant tobuildacommunity/encourageadoption? 3. Whatcommunityarewetryingto build? 4. Dowewant ourcodeusedinclosedsource applicationsbycompetitors? 5. Dowewanttodiscourageforking? 6. Whatisthepublic perceptionof thelicensewe choose? 7. Whatlicensewillbethemost efficient/easiestto use? 8. Whatlicensesprotect our intellectualproperty? 9. How muchlicensereciprocity isrequired? 10. Whatprotections do we wantinplaceforpatentlicensing&litigation?
- 12. RESTRICTIVEPERMISSIVE GNUGeneral PublicLicense,v.2 • Attribution • Copyright license • Implied patent license • Attribution • Copyleft • Copyright license • Implied patent license • Attribution • Weakcopyleft • Expresspatentlicense • Copyright license • Patentretaliation • Attribution • Strongcopyleft • Broadexpresspatentlicense • Copyright license • Patentretaliation • Attribution • Expresspatentlicense • Copyright license • Patentretaliation 2.Business&LegalChoices|Choice#2:WhatOSSLicense?
- 15. • NewOSSFoundationOwnsIt: Governance-“GovernancebyContribution,”fosterscontributionfromabroad communityofdevelopers,users,customers,partners,ISVs,whileadvancing the developmentofthePaaSatextremevelocity Development-CFF“Dojos”encourageagile engineering,pairprogramming, daily standups,andpublicstorytrackers 2.Business&LegalChoices|Choice#3:Gov/DevModel?
- 16. 1. Scanningyourcode a. Earlyprep -knockouteasyproblems b. Component license compatibility c. Securityissues 2. Correctingcodeissues a. Fixingmust-doissuesfromscanresultsbeforepostingcode b. Remove customerandpersonalinformation oftenfoundincomments 3.Engineering&CommunityChoices|ReadyingCode
- 17. 4.LicenseCompatibility-APACHE2.0EXAMPLE 3.Engineering&CommunityChoices|ReadyingCode Fullycompatible LimitedCompatibility NotCompatible ApacheV2&V1.1 BSD MIT/X11 W3CSoftwareLicense AcademicFreeLicense3.0 MicrosoftPublicLicense CreativeCommons Attribution EclipseDistributionLicense1.0 UnicodeLicenseAgreement CDDL CPL EPL IPL MPL1.0, 1.1,2.0 OPL Open SoftwareLicense3.0 ErlangPublicLicense BinaryCodeLicense GNUGPL1,2,3 GNULPGL 2,2.1,3 AfferoGPL3 NPL1.0,1.1 QPL SleepycatLicense MicrosoftLimitedPublicLicense CodeProjectOpen License
- 18. 3.Engineering&CommunityChoices| BrandingandAdoption 1. Naming&branding -Optionsdependonownership&governancechosen a. Samenamebetweencommercial &open source? b. Separatebrandsbetweencommercial &opensource i. Givebrandequitytonewcommercial sourceorkeep? ii. Restrictions ifseparatenamesownedbyseparateentities 2. Drivingadoption a. DifferentFactions:Committers,Contributors&Users b. Incorporation intootherprojects
- 19. 3.Engineering&CommunityChoices| Redefineyourdevelopmentprocesstofityourossmodel ● CertainTypesofContributors andCommittersallowed ● AboutEngineering Process ● DoYouAcceptExernal Contributions ● DoyouallowExternal Committers? ● Whatistherelationship betweentheOSScodeandany Commercial Release? ● Recruiting Existing CommittersandExternal Contributors ● Engineering ProcessDictated byFoundation-AdaptorDie
- 20. 3.Engineering&CommunityChoices| EnsuringIPCleanliness 1. Accepting GrantsofCodeasBenevolent Dictator a. CLA/ICLAProcess-License Choices b. Ensuring Chain ofTitle 2. InitialGrantsofCodetoanExternalFoundation a. ASFasexample i. SoftwareGrantAgreement ii. CompanyandIndividual a. PivotalCFasexample i. SoftwareGrantto Pivotal/accepted CCLAs/ICLAS ii. Workingwith yourcustomers 3. OngoingIPCleanliness a. CodeScans
- 21. 3.Engineering&CommunityChoices| DevelopingYourOSSCommunity 1. Howwillyourengineeringprocessworkbetweenopensource&commercialversions? 2. Whocancommit&howareexternalcontributionsaccepted? 3. Howareopensourceuserssupported? 4. Howdoyoumaintain relationswithyouropensourcecommunity?
Editor's Notes
- In 2013, we created a company that would allow customers to go on the journey to become a digital business, using software and data in innovative ways to both seize opportunities and protect themselves from disruptive competition. As we embarked on that journey with our customers, we quickly learned that in order to assist our customers in being innovative and seizing opportunities, we ourselves needed to do the same. Open source has been a momentous part of that journey. In this talk, we’ll share Pivotal’s experiencesas a primary sponsor of several open source communities including Cloud Foundry, Spring, and Apache Geode (incubating). We’ll review the reasons for open sourcing a commercial product, the business and legal choices you’ll make along the way, how those choices affect engineering, executing the transition to open source, and Pivotal’s experience bringing OSS to market.
- Why choose open source? Crucial question to answer because determines what kind of communities you will ultimately focus on. You’re a corporation that has made the decision to go to open source. What are the strategic choices you now need to make on your road to becoming open? The “how” is as important as the why. Software is covered by patents and copyrights, so considerations of ownership and licensing need to be addressed. The weight of existing code and cultural history are important considerations and affect how the community is built and what it looks like. Issues include: what license to attach to the project the tool platform to support collaborative development (managing source code versions, distributing built software, handling communications, logging issues and bugs). what kind of community do you want to develop? what governance type do you want? We’ll discuss these choices in the context of three different Apache-licensed based projects at Pivotal.
- Pivotal employs committers, project leads and contributors to a variety of open source projects and community initiatives, each with different development histories and governance models - how did we fit them all together? Cover the Pivotal Story: one company’s relationship with Open Source communities. Were the choices defined by ones we designed from scratch as Pivotal (and not as SpringSource, VMware). Would we have made different choices? On the flip side, Pivotal being an EMC affiliate affected our choices. Examples: Cloud Foundry® is an open source Platform as a Service (PaaS), sponsored and led by Pivotal®, with contributions from a large ecosystem of organizations and individual developers. Cloud Foundry provides users with a choice of clouds, developer frameworks and application services, while increasing a user’s ability to build, test and scale applications. Cloud Foundry is released under the terms of the Apache License.’ Spring is the most popular and complete application development framework for enterprise Java. Spring projects provide comprehensive infrastructure support for developing Java applications. Millions of developers use Spring to build modern Web and enterprise applications. The Spring Framework is released under version 2.0 of the Apache License. The popular Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. Redis is an open source, networked, in-memory, key-value data store with optional durability. Written in ANSI C, it is often referred to as a data structure server, because keys can contain strings, hashes, lists, sets and sorted sets. Redis is open source software released under the terms of the three clause BSD license. Redis is the most popular key-value store in the cloud. RabbitMQ is a complete and highly-reliable enterprise messaging system, based on the AMQP standard. RabbitMQ is easy to use, runs on all major operating systems and supports a huge number of developer platforms. It is both open source and commercially supported. Released under version 1.1 of the Mozilla Public License, RabbitMQ is the most popular AMQP implementation on the planet. MADlib is an open source library for scalable in-database analytics. It provides data-parallel implementations of mathematical, statistical and machine-learning methods for structured and unstructured data. Apache Tomcat is a popular open source application server that implements the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat powers numerous large-scale, mission-critical web applications (including those written in Spring) across a diverse range of industries and organizations. It is released under the Apache License version 2. Apache HTTP Server is the most popular web server on the Internet. Powering over 100 million websites, it is one of the oldest open source projects in use today. Apache HTTP Server provides functionality around authentication, security and content delivery. It is released under the Apache License version 2. The Eclipse Foundation is a not-for-profit, member-supported corporation that hosts the Eclipse projects. Full details of Eclipse and the Eclipse Foundation are available athttp://www.eclipse.org. Pivotal is an Eclipse solutions member of the Eclipse Foundation and participates in several projects at Eclipse, including JDT Core, AJDT, AspectJ, Orion and Flux. Apache Geode is the open source distributed, in-memory database for scale-out applications. What is APACHE GEODE? An open source distributed, in memory database for scale-out applications Features: Elastic Performance: All data is stored in-memory for low latency. Performance scales linearly as nodes are added. Data is distributed automatically between nodes to optimize performance. Database consistency: Data is persisted in write-optimized disk storage. Consistency checking is configurable between highest performance caching and ACID transactions. Resilient clustering: Clusters fail-over to other nodes in case of failures, and rebalance remaining resources. Clusters self-heal when nodes return to operation. Details behind GemFire/Geode: Over a 1000 person years invested into cutting edge R&D Thousands of production customers in very demanding verticals Cutting edge use cases that have shaped product thinking Tens of thousands of distributed , scaled up tests that can randomize every aspect of the product We donated everything but the kitchen sink, and more code drops are imminent Why OSS? Open Source Software is fundamentally changing buying patterns Developers have to endorse product selection (No longer CIO handshake) Community endorsement is key to product visibility Open source credentials attract the best developers Vendor credibility directly tied to street credibility of product Align with the tides of history Customers increasingly asking to participate in product development Allow product development to happen with full transparency Apache is where you go to build open source street cred. Cloud Foundry® is an open source Platform as a Service (PaaS), sponsored and led by Pivotal®, with contributions from a large ecosystem of organizations and individual developers. Cloud Foundry provides users with a choice of clouds, developer frameworks and application services, while increasing a user’s ability to build, test and scale applications. Cloud Foundry is released under the terms of the Apache License.’ Not only did we start from day one on an open-source basis, but we went out of our way to recruit others in the industry to join with us in a Foundation. Our partners in the governance of that foundation include IBM, HP, SAP, Intel, and about 40 other companies. The biggest technology companies in the world are rallying behind Cloud Foundry to make it the open cloud standard for the industry and allow enterprises of any size and scale to build modern cloud applications, whether that really starts in their data center or they start using hybrid or public cloud infrastructures. Spring is the most popular and complete application development framework for enterprise Java. Spring projects provide comprehensive infrastructure support for developing Java applications. Millions of developers use Spring to build modern Web and enterprise applications. The Spring Framework is released under version 2.0 of the Apache License. 12 years of OSS development.
- Pure Open Source: no single owner Analysis: No $$ in pure OSS. Community Open Source: Owned by a community or legal entity representing that community (e.g., Linux Foundation, Apache Software Foundation). Community members typically don’t derive direct revenues from the software but subsidize it from ancillary products and services. Source code of projects is available under one license, and anyone can enter the market and generate revenue from the project. Analysis: supported by a community of users/vendors, but not meant for profit (other than in vendor add-ons - closed source proprietary tools built upon an open platform). Pure-Play Open Source: Support Contracts: (e.g., MySQL (OS support + dual licensing of client libraries). Services Contracts: consulting services contracts on open source packages. Analysis: Risky because everyone has equal access to source code, and pricing is undercut - race to zero on price. “So here is the conundrum facing enterprise infrastructure software companies: You can no longer win with a closed-source platform, and you can't build a successful stand-alone company purely on open source.” Mike Olson, Cloudera: https://www.linkedin.com/pulse/article/20131003190011-29380071-the-cloudera-model Enterprise Subscriptions to OSS Distributions (aka “Corporate Distributions”): Corporate distributions of open source projects: RedHat (enterprise subscription to Linux) Multi-Licensing: Multi-licensing is the practice of distributing software under two or more different sets of terms and conditions. This may mean multiple different software licenses or sets of licenses. Prefixes may be used to indicate the number of licenses used, e.g. dual-licensed for software licensed under two different licenses. When software is multi-licensed, recipients can choose the terms under which they want to use or distribute the software. The distributor may or may not apply a fee to either option. The two usual motivations for multi-licensing are license compatibility and market segregation based business models. (e.g., Cloudera - “open core” model) Single-Vendor Commercial Open Source: owned by a single legal entity with the purpose of deriving revenues from the software. The benefits of single-vendor commercial open source stem from the creation of an active and engaged user community around the product while at the same time preventing the emergence of competitors from that community. In a nutshell, this community helps the company get to market faster, create a superior product, and sell more easily, all at a lower cost than possible for traditional competitors. In exchange, the company offers a professionally developed product of compelling value to the community that this community is free to use under an open source license. Characteristics: Do not accept contributions to the code base If they do accept them, transfer of copyright from creator to the company (or license) Because vendor owns the copyright, vendor can license it however it wants Typically under reciprocal license like GPL to drive adoption/stall competitors Revenue sources: Core product. Some customers pay for the software, simply because they cannot accept the open source license. Mostly, this is for legal reasons. For example, companies may pay for a commercial license to receive certification or indemnification or to embed the software into their products without having their own code touch open source code. Whole product. Commercial users pay for the utility derived from using the software. Increasingly, the free open source product does not provide the full utility, only a more comprehensive non-free commercial version does. To meet all requirements, commercial users have to upgrade from the free to the non-free version. Operational comfort. Customers also want to ensure that the software reliably fulfills its duty. Thus, they may be buying hotline and technical support, subscription services to bug fixes, or real-time systems monitoring. There are many such non-functional requirements that companies may want to buy, many of which are specific to the software at hand. Consulting services. Finally, customers may want to pay for training, documentation, and implementation services. Additional Resources: http://dirkriehle.com/publications/2009-2/the-commercial-open-source-business-model/ http://www.slideshare.net/faberNovel/businessmodels-opensource-en-125492
- Introduction We frequently hear that there are 3 ways for Enterprise Software to survive in the cloud era: Create own OSS ecosystem Align with existing one Get left behind But I don’t agree with that presumption - proprietary software isn’t going anywhere and just as there are incentives to go open source, there are equally valid incentives to stay proprietary. So the first question I always asked when someone approaches me to open source something is “should we open source this software?” What’s open sourcing going to do for us or the community? What is the Software? Consider the software around which a project and community is going to be built and what’s its relation to your business. Does it do something useful that has wide applicability? Or is it something that you’re just going to dump in github, call open source, and let die on the vine? OSS is all about the code, and without code there is no conversation - code creates gravity around which discussions are built. Why not stay proprietary? Total control over development, not dependent on others. Limited availability creates demand Secrecy/rapid response Lock-in customers What is motivating publication of software under an OSS license? All too often we hear OSS as the cure to all ills. What kind of open source project do you want this to be? Do you want to develop a community? What kind of community do you want to develop? Are you doing this just for “face value”? Open Source Choice Overview Who will own the software? Who will choose the license model? What governance/development model? the roles that project participants assume, the relationship to eachother, decision making, participation in the project, communication and sharing with the project team and community descent into chaos Development Control <-> Agreed upon <-> Accepted
- Single-Vendor Commercial Open Source: owned by a single legal entity with the purpose of deriving revenues from the software. The benefits of single-vendor commercial open source stem from the creation of an active and engaged user community around the product while at the same time preventing the emergence of competitors from that community. In a nutshell, this community helps the company get to market faster, create a superior product, and sell more easily, all at a lower cost than possible for traditional competitors. In exchange, the company offers a professionally developed product of compelling value to the community that this community is free to use under an open source license. Characteristics: Do not accept contributions to the code base If they do accept them, transfer of copyright from creator to the company (or license) Because vendor owns the copyright, vendor can license it however it wants Typically under reciprocal license like GPL to drive adoption/stall competitors Revenue sources: Core product. Some customers pay for the software, simply because they cannot accept the open source license. Mostly, this is for legal reasons. For example, companies may pay for a commercial license to receive certification or indemnification or to embed the software into their products without having their own code touch open source code. Whole product. Commercial users pay for the utility derived from using the software. Increasingly, the free open source product does not provide the full utility, only a more comprehensive non-free commercial version does. To meet all requirements, commercial users have to upgrade from the free to the non-free version. Operational comfort. Customers also want to ensure that the software reliably fulfills its duty. Thus, they may be buying hotline and technical support, subscription services to bug fixes, or real-time systems monitoring. There are many such non-functional requirements that companies may want to buy, many of which are specific to the software at hand. Consulting services. Finally, customers may want to pay for training, documentation, and implementation services.
- Advantages: Leverage existing Big Data communities Established development and governance models Apache 2.0 license becoming the license of choice for commercial OSS products. Disadvantages ASF is all about communities. For an awesome codebase that still has tons of usage but no community developing or actively maintaining it -- ASF is not a good place. (e.g., OpenSSL (arguably the most widely used piece of software) would've been kicked out from ASF. ASF is not a holding place for projects the way something like Software Freedom Conservancy is. If the community joins ASF it is expected to be interested in the Foundation, not just looking for hosting. It is expected to vote, participate, etc. There are many great projects with BDFLs (Linux, Python, Spring); ASF will be a bad place for a project like that. If your community has issues with open communications using mostly english -- ASF is a bad place. Projects with non-trivial infrastructure requirements are not a good candidate for ASF UI-centric projects are not having fun times in ASF. That is because there are NO good UI libraries available under ALv2 and if you can't have that fundamental dependency be at least an option under ALv2 -- you're not a good candidate for ASF. Projects requiring a lot of corporate collaboration are not happy campers at ASF (Java is a good example) Large scale platform projects (think OpenStack, CloudFoundry, etc.) may have trouble in ASF. Projects that need to deal with patents a lot (multimedialibraries are a good example here) may not be ideal candidates.
- Align with the Tides of History Enterprises want the ability to develop and deploy applications and have the freedom to seamlessly deploy those applications across a wide variety of cloud-based platforms Foundation for Cloud Foundry will bring together industry leaders committed to the growth of the open PaaS movement, working in concert toward the development of an open cloud architecture that will enable a broad, open ecosystem that will allow many to contribute and benefit The scale of this project could not be accomplished without widespread adoption Flexibility and Control, Rapid Innovation, Multi-Vendor Support
- Align with the Tides of History Enterprises want the ability to develop and deploy applications and have the freedom to seamlessly deploy those applications across a wide variety of cloud-based platforms Foundation for Cloud Foundry will bring together industry leaders committed to the growth of the open PaaS movement, working in concert toward the development of an open cloud architecture that will enable a broad, open ecosystem that will allow many to contribute and benefit The scale of this project could not be accomplished without widespread adoption Flexibility and Control, Rapid Innovation, Multi-Vendor Support
- General The original purpose of open source licenses were to create software that could be freely used, modified, and shared. In corporations hands, however, the choice of an open source license is really a choice of how much you want to enable your competition to use the code you open source. There are 3 categories in the open source license spectrum: Permissive licenses: Minimal requirements about how the software can be redistributed. No guarantee that future generations of the software will remain free. (This is in contrast to licences which have reciprocity / share-alike requirements. When the software is being redistributed (either modified or unmodified), permissive licences permit the redistributor to restrict access to the modified source code, while copyleft licenses to do not allow this restriction. Copyleft licenses: general method for making a creative work as freely available to be modified, and requiring all modified and extended versions of the creative work to be free as well Weak copyleft licenses Generally used for the creation of software libraries, to allow other software to link to the library, and then be redistributed without the legal requirement for the work to be distributed under the library's copyleft license. Only changes to the weak-copylefted software itself become subject to the copyleft provisions of such a license, not changes to the software that links to it. This allows programs of any license to be compiled and linked against copylefted libraries , and then redistributed without any re-licensing required. Strong copyleft license Forbids linking or integration the subject work into larger works/projects Network Protective Closes a perceived application service provider "loophole" (the "ASP loophole") in the ordinary GPL, where, by using but not distributing the software, the copyleft provisions are not triggered License Summaries: BSD: Permissive license allows anyone to do anything with code with proper attribution and no warranty Pros: Postgres is BSD, encourages community, good public perception, compatible with other Pivotal OSS license types Cons: permits commercial use, permits private use, permits sublicensing, forking, Apache 2.0: Permissive license that provides express patent grant from contributors to users Pros: compatible with many OSS license types, encourages some community, good public perception, patent protection, defensive patent termination provision. Cons: Affiliate implications, permits commercial use, permits sublicensing, forking MPL 2.0: Weak copyleft license, hybrid of BSD/GPL seeks to balance concerns of proprietary and open source developers by allowing interoperability but pushing MPL-based code to the community (file-based copyleft) Pros: Apache compatible, explicit patent license, defensive patent termination provision, warranting original work so no CLA, encourages community, good public perception, compatible with other license types, permits only limited commercial use and limited private use Cons: permits commercial use, permits private use, permits sublicensing, some forking AGPL 3.0: For licensees distributing or using derived works, source code must be made available Pros: One-way Apache compatibility, no Affiliate implications, restricts commercial or internal use, patent grant, additional patent provisions strongly discourage patent claims by users, prevents forking Cons: bad perception in corporate community
- Single-Vendor Commercial Open Source: owned by a single legal entity with the purpose of deriving revenues from the software. The benefits of single-vendor commercial open source stem from the creation of an active and engaged user community around the product while at the same time preventing the emergence of competitors from that community. In a nutshell, this community helps the company get to market faster, create a superior product, and sell more easily, all at a lower cost than possible for traditional competitors. In exchange, the company offers a professionally developed product of compelling value to the community that this community is free to use under an open source license. Characteristics: Do not accept contributions to the code base If they do accept them, transfer of copyright from creator to the company (or license) Because vendor owns the copyright, vendor can license it however it wants Typically under reciprocal license like GPL to drive adoption/stall competitors Revenue sources: Core product. Some customers pay for the software, simply because they cannot accept the open source license. Mostly, this is for legal reasons. For example, companies may pay for a commercial license to receive certification or indemnification or to embed the software into their products without having their own code touch open source code. Whole product. Commercial users pay for the utility derived from using the software. Increasingly, the free open source product does not provide the full utility, only a more comprehensive non-free commercial version does. To meet all requirements, commercial users have to upgrade from the free to the non-free version. Operational comfort. Customers also want to ensure that the software reliably fulfills its duty. Thus, they may be buying hotline and technical support, subscription services to bug fixes, or real-time systems monitoring. There are many such non-functional requirements that companies may want to buy, many of which are specific to the software at hand. Consulting services. Finally, customers may want to pay for training, documentation, and implementation services.
- Governance and Development Models Apache Governance Model: Non-profit corporation, elects a Board of Directors that sets corporate policy, and delegates ownership of project policies and execution to various officers and PMCs Apache Development Model: the “Apache Way” is a consensus-based, community driven model with the ethos of merit, consensus, community and charity General Points: All volunteer work. If you want something done, volunteer on the appropriate committee. Apache Corporate Governance Overview As a US-based membership corporation and 501(c)(3) non-profit, the Apache Software Foundation (ASF) is governed by a set of bylaws in terms of its corporate actions. The Membership elects a Board of Directors which sets corporate policy, and delegates ownership of project policies and execution to various officers and Project Management Committees (PMCs). While many people are familiar with the consensus-based, community driven governance known as The Apache Way that is used by our projects, readers perhaps may not be as familiar with how the ASF as a corporation works. Corporate Governance Behind the scenes of the many successful Apache projects, the ASF is run and managed much like other legal corporations. While the ethos of The Apache Way - merit, consensus, community, charity - is reflected within our corporate governance activities, the details of how the corporation legally works are important to understand. Membership The Members of the ASF are similar to stockholders; they elect new Members and may vote for Directors.Read about the ASF Membership. Board of Directors The Board sets corporate policy, appoints officers, forms PMCs, and delegates policy or execution to those officers and PMCs. Read about the Board of Directors. Executive Officers The board elects a Chairman (a director) and appoints a usual slate of executive officers. Officer positions are all unpaid volunteers, and serve at the direction of the board in their specific areas of responsibility. We always have a complete list of officers published. Officers are responsible both for managing the Foundations affairs in their specific areas, as well as reporting monthly status reports back to the board. Executive officers include the normal slate of officers, including a President, Executive Vice President, Secretary, Treasurer, and Assistant Secretary and Treasurer. Corporate Officers The board has at various times appointed other officers for corporate-wide functions - this includes Vice Presidents to oversee Brand Management, Conference Planning, Fundraising, Legal Affairs, Marketing and Publicity, Travel Assistance, and W3C Relations, among others. The board delegates the authority to set and execute corporate policy within the officer's specific area of responsibility. The board has also appointed a VP of Infrastructure, who is responsible for the day-to-day running of our Infrastructure team and the hardware that keeps Apache running. Since our infrastructure (websites, mailing lists, source code control, wikis, etc.) is a shared resource for all projects at the ASF, it is managed centrally. The VP, Infrastructure reports to the President. Project Management Committees PMCs vote on new committers and PMC members for their project, and set per-project policies. Read about PMCs. ASF Organization Chart Our high-level Apache org chart best shows the separation between organizational governance (the board & members) and technical governance (PMCs and committers). Technical Governance Within the ASF, the board delegates the technical direction of all projects to each PMC. PMCs are expected to follow corporate policies in terms of licensing, branding, infrastructure and so on, and are expected to manage their projects independently using The Apache Way. PMCs are tasked with all other aspects of project management, especially technical direction. Project Management Committees PMCs work to produce software for the public good by voting on releases of their project's software products. Read about PMCs. Committers Committers are members of project development community who have been granted write access to an Apache projects. Each project's PMC invites people who have shown merit within their project to become committers. Committers must sign a brief Individual Contributor License Agreement (ICLA), which clearly defines the terms under which intellectual property has been contributed to the ASF. This allows our projects to ensure that the products they publish can safely be released under the Apache License. Committers are elected separately for every project; merit within one project is not necessarily transferable to other projects. Committers also have access to a one Foundation-wide committer repository, where a few extra services and tools useful for doing Apache project work are available. Committers may also list themselves in our worldwide listing of committers , as well as within our Community Development mentoring program. Non-Governance Groups As a community-based organization, there many other groups of individuals and organizations that provide valuable work and services for the ASF and Apache projects, but are not directly part of our corporate governance. Contractors / Paid Staff The ASF pays both for a number of services, and for several contractors to continue to keep core infrastructure running. Normally we rely on volunteers for all of our work - both at the technical and project levels, and at the organizational and board levels. However maintaining a reliable and secure infrastructure to keep all of our services running requires paid staff. Currently, the ASF contracts several full-time sysadmins to maintain our wide variety of services and machines; these contracts along with hardware and bandwidth costs make up the largest part of our annual corporate budget. We also contract for marketing and publicity services. Note that the ASF does not pay for software development on any Apache projects; we rely on volunteers for all of our project work. The ASF focuses on providing the technical, legal, and community infrastructure for like-minded communities; we trust that healthy project communities will build their own software products. Contributors Contributors are individuals who contribute patches - source code, documentation, help on mailing lists - to Apache projects. All Apache projects greatly appreciate the thousands of volunteers who have contributed work back to our projects. Contributors do not have a specific governance role - however healthy projects are always on the lookout for productive and helpful contributors, so they can consider nominating new committers. Users Users use our software, and often ask for help about our software. Many helpful users are non-technical, but still spend the time to submit bug reports and answer questions on our project's mailing lists. Sponsors Many organizations and a few individuals have signed up as Sponsors of Apache, and have pledged annual donations to the ASF. The ASF is greatly appreciative of both the financial and other support that our many Sponsors provide, which ensures we have the infrastructure and other services needed to ensure our 100+ Apache projects can succeed. To ensure project and corporate independence, Sponsors are not part of corporate governance at the ASF. Becoming a Sponsor does not give your organization or employees any specific merit within the ASF or our projects, although Sponsors are always recognized by the ASF on our Thanks page. General Points: All volunteer work. If you want something done, volunteer on the appropriate committee. ASF is about supporting communities A number of projects Each project is responsible for their own code, community and direction ASF Board provides oversight, but that’s it Board has no say on what code gets written, nor what direction projects take, nor what projects ASF should start. All of that is devolved to the projects themselves. ASF has some common support (e.g., infrastructure, press, trademarks), to help rojects focus on their code and their communities Community The community behind a project are empowered with the technical decision-making for that project. Apache projects must follow a brief set of organizational rules, but otherwise technical and other decisions are completely up to the project and it's PMC. Some key aspects of Community are: Collaborative Apache projects are run collaboratively; that is, the whole of the community that has shown merit gets to decide technical direction. Consensus Communities working in The Apache Way strive to get consensus on major decisions. Having the community work together is one of the most important parts of the Way, as well as one of the most difficult to implement. Diversity Community diversity is often a key element to community health. The most important factor is a diversity of employers, for those committers who are doing some or all work on behalf of the employers. Projects that solely comprise active committers from a single project are frequently at risk of abandonment when their employer's business cycle changes. Projects with active committers from multiple employers - or including students and hobbyists – can continue work and to draw in new contributors, even if one employer changes direction. At the ASF, diversity of employers is a graduation requirement for Incubating projects. Incubator Podlings must show that they can attract committers from various employers to ensure that the project and technology is likely to be useful for a wider audience. Diversity of learning and experiences within a community is often a bonus. Committers with different backgrounds will bring new ideas and perspectives to a project, which can make for stronger and more innovative technical decisions. Hats Everyone within a community comes with their own background, and may perform different roles within the community: user, writer, developer, PMC member. The concept of Hats relates to the roles you may play within a communty at various times. When you're requesting a new feature, you're wearing your user Hat. When checking in code to fix a bug, you're wearing your Committer Hat. Votes on project releases are made while wearing your PMC member hat. While the difference is sometimes subtle, in a perfect world it's an important lens to consider your actions through. For example, as a user you might want your new feature shipped as soon as possible, because your organization needs to deploy it. When properly applying The Apache Way, however, as a PMC member you probably shouldn't propose a release vote until the project as a whole is tested and stabilizes it's API. Good community members often realize this distinction, and are happy to simply pull a changeset locally to your own organization to deploy just the new feature, while continuing to work with the community on getting to the right place for the next project release. Hats are also another aspect of your Affiliations. While we hope committers keep their Committer Hat squarely on when checking in code, we realize that everyone has their own, external reasons for particpating here – whether because of your dayjob employer, because of a consulting contract, or because you are seeking the fame and fortune of being an open source contributor. (Hint: fame and fortune not guaranteed.) Mailing Lists Work at Apache is done on mailing lists. Nearly all of these lists are publicly archived. An old adage is: "If it didn't happen on-list, it didn't happen." Ensuring that all work and especially all decisions happen on-list ensures that the entire community is able to participate. Merit accrues to Individuals through their visible and productive work within a community. To put it another way, merit is the invisible currency that you gain by contributing useful work to the project. There are a number of common aspects to merit as it's recognized within The Apache Way, the most important one is it's recognition by the community. You don't gain merit by simply doing a lot of work; you gain merit by doing things the community values. Merit is measured by the community. In a general way, it's the community's perception of your value to the project. Different communities have different measurements of value, both in terms of what's important to do, how it's important to act, and in particular where the bar is to get recognized. Merit can and cannot be measured. The concept of merit – or useful work – within technical communities does allow for some measurements. The code you contribute compiles, or it does not; it meets the spec, or it fails the tests; it performs a function that the community values, or it does something silly. This technical aspect is a key difference to the term “merit” as it's used in The Apache Way than it often is used in other social or political areas. Merit accrues to individuals. It doesn't matter who you work for, or why you're contributing. The merit accrues to you as a person, regardless of the Hats you may wear. Merit is not transitive. Your co-workers contributing to the same community do not share in your merit. Your company is not necessarily recognized for either the number of projects contributed to nor the number of developers assigned to work on projects. Merit is not transferable. The merit gained in one community is not necessarily valued in another community. Web Services experts should not expect to immediately gain a vote in the SpamAssassin community. Likewise, the bar for significant recognition varies significantly between different communties. Merit does not expire. It may get dusty if you stop participation for a while, but you still typically keep your recognition within the community if you come back later. Merit can be lost through harmful actions within the community, and in some cases through harmful or distrustful actions elsewhere. Merit is not just for code. Most communities value documentation, website, infrastructure, and mailing list help as well as code or bug report contributions. The most obvious reward for your merit is being voted in to be a committer within a specific community. The merit level to become a committer varies from community to community; it can span anything from a handful of useful patches and helpful questions on a mailing list, to several months of sustained hard work on the code, mailing lists, or website. How ASF Projects Recognize Merit Within the ASF, most projects have fairly similar processes for actually recognizing merit. The specific processes are specific to the ASF, but in many cases are echoed in other open source projects as well. Committers have write access to their project's code repository. This means they may directly contribute to the project's code, website, and other materials. Committers who continue to show merit may be recognized by voting them onto the Project Management Committee (PMC). PMC members have binding votes on the strategic direction of the project, and on making formal releases. One PMC member is typically voted in by the community to become the chair of the PMC, and with that comes the role of Vice President of that particular project. Note that within the ASF, voting in committers is done solely by each project's PMC individually; they act independently in this respect. When voting individuals onto the PMC itself, the Board of Directors of the ASF exercises oversight, and approves all PMC changes by a simple 'ACK' email. The Board also specifically passes resolutions at monthly meetings to appoint, remove, or change Vice Presidents of Apache projects. Openness The concept of doing as much work as possible in public is fundamental to The Apache Way. For a community to best work and grow, it's technical work must happen in the open. Open communication promotes community growth. Having existing and past technical discussions and decisions available in the mailing list archives makes it easier for new users to understand the project and the choices the community made to get where it is today. Open communication ensures community health. Having every email you write to the project lists be published may be unnerving to some at first, but it's crucial to ensure that the whole community can contribute to the work. This also ensures that community members in different regions, or who work on different schedules, can still participate. Face to face meetings must have results published and voted on. While in-person meetings or telephone conferences are sometimes held to increase collaboration, the results of any meetings must be published to the project mail lists. Any decisions made off-list must be ratified by a vote or lazy consensus on the public lists to be valid. Open work ensures everyone can participate. Having all of the technical discussions, consensus building, and code and documentation work happen in the open ensures that everyone can participate and everyone – contributors and just lurkers alike – can learn from the process and understand where the project is going. Open work ensures our projects remain neutral. A healthy community has some diversity, and ensuring that all work on the project happens in the open means that no one set of contributors or no corporation or other organization can command the project or use it solely for their own ends. Everyone can see what the project is doing and who is advocating what within the project. Open communication allows for oversight. Within the ASF, there are a few core values that we expect all our projects to follow. Having the project's work happen in the open ensures that the board and the PMC can review what's happening to ensure the core values are accepted and followed. Open status ensures that everyone can know what's going on. New users don't need to know who to ask to learn about the project: everything is on the mailing list, the archives, the website. Open lists promote open reputations. Merit within a community is gained through open work within that community. While each community has it's own standards for levels of merit (i.e. at what point an individual may be voted in as a committer), open lists mean that all of a person's work on other communities is also visible. Pragmatisim Pragmatisim is about doing what makes sense for the community and the all of public, without other agendas. As a public charity, adopting a pragmatic attitude about licensing and community is a key part of our success. Our pragmatisim is primarily defined through our license, which we require all of our projects to use on the softare products they release. Pragmatisim is also shown through how we prefer diverse, consensus based communities for our development work. The Apache License welcomes everyone to use our software however they please – including in closed or otherwise proprietary ways. We're happy to have users take Apache software and use it privately, with or without ever sharing their changes with the world. We're happy to have corporations build proprietary projects on top of our software and sell the resulting product for a profit. As long as users comply with the very basic terms of our license, we want them to have the freedom to do as they will with our software. This pragmatic background to our license and our communities is most starkly contrasted to the Free Software Foundation's Gnu Public License (GPL). Much of the intent of GPL licenses – often called “CopyLeft” licenses to distinguish them from copyright concepts – is to ensure that the software itself and it's derivatives will forever remain free. The GPL essentially requires that future changes to any GPL software released publicly are given back to the community, using the GPL on the derived work. In some ways, the GPL provides for the software itself to be free, even at the expense of developers who might want to release derived works under another (possibly proprietary) license. The Apache License, in contrast, wants to give maximum freedom to the users of our software. All ASF projects are required to use the Apache License. The rights we ensure that users of our software have is one of the fundamental aspects of the ASF. Charity The ASF is a public charity, and it's purpose is to give away all of the software projects that it hosts. The point of this charity is for the public good - which includes everyone. Thus we use the pragmatic Apache License to ensure maximum freedom of all users who may choose to use our software. The ASF will never charge for the use of it's software. All Apache projects provide all code and basic mailing list support for free, without any requirements (other than basic netiquette when participating on our mailing lists). All volunteer work: If you want something done, volunteer on the appropriate committee
- Like a constitutional convention Bylaws promote a healthy community Preserves the separation of concerns between Foundation business and technical governance Rewards Developers and organizations that further OSS projects Uses Apache 2.0 license and Apache-style CLA for clean and simple IP practices Promotes for the fastest path possible to committer status using Dojos Board Responsibilities Ensures Mission met Bylaws & IP Elect Officers Select/manage key leadership Executive Director/Others Budget Approval General Operating Decisions Approve new PMCs Approving changes to the Development Governance Policy PMC Council Escalations User Advisory Board: Members overseen and selected by Executive Director Intent is to empower end users of the platform Provides a mechanism for users to voice any concerns Channel to disseminate information to the user community and to solicit input on proposed plans Provides requested input on issues to further Foundation objectives Strategy Council: Provides a mechanism for supporting members to voice any concerns, raise issues for discussion, and provide feedback to those setting the direction of the Foundation and the PMCs Channel to disseminate information to the vendor community and to solicit input on proposed plans Provides requested input on issues to further Foundation objectives, for example: Technical standards System acceptance and performance standards Foundation event planning and messaging PMC Council Responsibilities Managing overall roadmaps across PMCs Coordination of PMC themes Management of the overall release cycle integration Defining and enforcement of overall development, testing, and quality policies Resolving intra- and inter-PMC disputes Ownership of Development Operations definition and documents PMC Responsibilities: Oversee and Provide Leadership for Related Projects Coordinate Project Themes Determining programming languages for the PMC Projects Approve Project lifecycles (I.E. incubation to Active) Approve new Projects Define required documentation and testing resources within the PMC Provide point of arbitration for issues with Projects Projects: BUILD AND RELEASE SOFTWARE Release Planning Releases based upon periodic review of Story Tracker items Project Lead(s) determine release content and priority with Dedicated Committers The Foundation believes in continuous releases, and all Project teams aim to ship working software as frequently as possible
- Using “free” or components with restrictive usage reduce your options Open-source licenses are not necessarily compatible, which can make it legally impossible to mix (or link) even open-source code if the components are released under different licenses. For example, software that combined code released under version 1.1 of the Mozilla Public License (MPL) with code under the GNU General Public License (GPL) could not be distributed without violating one of the licenses' terms by default.[5] This is despite both licenses being approved by the Open Source Initiative[6] and Free Software Foundation.[7]
- Using “free” or components with restrictive usage reduce your options Open-source licenses are not necessarily compatible, which can make it legally impossible to mix (or link) even open-source code if the components are released under different licenses. For example, software that combined code released under version 1.1 of the Mozilla Public License (MPL) with code under the GNU General Public License (GPL) could not be distributed without violating one of the licenses' terms by default.[5] This is despite both licenses being approved by the Open Source Initiative[6] and Free Software Foundation.[7] Our experience with Apache Geode Since version 3.4, JGroups has been licensed under the Apache License 2.0. Earlier versions are licensed under LGPL 2.1
- Using “free” or components with restrictive usage reduce your options Open-source licenses are not necessarily compatible, which can make it legally impossible to mix (or link) even open-source code if the components are released under different licenses. For example, software that combined code released under version 1.1 of the Mozilla Public License (MPL) with code under the GNU General Public License (GPL) could not be distributed without violating one of the licenses' terms by default.[5] This is despite both licenses being approved by the Open Source Initiative[6] and Free Software Foundation.[7]
- Using “free” or components with restrictive usage reduce your options Open-source licenses are not necessarily compatible, which can make it legally impossible to mix (or link) even open-source code if the components are released under different licenses. For example, software that combined code released under version 1.1 of the Mozilla Public License (MPL) with code under the GNU General Public License (GPL) could not be distributed without violating one of the licenses' terms by default.[5] This is despite both licenses being approved by the Open Source Initiative[6] and Free Software Foundation.[7]
- Using “free” or components with restrictive usage reduce your options Open-source licenses are not necessarily compatible, which can make it legally impossible to mix (or link) even open-source code if the components are released under different licenses. For example, software that combined code released under version 1.1 of the Mozilla Public License (MPL) with code under the GNU General Public License (GPL) could not be distributed without violating one of the licenses' terms by default.[5] This is despite both licenses being approved by the Open Source Initiative[6] and Free Software Foundation.[7]
- Using “free” or components with restrictive usage reduce your options Open-source licenses are not necessarily compatible, which can make it legally impossible to mix (or link) even open-source code if the components are released under different licenses. For example, software that combined code released under version 1.1 of the Mozilla Public License (MPL) with code under the GNU General Public License (GPL) could not be distributed without violating one of the licenses' terms by default.[5] This is despite both licenses being approved by the Open Source Initiative[6] and Free Software Foundation.[7]