bringing commercial software to open source

Pivotal Confidential–Internal Use Only

2 © 2015 Pivotal Software, Inc. All rights reserved.

Bringing Commercial Software to Open Source Cyrus Wadia, Associate General Counsel – Strategic IP Gregory Chase, Director of Big Data Communities Thursday, June 25, 2015


SECTION 1 Introduction

SECTION 2 Reasons for Open Sourcing a Commercial Product

SECTION 3 Business & Legal Choices

SECTION 4 How Your Choices Affect Engineering

SECTION 5 Executing a Transition to Open Source

SECTION 6 Pivotal’s Experience Bringing OSS to Market

Agenda


From “Hello World”, software begins as proprietary

5 © 2015 Pivotal Software, Inc. All rights reserved. 5

Reasons for Open Sourcing a Commercial Product


The Half-Trillion-Dollar Enterprise Software Opportunity

$620 Billion in enterprise software sales in 2015 $40 Billion in database software sales in 2015

-  Sources: Forrester 2015 Industry Outlook and IDC Worldwide SaaS Enterprise Applications 2014-2018 Forecast


Open Source Software is Eating the $620 Billion-Dollar Enterprise Software Market

78% of companies run on OSS 88% of enterprises will increase OSS contribution Buyers are seeing OSS as superior to proprietary:

Source: Black Duck 2015 Future of Open Source Survey

57% increasing quality

61% increasing security

52% increasing ease of use

59% easier to deploy


In Data Management, Popularity of Open Source Offerings Increases vs. Commercial Offerings

Source: DB-Engines.com


Investors are Pouring Money into OSS Startups

Source: Venture Beat 2015: “The Disruptive Effect of Open Source Startups”


Why Users Are Choosing OSS

Focus and simplification

Economics of collaboratively-developed software

Customer demand - a “choice insurance policy”

Reliability, performance and speed

Security

Rapid development and deployment

Gain benefit of a vibrant ecosystem


Why Producers Choose to Contribute to OSS Developer

Company Hobbyist

Opportunistic

Patronage

Cost reduction

Direct use in revenue-generating service

Productize enterprise versions

Sell OSS support Other benefits: ●  Professional

credibility ●  Job satisfaction ●  Make a difference

Other benefits: ●  Commoditize market ●  Network effect ●  Mindshare

No revenue

“Pure” OSS revenue


Business & Legal Choices on the Road to Open Source


Choice #1: Should You Open Source This Software?

●  What is the software?

●  Why not stay proprietary?

●  What is motivating publication of software under an OSS license?

Pivotal Privileged & Confidential–Internal Use Only

Open Source Choice Overview

Who will own the Software?

Who Chooses the License Model?

Company

New OSS Foundation

Existing Foundation

What Governance/Development

Model?

You (+) Choose

Foundation Chooses

You (+) Choose

Foundation Chooses


Choice #2: What OSS Business Model to Use?

OSS

Community OSS

Pure Play OSS

Subscription OSS

Multi-Licensed OSS


Choice #3: What Governance/Development Model? •  Determined by the choice of business model

•  “Benevolent dictator for life”: If choosing to retain ownership of the OSS, you

determine its development and governance

•  If choosing an existing Foundation, you step into an existing development and governance model

•  If choosing to create a Foundation, you create or collaborate on the development and governance model

•  More later...

Pivotal Privileged & Confidential – Internal Use Only

Choice #4: What Open Source License to Use? CONSIDERATIONS

1.  Is it an OSI-approved license? 2.  Do we want to build a community/encourage

adoption? 3.  What community are we trying to build? 4.  Do we want our code used in closed source

applications by competitors? 5.  Do we want to discourage forking? 6.  What is the public perception of the license we

choose? 7.  What license will be the most efficient/easiest to

use? 8.  What licenses protect our intellectual property? 9.  How much license reciprocity is required? 10.  What protections do we want in place for patent

licensing & litigation? 11.  What legal jurisdictions are we targeting? 12.  Are there any Project-specific affinities we need to

address?


Open Source License Spectrum Permissive to Restrictive

RESTRICTIVE PERMISSIVE

GNU General Public License,

v. 2

•  Attribution •  Copyright

license •  Implied

patent license

•  Attribution •  Copyleft •  Copyright license •  Implied patent license

•  Attribution •  Weak copyleft •  Express patent license •  Copyright license •  Patent retaliation

•  Attribution •  Strong copyleft •  Broad express patent

license •  Copyright license •  Patent retaliation

•  Attribution •  Express patent

license •  Copyright license •  Patent retaliation


Top 20 Most Commonly Used Licenses in Open Source Projects


Licensing Choices by Companies Vary ●  GPL + Commercial License: MySQL, Sencha, Mura CMS, Aquia,

Canonical Ubuntu, RedHat, Suse ●  Apache 2.0 + Commercial: Cloudera, Pivotal, Couchbase, DataStax,

ElasticSearch, Puppet, RedHat OpenShift, RedHat Openstack ●  LGPL 3 + Commercial: Alfresco ●  AGPL 3 + Commercial: MongoDB ●  Multiple OSS Licenses + Commercial: JetBrains, QNX, Zimbra,

Pentaho, Talend ●  Postgres+ Commercial: Enterprise DB


How Your Choices Affect Engineering


Most Software Built Today Uses FOSS Components

90% of a typical application is assembled from OSS Components

Developers are 75% faster reusing OSS components

8 out of 10 developers believe OSS is higher quality


Choosing OSS Components Means Choosing Their Licenses

300 billion lines of source code in OSS projects

1 million unique projects in 8400 sites

40% of OSS projects have no declared license

77% on Github have no declared license

42% of these have embedded licenses from components


Many Free and Open Source Licenses are Incompatible with Each Other

Example Component License Compatibility with Apache Fully compatible

Limited Compatibility

Not Compatible

Apache V2 & V1.1 BSD

MIT/X11 W3C Software License

Academic Free License 3.0 Microsoft Public License

Creative Commons Attribution Eclipse Distribution License 1.0

Unicode License Agreement

CDDL CPL EPL IPL

MPL 1.0, 1.1, 2.0 OPL

Open Software License 3.0 Erlang Public License

Binary Code License GNU GPL 1,2,3

GNU LPGL 2, 2.1, 3 Affero GPL 3 NPL 1.0, 1.1

QPL Sleepycat License

Microsoft Limited Public License Code Project Open License


Top 20 OSS Components Found in Audits and Their Licenses Component License

jQuery JavaScript Library MIT License

Apache Jakarta Commons Logging Apache 2.0 License

JUnit Eclipse Public License

Apache Jakarta Commons IO Apache 2.0 License

zlib zlib License

Silk Icons Creative Commons Attribution 2.5

ANTLR BSD 3-clause “New” or “Revised” License

Apache Jakarta Commons Codec Apache 2.0 License

Apache Xerces Java XML Parser Apache 2.0 License

Document Object Model – DOM W3C Software Notice and License 20021231

Component License SAX SAX Public Domain Notice

Apache Log4j Apache 2.0 License

JavaMail 1.5.0+ CDDL

DOM4J – Flexible XML Framework for Java DOM4J License (BSD 2.0+ style)

Simple Logging Façade for Java (SLF4J) MIT License

Apache Jakarta Commons Collections Apache 2.0 License

OpenSSL OpenSSL Combined License

JavaBeans Activation Framework (JAF) 11/2005+ CDDL 1.1

Apache Tomcat Apache 2.0 License

swfobject MIT License


Readying Your Code for Open Source

1.  Scanning your code a.  Early prep - knock out easy problems b.  Component license compatibility c.  Security issues

2.  Correcting code issues

a.  Fixing must-do issues from scan results before posting code b.  Remove customer and personal information often found in comments c.  Appropriate copyright notices in code headers d.  Removing features intended for commercial versions e.  Doesn’t have to be perfect, can be work in progress


Redefine & Transform Your Development Process to Fit Your OSS Model 1.  Self-governed / benevolent dictator for life model

a.  Do you accept external contributions?

b.  Do you allow external committers?

c.  What is the relationship between open source code & commercial releases?

2.  Established OSS Foundation a.  Goal is usually to recruit external committers and contributors b.  Much of engineering process is dictated by the foundation

3.  Make-your-own foundation a.  Certain kinds of contributors and committers b.  About enginering process???


Executing a Transition to Open Source


Popularity of Public Source Code Repositories


How Much Infrastructure is Needed to Create a Collaborative Community?

Public Repo

Website

Mail List

Public Repo

Website

Dev User Events

Wiki

Issue / bug tracker

Public Repo

Website

Dev User Events

Issue / bug tracker

Wiki

Code review

Online Chat

Twitter

Youtube

Slide share

Google+

...


Launching Your New Community

1.  Naming & branding - Options depend on ownership & governance chosen

a.  Same name between commercial & open source? b.  Separate brands between commercial & open source

i.  Give brand equity to new commercial source or keep? ii.  Restrictions if separate names owned by separate entities

2.  Driving adoption a.  Committers and Contributors b.  Users c.  Incorporation into other projects d.  Relationship with commercial business


How to Ensure IP Cleanliness 1.  Accepting Grants of Code as Benevolent Dictator

a.  CLA/ICLA Process - License Choices b.  Ensuring Chain of Title

2.  Initial Grants of Code to an External Foundation a.  ASF as example

i.  Software Grant Agreement ii.  Company and Individual Committers sign Commitment Agreements

b.  Pivotal CF as example i.  Software Grant to Pivotal/accepted CCLAs/ICLAS ii.  Working with your customers

3.  Ongoing IP Cleanliness a.  Code Scans


Coexisting with Your New Community

1.  How will your engineering process work between open source & commercial versions?

2.  Who can commit & how are external contributions accepted?

3.  How are open source users supported?

4.  How do you maintain relations with your open source community?


Pivotal’s Experience Bringing OSS to Market


Pivotal OSS Communities & Collaboration


Open Source Business Models at Pivotal

Community OSS

Pure Play OSS

Subscription OSS

MultiLicense OSS


All OSS under Apache License, but Different Governance and Development Models


What is Spring?

●  An application development platform that helps developers build simple, portable, fast and flexible JVM-based cloud native applications

●  12 years of OSS development ●  Proven and trusted by enterprises worldwide


●  Governance Model: Empowered engineering leads (gatekeepers). Leads drive innovation with community/customer feedback and contributions.

●  Development Model: Distributed team, agile processes, public issue tracking, and maniacal focus on design/quality

Governance and Development Models


Spring Team Structure

Cross Cutting Themes

Project Lead(s

)

Project Lead(s

)

Project Lead(s

)

Project Lead(s

)

Project Lead(s

)

Community Other OSS Projects Customers

43

What is Cloud Foundry?

●  Open source cloud computing platform as a service

●  Supports the full application lifecycle, from initial development, through all testing stages, to deployment

●  Build and run applications on-premise, in public cloud, and via hybrid cloud deployment

44


●  Governance Model: “Governance by Contribution,” fosters contribution from a broad community of developers, users, customers, partners, ISVs, while advancing the development of the PaaS at extreme velocity

●  Development Model: CFF “Dojos” encourage agile engineering, pair programming, daily standups, and public story trackers

45

CFF Membership

46

Cloud Foundry Foundation Mission

●  To establish and sustain Cloud Foundry as the global industry standard Platform-as-a-Service (PaaS) open source technology with a thriving ecosystem

●  To deliver continuous quality, value and innovation to users, operators and providers of Cloud Foundry technology

●  To provide a vibrant agile experience for the community's contributors that delivers the highest quality cloud native applications and software, at high velocity with global scale

47

Equal Opportunity To Participate Everyone has an equal opportunity to participate in projects

No Surprises Planning processes and project status are open to all

IP Hygiene IP cleanliness must be preserved at all times

Cloud Foundry Foundation Guiding Principles

Governance by Contribution Influence within the Foundation is based on contributions

CONFIDENTIAL AND EMBARGED INFORMATION UNTIL DECEMBER 9TH, 2014

CFF Governance Structure - Board & Assists

BOARD OF DIRECTORS

Platinum #1 Representative






Gold #1 Member Representative


Gold #2 Member Representative

Voting Members Advisory Members (non-voting)

Determined by Board at Formation

•  One Silver Member

•  PMC Chairperson •  Individual

Member •  Executive

Director

Executive Director

End Users (As selected by the Executive Director)

Gold Reps (12 members)

Silver Reps (6 members)

USER ADVISORY BOARD

Executive Director

STRATEGY COUNCIL


CFF Governance Structure

PMC Leads

PMC COUNCIL

PMC Chairperson

Executive Director

PMC MEMBERS

PMC Lead Project Lead(s)

Member Representative(s) One per organization who has at least one

Dedicated Committer within any Active Project under the PMC

Project Lead(s) Project Dedicated Committers

FTE committers working on Backlog. Includes Developers, Documenters, and Testers


AGILE ENGINEERING

•  Drives the evolution of a finished product through an iterative weekly development cycle

•  Utilizes unparalleled

flexibility of product design

PAIR PROGRAMMING

•  Each workstation has two engineers, two keyboards, two mice, two monitors but just one computer

•  The “driver” writes code

while the “navigator” offers ideas on how to resolve issues

DAILY STANDUPS

•  Daily standups promote collaborative discussions on progress and problem-solving

PUBLIC STORY TRACKERS

•  Manages features and bugs during product development

•  You can provide feedback

on builds and see how your product is progressing user demand

CFF Development: The Dojos


Benefits of The Dojo

•  Fastest path to Dedicated Committer status –  Six weeks of collaboration

•  A learning experience beyond anything offered in the industry! –  Master Cloud Foundry by working shoulder to shoulder on the

open-source project with other Dedicated Committers –  Learn the project inside and out

•  Build longstanding relationships with other Dedicated Committers –  Streamlining the remote experience after the Dojo

•  Expand developer expertise –  Extreme programing, paired development, and a highly disciplined agile practice –  Graduates go home prepared to integrate new practices into in-house

development efforts

CFF Development: Benefits of the Dojos


(Incubating)

53

What is Apache Geode (incubating)? What is Apache Geode (incubating)?

●  An open source, distributed, in-memory database for scale-out applications

●  Elastic performance, database consistency, and resilient clustering

54


●  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


●  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

55 © Copyright 2015 Pivotal. All rights reserved.

Why OSS? Why Now? Why Apache?

•  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 –  Transparent, meritocracy which puts developers in charge


Apache Governance Structure Overview Corporate

Governance Technical

Governance

Non -

Governance Groups

Membership

Board of Directors

Executive Officers

Corporate Officers

PMCs

PMCs

Committers

Contractors/Paid

Staff

Contributors

Users

Sponsors


Source: The Apache Software Foundation

Apache Org Chart


Or to Put It Another Way... ●  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


•  All Geode development now happens “The Apache Way”

–  Community: ▪  Collaborative, Consensus-Based, Diversity, Hats, Mailing Lists

–  Merit: accrues to individuals through visible and productive work, defines who participates

–  Openness: All work done openly

–  Pragmatism

–  Charity

Apache Geode (Incubating) Development


Apache Geode (Incubating) Development •  Incubation

–  Applying

–  Overview of Process

–  Roles: Users, Developers, Committers, Mentors, Incubator PMC

–  Logistics: Website, IP Management

Apache Geode (Incubating) Development

What is the Open Data Platform?

A shared industry effort to help promote and advance the state of Apache Hadoop® and Big Data technologies for the Enterprise

ODP Speeds Adoption by Addressing Ecosystem

Interoperability

Common Core

Governance & Development Models

• Governance Model: TBD, but patterned on ASF Model • Development Model: the “Apache Way” is a consensus-based, community driven model with the ethos of merit, consensus, community and charity

–  “community over code” –  no paid committers

The ODP Core

•  The ODP Core is the kernel over which the industry can certify enterprise-class Apache Hadoop® solutions

–  Simplifying development of interoperable technologies •  Created by the ODP Developer Community

–  A team of cross industry technical experts –  Individual, or member company developers – anyone can

participate •  Using an open and transparent planning and release

process that follows the Apache Way –  Interoperability within and beyond the ODP Core drives a

broad set of use cases and rapid market growth

A Simple Beginning For The ODP Core •  The ODP Core is starting with a small number of projects

–  Enables a rapid start for the Initiative and an industry driven definition

•  All members decide how the ODP Core evolves –  All members are responsible for choosing projects to

include in the ODP Core –  Platinum, Gold and Silver member companies = One Member / One Vote

HDFS

YARN

Map Reduce

Ambari

✓  Deployable Hadoop configuration ✓  Improves interoperability ✓  Gives customers more freedom ✓  Follows the Apache Way

ODP Core Initial Projects

ODP & ASF: Complementary •  All ODP Apache related

planning and development will be done in the ASF

•  Will contribute to ASF projects in accordance with ASF processes and Intellectual Property guidelines

•  OPD will promote Apache Hadoop® community development and outreach activities


Q&A

bringing commercial software to open source

Technology