The Open Source community is one of vast reach. Releasing software as open source is now the norm. Simultaneously, the value of using Open Source software in one's codebase is increasingly evident. Given that, how does one release a project or choose the right project to use? In this talk, we'll cover best practices for releasing projects as open source, and how those will impact consumers of open source software.
Best Practices for Releasing
and Choosing Open Source
Oct 15th, 2015
Who am I?
▪ Working on the Open Web (~ 9 years)
▪ Large and small companies
▪ Consumer and Producer of Open Source
Data Visualization team
Why should you care about Open
No software is built without it.
If you're a consumer...
▪ Your open source software should:
▪ Do the job
▪ Do it well
▪ Be easy to work with
▪ Be easy to adapt to your needs
▪ Not break easily
▪ Be maintained and supported
▪ Have other users
▪ Follow accepted paradigms/specifications
If you're a producer...
▪ You want your open source software to:
▪ Be useful to people
▪ Be used by a lot of people
▪ Be fun to work on
▪ Be fun to maintain/support/grow
Dear Open Source Creators...
Choosing a code repository
▪ Many options: Github, Bitbucket, CodePlex
▪ Things to consider:
▪ Git vs Not Git (svn, cvs... don't.)
▪ Pricing (Team vs Individual)
▪ Private vs Public
▪ Discoverability for potential consumers
Choosing a code repository
▪ More things to consider:
▪ Ease of adding collaborators
▪ Ease of "following along"
▪ Ease of submitting support requests
▪ Ease of interfacing with other engineering
tools (build systems, test systems,
▪ Ease of communicating about your open source
project (documentation, wiki etc.)
Documenting Your Project
▪ Code is only 10% of the work.
▪ Documentation should always have:
▪ Installation instructions
▪ Usage instructions/tutorials/examples
▪ Instructions on modifying/extending
▪ Maintainers and how to contact them
▪ Instructions on support requests
▪ Guidelines for interested contributors
▪ Credits to other contributors / software
▪ Make it
▪ Keep it up to
▪ Allow people to
fix it if you can't
▪ Keep it as simple
▪ Document edge
▪ Things break - that's why we version things:
▪ For example (if we look at 2.5.6):
▪ (2) Major for breaking API changes
▪ (5) Minor for adding backwards compatible new functionality
▪ (6) Patch for backward-compatible bug fixes
▪ Document on which platforms each version works, so that
people who are locked into certain platforms can find older
▪ Make older versions available (publish or download.)
▪ Publish a Change Log / Release Notes
▪ Permissive licenses (BSD) mean:
▪ more people can use your software (especially
▪ people can commercialize your software/code
▪ people can copy your code with attribution
▪ you are not held liable
▪ "Sticky" Copyleft Licenses (GPL*) means:
▪ Anyone who redistributes your code MUST use
the same license
▪ Larger companies will avoid it like fire (because
they have products they want to sell and not
release as open source.)
▪ Some restrict modification
▪ Apache License - similar to MIT in
permissiveness, but reserves right to patent.
▪ MPL - between MIT and GPL
▪ Creative Commons - mostly content, not code
▪ more: http://choosealicense.com/licenses/
▪ Don't make up your own
▪ You should absolutely have one
▪ Make sure you choose a platform that:
▪ Users can submit support requests / issues on
▪ Users can get an update on their issues
▪ Inform users what information you need
(Environment, screenshots, reproducible steps etc)
▪ Update tickets - always respond with
acknowledgement, plan and resolution
Community is Key
▪ Your code is worthless without its users.
▪ You should always:
▪ Answer questions (StackOverflow, google groups,
▪ Update on the status of your work and planned
▪ Appreciate and engage contributors
▪ Be honest about your investment
▪ Be nice to your community and your competitors
It's not all sunshine and roses...
The less pleasant side of Open Source Publishing
▪ Needing to fix bugs that arise due to platform
changes, not your own code.
▪ Ridiculous / angry user requests
▪ People "copying" your code and calling it their
▪ The consequences of success (stability vs
growth, "competition", commercial application,
▪ No one caring
Open Source is a long term
Dear Users of Open Source...
Things to look out for...
▪ Is the project active?
(commits, releases, issues, dev priorities etc.)
▪ is it good code?
(good organization, good practices)
▪ Is it easy to adapt?
(are there extensions/plugins?)
▪ Is it well supported?
(Issues - How many are open and
unanswered? How severe are they?)
Things to look out for...
▪ Is it well documented?
(Does it exist and is it good?)
▪ Can YOU use this project?
▪ Does it have a community?
(Is anyone using it? Are there conversations
about it? are there community helpers?)
Sometimes things go wrong...
▪ Maintainers become disinterested OR the
need is eliminated
▪ There's no community involvement /
▪ Code libraries "break" as platforms evolve
(aka, no longer compatible)
▪ Open source libraries are written in a way
that makes them hard to extend/fix
Be diligent in your choices.
Rate and review the session on our mobile app
Download at http://ddut.ch/ghc15
or search GHC 2015 in the app store