How to Open Source an Internal Project

!
START YOUR TIMER
How to open source
an internal project
All Things Open Meetup
@vmbrasseur
@vmbrasseur • CC BY-SA • Image: Library of Congress on Flickr; Public Domain 1

For starters, please hold your
questions until the end.
I'd do this in person as well, but it's
particularly important for me in this
virtual setting.
I can focus on slides or I can focus on
the chat. I can't do both. ;-)
Please
hold questions
for the end
@vmbrasseur • CC BY-SA • https://archive.org/details/ato2020meetup-internalproject 2

Now to set up some expectations about this talk.
This talk will NOT present a one-size-fits-all method for
releasing an internal project, because such a method DOES
NOT EXIST. Every company and every project release will
be different. What works for Google will not necessarily
work for you.
This talk WILL introduce important concepts that I've found
are most often overlooked or handled poorly.
I'm going to give you a very high level summary of the steps
required, because it's impossible to cover specifics that
cover every situation.
Setting up expectations
By the end of this talk you'll have a very rough roadmap for how
to release a project, but you'll have to do the driving yourself.
• One size does NOT ﬁt all
• Won't give you a silver bullet
• Releasing the software is just the start
(community is important)

Despite everything I just said…
…when I've given this presentation in the past I've received
feedback that I didn't make it easy for people to release
projects
Well, I mean, like I said, I can't do that. I don't have a magic
wand. This is a complicated process and it takes a lot of
thought and work to do it properly.
But, fine, for the people who want the Soundbite Version,
here's a slide for you.
For the rest of you, let's get started with something that I
find is more necessary than you'd expect…
The TL;DR
• Identify company goals & business needs
• Perform pre-release due diligence
• Deﬁne processes, procedures, policies, legal requirements
(Governance)
• Choose & apply a license
• Intentionally & patiently invest

I'm finding that, more and more often, it's
important to clarify this term up front.
Because, it turns out, over the past couple
decades of really impressive growth of free and
open source software projects and use, folks
have lost track of the answer to this very
important question.
I'm going to spend a fair bit of time on this,
because it's pretty darn important.
What even is
Open Source?

Specifically, many people don't realise that there's a definition of
what it means to be "Open Source".
It's called the Open Source Definition, it's maintained by a non-
profit standards and advocacy organisation named the Open
Source Initiative, and it's accepted around the world as the single
canonical definition of open source.
Built upon the Four Freedoms and the Debian Free Software
Guidelines, the OSD details what is required of any software that
calls itself "open source."
I'll read the slide for the visually impaired.
Software that does not provide for every one of these 10 items is,
literally by definition, not Open Source
Open Source Deﬁnition (OSD) 1
1. Free Redistribution 6. No Discrimination Against Fields of
Endeavour
2. Source Code 7. Distribution of License
3. Derived Works 8. License Must not Be Speciﬁc to a Product
4. Integrity of the Author's Source Code 9. License Must not Restrict Other Software
5. No Discrimination Against Persons or Groups 10. License Must be Technology Neutral
1
https://opensource.org/osd-annotated

Read the slide out loud then
use it to introduce the next
slide
Why should you care
about this?

Let's say you're building a product at work. You find this software
library that does exactly what you need to help your product function.
It says it's "open source," and you can see the source code right
there, so you use it.
Then you learn that the maintainer of the library has a different
meaning for "open source" than you. To them, it means that you can
see the source code, and you can maybe even use the source code,
but if you start to make money because of the library then you have
to give them all of YOUR source code.
Suddenly, you either have to completely rearchitect your product or
you need to hand this maintainer your source code, because they
were working under a definition of "open source" than you.
Why
You Should Care
About This

The OSD is a standard. It ensures we all have the same
expectations.
Everyone's using the same definition, so anything that says it's
"open source" should match that definition.
Do you really want to inspect and analyse every single project
you use to ensure that it matches the definition?
No, of course you don't. That would take forEVer, which means
you'd probably never do it, which means you could end up at a
BIG risk of using a project that might not meet the definition and
require you do do things you don't expect.
It's OK. You don't have to inspect and analyse all projects.
Instead…
The OSD prevents
this problem

The Open Source Initiative
does that for you.
Or, more specifically, it does it
by reviewing licenses under
which the software is released
Open Source
Initiative (OSI)
Approved Licenses

To help ensure the freedoms and benefits of the Open
Source Definition, the Open Source Initiative reviews
software licenses and compares them against the Open
Source Definition.
Those licenses that obey definition are "OSI-approved."
Because the approved licenses ensure adherence to the
Definition, only those projects that use an approved license
are guaranteed to be open source.
You don't have to inspect or analyse at all. Just check the
license, make sure it's OSI-approved, and know that it
matches the same definition of "open source" that you use.
opensource.org/licenses
11

…and that's figuring out why
your company is even looking
to do this in the first place
Identify
company goals
and business needs

Your company has and will invest a lot in
this thing you're looking to release
If the company receives no benefit from
releasing it
And if you can't all agree on what that
benefit is
You're going to have a lot of problems down
the road
It's OK to want to get something
out of releasing this project as
free/open source.

The answer to this question
will guide your focus from here
on out
Please don't underestimate its
importance
So…
…what does your company want
to get out of it, anyway?

If you don't know what you want to get out of it
You will never know whether you're on track or
need to change tactics
You will never be able to define what metrics
are meaningful
FIGURE THIS OUT UP FRONT
Let's assume you have goals figured out.
What are your next steps?
Without a goal
this entire effort
will probably fail
…but you won't notice until it's too late

Perform pre-release
due diligence

Clean that project, yo
These are things that can get your
company into a lot of trouble, so
review all code, comments,
documentation
Gonna release commit history? Clean
it, too.
Review for time bombs
• Credentials
• Trademarks
• Profanity or rudeness

"Distribution" is the trigger for most FOSS
licenses
Releasing a project is distribution
Review all of the projects on which your
company's project relies
Make sure you're in compliance with the terms of
the licenses of those projects
Get your IP counsel involved. Don't play fast and
loose with license conditions.
Review for compliance with licenses
So, you want to release your project as FOSS, huh?
Do you know what free and open source software
your project relies upon?

Clearly Defined is a relatively new but very actively developed
and supported project for gathering the information you need for
this due diligence.
It's an ever-growing community-driven resource for curated
license, copyright, and project source code location information
for free and open source software packages
It can be a very good way to bootstrap your due diligence
process
You can learn more about it and contribute at this website.
Now that you've done your due diligence, now you're ready to
release the project, right? Wrong. There's still plenty you have to
do before the project is released.
ClearlyDeﬁned.io

Deﬁne processes,
procedures, policies,
legal requirements
(Governance)
@vmbrasseur • CC BY-SA • Image: NASA Commons on Flickr; Public Domain 20

Read for the visually impaired
Consult with your legal counsel
NOTA BENE! DO NOT IGNORE THE
MAINTENANCE OVERHEAD FOR
THESE!
Figure out this process BEFORE you
release the project
To CLA/DCO?
Not to CLA/DCO?
Contributor License Agreement (CLA): A legal document intended to certify that
the person sharing a contribution has the right to do so, and that once the
contribution is accepted the project has a license to alter, distribute,and
administer those contributions however it sees fit.
Developer Certificate of Origin (DCO): A confirmation by a developer that they
have the right to share their contribution with the project. The developer provides
their confirmation by "signing" their contribution using a -s flag on the git commit.
The DCO is intended as a paperwork-free and low hassle alternative to the CLA.

For love of dog, document your project
User docs, Developer docs,
Installation docs, API docs
We all love using projects with good
docs. We all love complaining about
projects with no docs.
Be loved. Launch with good docs.
Documentation

There are a lot of other moving parts you need to consider
and put in place before releasing the project.
Not all projects will need these. Think about the audience
for your project. What will the expect? What will help them
use or contribute to the project?
Also consider those goals you came up with earlier. If some
of those goals include building a strong community and
user base, you're going to need marketing for your project.
This means getting your marketing team up to speed
about open source so they're equipped and prepared to do
a good job with what's probably a new market for them.
Issue templates?
Styleguides?
CI/CD?
Website?
Community chat/portal?
Marketing?

Please start out the project with a Code of Conduct.
This is table stakes now, folks.
If you're building a community, you need standards of
behaviour in that community. When something goes
wrong, it's difficult and unfair to hold people to
unexpressed standards and expectations. Be clear and
open about that stuff with a Code of Conduct.
Don't forget: it's not enough to have a CoC document. You
also have to learn how to enforce it. There are specialists
who can help you with this and I strongly recommend you
contract with them for training.
Code of Conduct

If you want folks to contribute, you gotta tell them how
This file is how you do it. Be as detailed as necessary.
Pointers to other docs, such as: Setting up dev
environment, how to open a bug report, how to get a
patch landed, styleguides, roadmap, etc.
If you don't have one of these, people will just invent
their own contribution methods and you probably
won't like that
So! OK! You have some basic governance ready for
your project! What's next?
CONTRIBUTORS ﬁle

And finally, now, it's time to
choose and apply a license
Choose and apply a
license
@vmbrasseur • CC BY-SA • Image: Internet Archive Book Images on Flickr; Public Domain 26

Everyone always jumps to this step first, but it
doesn't actually have to be done until just
before you release the project.
License selection may be influenced by the
license conditions of the projects on which
yours relies.
It will definitely be influenced by the business
needs and requirements, which is to say by
those goals I mentioned above.
Psssst!
This should be the last thing you do,
not the ﬁrst.

Every license on the list provides the 10 freedoms and benefits
of the Open Source Definition, but they have their own plusses
and minuses.
For instance, many companies prefer to release and use projects
released under the Apache 2 license due to its patent provisions.
Some companies and people prefer GPL because they believe
in sharing and the freedoms to Run, Study, Redistribute, and
Improve the software.
The only way to choose the correct license is to have figured out
those company goals that I mentioned earlier.
What are you trying to accomplish by releasing this project?
Which license will help support those goals?
Many licenses, many options

Some companies think, "Well,
our goals and business
requirements are very unique and
particular. We need an equally
unique and particular license so
we're going to write our own."
"How about we just create our
own new open source license?"

There are over 100 licenses on the OSI-
approved list. While there are valid
reasons for creating new licenses and
there's always room for experimentation
and evolution, the chances that your
project is one of those requiring
experimentation is, frankly, pretty slim.
Please.
No.@vmbrasseur • CC BY-SA • https://archive.org/details/ato2020meetup-internalproject 30

Also, until a license is reviewed and approved by OSI, it can't call
itself an open source license, so releasing a project under a new
license makes it a proprietary project, not an open source
project.
Now, there's nothing wrong with releasing it under a proprietary
license if that's what your business needs. For instance, the
Unity game engine code is available under a proprietary license
and that works well for their business.
But if what you're trying to do is release an open source project,
you need to use an open source license. Don't overcomplicate
things by trying to reinvent one of the many perfectly good
wheels availble on the OSI Approved License list.
It's only an Open
Source license if it's
been reviewed and
approved by the
Open Source Initiative.
Otherwise it's just a
sparkling end user
license agreement
(EULA).
@vmbrasseur • CC BY-SA • Bottle with Popping Cork emoji: EmojiTwo, CC BY 4.0 International 31

Here's that link again, so you can select a
license that works for you and your company.
Do work with your legal team in this process,
please, don't simply work from what your
senior developer tells you. This is an intellectual
property legal matter. Unless your senior dev is
an intellectual property lawyer, they're unlikely
to have the background to provide legal
guidance to your company.
opensource.org/licenses
32

Take guidance from the GPL
instructions
Usually seen as the most thorough
Few other licenses provide
instructions. Thanks, FSF!
A PITA? Dude, this stuff can be
automated
Applying a license
• LICENSE (or COPYING) in the repository
• Add copyright notice to each ﬁle
• Add license notice to each ﬁle

Maven.java
package org.apache.maven;
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/

Release and Build
Community
@vmbrasseur • CC BY-SA • Image: US National Archives on Flickr; Public Domain 35

Remember that I mentioned
earlier that releasing the project is
only the start
Once it's out there, your company
can't maximise its benefits
without the help of a community
Respect community expectations
and autonomy

You can't gain any of those benefits
without building a community
You can't build a community
without building trust
So how do you do that? How do
you build trust?
Trust == Beneﬁts

Your company is now a
community member,
not a project dictator

All development work happens
in the open where everyone
can see & participate in it
Features aren't developed in
quiet in-house and then
popped on the community
Work in the open
• Accept contributions from the community
• Community driven roadmap
• Features developed in the open with the community
• Build processes operate in the open and are reproducible
by others

Listen, collaborate
• Open decision making process and leadership
• Community must be a primary stakeholder, not simply a
low-cost workforce
• Community participates in all elements of project
governance

Building a community takes time
Building trust takes time
Don't be in a rush. If your company
works consistently in the open and in the
best interests of the community, it will
see the benefits and it will meet its goals.
It's just not going to happen overnight
Be patient

Like I said, this is just an introduction of the many things
you'll have to do in order to release the software as free or
open source software.
These slides are already available here at Internet Archive
I'm your presenter, VM Brasseur…
I'm a corporate strategist and open source leader
and I'm the author of this, the first and only book all about
how to contribute to open source, available at this URL.
Now, are there any questions, but NOT comments
concealed as questions?
Slides:
https://archive.org/details/
ato2020meetup-internalproject
@vmbrasseur
ato@vmbrasseur.com
fossforge.com

How to Open Source an Internal Project

More Related Content

What's hot (20)

Similar to How to Open Source an Internal Project (20)

More from All Things Open (20)

Recently uploaded (20)

How to Open Source an Internal Project