The Pre-Open Sourcing Sanity Check

1Samsung Open Source Group © SAMSUNG Electronics Co.
The Pre-Open Sourcing
Sanity Check
Brian Warner
Senior Open Source Strategist
Samsung Open Source Group
brian.warner@samsung.com

2Samsung Open Source Group © SAMSUNG Electronics Co.
It’s really easy to say,
“Let’s create an open source project!”
…it’s really hard to actually do it.

3
The Pre-Open Sourcing Sanity Check
Can we do it?
•  Do we have
the skills and
bandwidth to
do this right?
Should we do
it?
•  Will this
contribute
positively to
our strategic
goals?
Who will we do
it with?
•  Have we
calibrated our
expectations
for external
participation?
How will we do
it?
•  Have we
thought
through all of
the nuances?
Samsung Open Source Group © SAMSUNG Electronics Co.
Samsung’s Open Source Group uses a rigorous and structured process
to evaluate internal proposals for new open source projects and alliances.
The very first step in the process is to ask some fundamental questions,
because the last thing anybody wants is a failure to thrive.

4
CAN WE DO IT?

5
Pillars of internal support:
Code, Skills, and Willpower.
The code
•  It may require work to release as
open source, but you have to start
with something tangible.
•  Your open source group can guide
you through the cleanup and due
diligence required to release code.
The skills
•  You must have people familiar with
the code available and committed to
the process.
•  These individuals will form the core
of the project’s technical leadership.
The willpower
•  Do we agree on an internal
definition of success?
•  Do we have the budget and internal
support to see the project past this
point?
The first step is to ask,
“Do we have what we need to get started?”

6
SHOULD WE DO IT?

7
Why build an alliance around an open
source project?
•  A technology is in the early stages of being defined, without broad
industry agreement on a standard model or implementation.
Leading by example
•  Current technology is burdened with legacy complexity or proprietary
implementations and needs to be proactively replaced.
Modernizing the stack
•  You can disrupt an incumbent competitor by collaborative producing
neutral software alongside other organizations with similar strategic goals.
Competing more effectively
It’s usually about one (or more) of these things:

8
When would you not want to create an
open source alliance?
History shows there are a number of situations which virtually
guarantee failure when releasing something as open source.
The issue is generally not technology, but rather mismatched
expectations between the initiator and the rest of the world.
Poor reasons to create an open source alliance:
•  You are expect others to maintain code you need, while
eliminating your own engineering resources.
•  As a retirement strategy for code you no longer need or care
about (abandonware).
•  When the source code is deeply tied to other code that can’t be
open sourced due to IP coverage.

9
What other alternatives are out there?
You don’t always need to do something new.
Other projects may already exist that need minor or major
modification, but would be less work than starting from scratch.
Good questions to ask:
•  Can you join and adapt an existing open source project to meet
your needs?
•  If you don’t have the internal open source experience you need,
can you work with business partners or consultants who do?
•  If you have enough time, could you do this as a traditional
standards effort?

10
WHO WILL WE DO IT WITH?

11
Why would others join you?
If the code is available and anyone can contribute, why would
others bother joining in?
Typically it’s because they have their own itch to scratch, which
may (or may not) be the same as the alliance’s mission:
•  To quickly establish de-facto standards through an open
reference implementation.
•  To lower development costs through external R&D.
•  To become more technically aligned with business partners.
•  To focus a efforts on commoditizing a competitor’s product.

12
HOW WILL WE DO IT?

13
Open Source Best Practices
The Right
Governance Model
The Right License
Technical and
Hosting
Infrastructure
Critical Mass at
Launch
Marketing Platform
Awareness and
Reach
Continuous
Project Guidance
Events Support

14
Open Source Best Practices:
The Right Governance Model
Governance is what provides equal footing to contributors and
ensures the project is not controlled by one company
What does governance cover?
•  Who makes decisions for code inclusion and releases, and how.
•  Who owns the copyright on contributed code, and what licenses are ok.
•  Who can be the lead maintainer or architect.
•  Allocation of project funds.
•  Is a Technical Steering Committee or Compliance and Certification
Committee necessary? Who can be on them?
•  What you have to do to use the trademark, and how it can be used.
•  The openness/transparency of the project.
•  The mechanisms which allow a project to modify itself.

15
OSS Best Practices:
Governance
Board of Directors
•  501(c)6 non-profit.
•  Makes non-technical decisions.
Technical Steering Committee (TSC)
•  Sets project’s technical direction by interpreting
policy set by the Board of Directors.
•  Makes independent technical decisions.
•  Members are key technical decision makers (maintainers, etc).
The Board should never interfere in technical matters.
Board of
Directors
Marketing
Compliance and
Certification Audit / Finance TSC
Workgroups
Workgroups

16
OSS Best Practices:
Governance – Board of Directors
Responsible for corporate organization, marketing, press, legal, IP policy, and
recruitment.
Sets high-level policy in consultation with the TSC, defining the Alliance’s scope,
technical vision, and direction.
In most cases, the board is empowered to change the organization as needed
over time, including bylaws, membership agreement, and IP policy.
Boards function best when representatives have decision-making authority on
behalf of their company.
Specific functions often assigned to committees (e.g., Marketing, C&C)
Typical composition:
•  Top-level members all get one Director seat and a full vote.
•  Mid-level members get one seat and vote for every n members.
•  Chair of the board elected from sitting Directors
•  Chair of the TSC is a full voting member of the board.

17
OSS Best Practices:
Governance – TSC
Membership
•  Merit-based, typically workgroup maintainers
•  If workgroups are combined into subsystems, an elected leader is the TSC
representative.
•  TSC chair is elected from among the TSC representatives.
•  Some projects guarantee additional seats for top-level members.
Process
•  Self-governed, following typical open source decision-making process (rough
consensus)
•  Discussions/minutes typically public, although only TSC members can participate in
votes.
Scope
•  Sets release requirements, quality standards, and target dates.
•  Establishes technical best practices and mediates technical disputes.
•  May organize collaborations between workgroups if requested.
•  Sets global workgroup requirements, i.e. each must provide complete test coverage.

18
OSS Best Practices:
Governance – Workgroups
Membership
•  Anyone may participate in a workgroup as a contributor (including non-members).
•  Any participant can earn committer rights by way of code contribution and building
community trust.
•  Committers periodically elect a maintainer, who is the ultimate decision maker in the
workgroup.
Process
•  All code submissions, discussions, and decisions are open, transparent, and documented.
•  Code is only committed through the open source process, and never without peer review.
•  The process to become a committer / maintainer / architect is enforced by the TSC for
consistency.
•  Committer rights in one workgroup do not automatically convey committer rights in
another.
Scope
•  A workgroup covers a logical grouping of technical functionality.
•  Workgroups may be grouped into subsystems, overseen by an elected architect.

19
Have a neutral home for collaboration
In order for a technical project to become a key pan-industry
initiative it needs:
A Positive Reputation
• Project can’t be controlled by one
company, or else peers will not
collaborate.
• Credibility can be imparted by a
neutral host / project parent.
Neutral Technical
Infrastructure
• Open project repositories.
• Free access to collaboration tools.
Legal Infrastructure
• Provides needed protections and
ability for companies to collaborate
freely.
• Allows companies to fund
development or promotion through
third party, handle trademarks,
enforce compliance (if necessary).
Marketing Platform
• Developer relationships, industry and
technical events, driving awareness
and preference.

20
The right open source license
Choosing the right open source license is just as important as the
decision to open source code. Legal counsel should be involved in this.
License consideration factors:
•  Do you want outside contributors?
•  If somebody uses and distributes your code and improves it (fixes bugs or
adds features) do you want to make them give you the improvements back
so you can use them too?
•  Do you want to permit proprietary forks?
•  Do you always want to be attributed?
•  Do you want people to use your code in non-open source program?
•  If somebody uses your code in their program and sells their program for
money, do you want some of that money?
•  Etc.

21
Awareness and Reach
An open source project needs developers and users to become a
relevant part of an industry.
Code is not enough; you need reach and influence.
Standalone projects often have a hard time recruiting developers
and/or users given the sheer number of open source projects in
place today.
Successful projects utilize public relations, speaking opportunities
and dedicated networking to build the awareness and reach.

22
Critical Mass at Launch
There are thousands of open source projects; the successful ones
show they can rally key stakeholders to participate in the project.
In open source, usually one project is dominant in any given
category as it attracts developer and user mindshare.
Vitally important that the project recruits a broad base of
stakeholders to show it’s a pan-industry initiative.
Perceived momentum for an open source project can neutralize
competitors, if awareness is sustained.
It is critical to secure solid launch partners.

23
In conclusion…
•  It takes a lot of work to launch a new open source project, but it
can also be really exciting to see hard work come to fruition.
•  In the initial enthusiasm, it can be easy to overlook fundamental
sanity checks and proceed based upon high-level assumptions.
•  While a code-driven, open source strategy is a proven way to
produce excellent software quickly, you will greatly increase
your chances of success by taking the time to do it right.

The Pre-Open Sourcing Sanity Check

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to The Pre-Open Sourcing Sanity Check

Similar to The Pre-Open Sourcing Sanity Check (20)

More from Samsung Open Source Group

More from Samsung Open Source Group (20)

Recently uploaded

Recently uploaded (20)

The Pre-Open Sourcing Sanity Check