This document provides an overview and agenda for a presentation about breaking free from proprietary software and embracing open source. The presentation covers the business and legal considerations for open sourcing existing software projects, including ownership models, licensing strategies, and governance approaches. It also addresses how to structure R&D, sales, and support organizations to be successful with open source and how to build and invest in developer and user communities. The goal is to help companies chart a course to transition existing proprietary software to open source models and practices.
8. Here’s what we accomplished in 2015
• Apache Software Foundation Incubating project
• First release out!
• First user summit on March 9
• Lots of customers and partners presenting
• About to make its first release
• Working closely with customers turn partners
• Over 500 GPDB Sandbox downloads
• Innovative companies already using open source
version
• Helping us improve based on latest PostgreSQL
advances
11. Before you begin: always be context sensitive
Vital Stats: 3.25M Lines of Code; 5
YEARS OF DEVELOPMENT
Vital Stats: 2M Lines of Code; 12
YEARS OF DEVELOPMENT
Vital Stats: 1.3M Lines of Code; 15+
YEARS OF DEVELOPMENT
What Is It: Open source cloud
computing platform as a service
What Is It: Application Development
Platform that
What Is It: Distributed, in-memory
database for scale-out applications
What Does It Do: Supports the full
application lifecycle, from
development, through testing stages,
to deployment, in multiple clouds
License Type: Apache 2.0
What Does it Do: Helps Developers
build simple, portable, fast and JVM-
based cloud-native applications
License Type: Apache 2.0
What Does it Do: Features elastic
performance, database consistency,
and resilient clustering
License Type: Apache 2.0
12. 12
Elephant in the room: OSS Business Models
1. “Pure” Open Source
2. Community Open Source
3. Services + Support Open Source
4. Subscription Open Source
5. Multi-License Open Source
13. Choice #1
Who should
own the
software?
Company
New OSS Foundation
Existing Foundation
You (+) Choose
Foundation Chooses
You (+) Choose
Foundation Chooses
Choice #2
What License
SHOULD you
use?
Choice #3
What is your
Governance
Model?
1. Your top level Big Choices
14. • Ownership Determined by the choice of business model
COMPANY - “Benevolent dictator for life”: If you
choose to retain ownership of the OSS, you
determine its course
Existing OSS Foundation - you step into an existing
development and governance model
Create a Foundation - you create or collaborate on
the development and governance model
1.1 Choice #1: Who Owns It?
15. • Company Owns It:
Advantages - Flexibility, you determine development
and governance models and licensing, fast track to
commits, goodwill associated with the OSS project,
Easy licensing, and easier adoption
Disadvantages - No existing community to tap into,
distrust of single-vendor open source
1.1 Choice #1: Who Owns It?
16. • Existing OSS Foundation Owns It:
Advantages - Leverage existing big data communities,
established development and governance models, Apache 2.0
license as license of choice
Disadvantages -ASF is about active communities, not hosting;
mostly English, projects with non-trivial infrastructure
requirements, UI-centric projects not doing well, not a place for
corporate collaboration, large scale platform projects not a
great fit, projects with a lot of patents
1.1 Choice #1: Who Owns It?
17. • New OSS Foundation Owns It:
Advantages - Bringing together contributors
committed to the growth of a broad, open
ecosystem; more control over development,
governance model; scale of project cannot not be
accomplished without widespread adoption, rapid
innovation
Disadvantages - Single vendor baggage, ceding
control over your products, enabling your
competition
1.1 Choice #1: Who Owns It?
18. Licenses are a strategic intellectual property weapon and shield
consisting of legal tools of copyrights, patents and trademarks
1.2 Choice #2: What OSS License?
• Is it an OSI-approved license?
• Do we want to build a community/encourage adoption?
• What community are we trying to build?
• Do we want our code used in closed source applications by
competitors?
• Do we want to discourage forking?
• What is the public perception of the license we choose?
• What license will be the most efficient/easiest to use?
• What licenses protect our intellectual property?
• How much license reciprocity is required?
• What protections do we want in place for patent licensing &
litigation?
• What legal jurisdictions are we targeting?
19. • Company Owns It:
Governance - Empowered engineering leads
(gatekeepers); Leads drive innovation with
community/customer feedback + contributions
Development - Distributed team, agile processes,
public issue tracking, and a maniacal focus on
design/quality
1.3 Choice #3: Gov/Dev Model?
20. • Existing OSS Foundation Owns It:
ASF Governance - 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
ASF Development -the “Apache Way” is a
consensus-based, community driven model with the
ethos of merit, consensus, community and charity
1.3 Choice #3: Gov/Dev Model?
21. • New OSS Foundation Owns It:
Governance - “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 - CFF “Dojos” encourage agile
engineering, pair programming, daily standups, and
public story trackers
1.3 Choice #3: Gov/Dev Model?
23. 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
3. Doesn’t have to be perfect, can be work in progress
3.0 Cleaning up your Code
24. 1. Invest in tools
a. CLA management and enforcement tools
b. CI is a must
c. Employees vs. GitHub
2. Track IP lineage
a. Being a committer on the project is a lot of responsibility
3. Manage it! Manage it well!
3.1 Congrats you now have “external R&D” org
27. 3.3 Help your Sales and Support organizations
1. Sales
a. Is there anything left to sell when everything is availblae for free?
b. “Loose a customer, gain a collaborator”
c. How do we sell to customers who are clueless about open source?
d. Doesn’t open source mean abandonment?
2. Support
a. Be very clear about your support policy – in fact, help draft it!
b. Make sure support folks join the community
c. Accept the “information asymmetry” from now on
28. 3.4 Invest in your community
1. User community
a. Measure your time-to-hello-world
b. Have an artifact for user community to coalesce around
c. Meetups and challenges work
2. Contributor community
a. Measure your time-to-first contribution
b. Invest in regular sync up events and an occasional summit
c. If it didn’t happen on the mailing list/JIRA/slack it didn’t happen