Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Best Practices for Releasing and Choosing Open Source Projects

F99c66cc9f64454df105006286d47521?s=47 Irene Ros
October 15, 2015

Best Practices for Releasing and Choosing Open Source Projects

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.


Irene Ros

October 15, 2015

More Decks by Irene Ros

Other Decks in Technology


  1. 2015 Best Practices for Releasing and Choosing Open Source Software

    Irene Ros Oct 15th, 2015 #GHC15 2015
  2. 2015 Who am I? ▪ Working on the Open Web

    (~ 9 years) ▪ Large and small companies ▪ Consumer and Producer of Open Source Software Data Visualization team
  3. 2015 Why should you care about Open Source code? No

    software is built without it. Period.
  4. 2015 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
  5. 2015 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
  6. 2015 Dear Open Source Creators...

  7. 2015 Code Repositories

  8. 2015 Choosing a code repository ▪ Many options: Github, Bitbucket,

 (MS), etc ▪ Things to consider: ▪ Git vs Not Git (svn, cvs... don't.) ▪ Pricing (Team vs Individual) ▪ Private vs Public ▪ Discoverability for potential consumers
  9. 2015 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, 
 publishing etc.) ▪ Ease of communicating about your open source project (documentation, wiki etc.)
  10. 2015 Documentation

  11. 2015 Documenting Your Project ▪ Code is only 10% of

    the work. ▪ Documentation should always have: ▪ Installation instructions ▪ Usage instructions/tutorials/examples ▪ Instructions on modifying/extending ▪ Dependencies ▪ Caveats ▪ Maintainers and how to contact them ▪ Instructions on support requests ▪ Guidelines for interested contributors ▪ Credits to other contributors / software ▪ Make it Searchable ▪ Keep it up to date ▪ Allow people to fix it if you can't ▪ Keep it as simple as possible ▪ Document edge cases
  12. 2015

  13. 2015 Versioning

  14. 2015 Version it! ▪ Things break - that's why we

    version things: ▪ http://semver.org/ ▪ 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 versions. ▪ Make older versions available (publish or download.) ▪ Publish a Change Log / Release Notes
  15. 2015

  16. 2015 Licenses

  17. 2015 Licenses

  18. 2015 Licenses ▪ choosealicense.com ▪ Permissive licenses (BSD) mean: ▪

    more people can use your software (especially large companies.) ▪ people can commercialize your software/code ▪ people can copy your code with attribution ▪ you are not held liable
  19. 2015 Licenses ▪ "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
  20. 2015 Licenses ▪ Other: ▪ 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
  21. 2015 Support

  22. 2015 Offer Support ▪ 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
  23. 2015 Community

  24. 2015 Community is Key ▪ Your code is worthless without

    its users. ▪ You should always: ▪ Answer questions (StackOverflow, google groups, IRC etc.) ▪ Update on the status of your work and planned changes/improvements ▪ Appreciate and engage contributors ▪ Be honest about your investment ▪ Be nice to your community and your competitors
  25. 2015 It's not all sunshine and roses... The less pleasant

    side of Open Source Publishing
  26. 2015 ▪ 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 own ▪ The consequences of success (stability vs growth, "competition", commercial application, support demand) ▪ No one caring
  27. 2015 Open Source is a long term commitment.

  28. 2015 Dear Users of Open Source...

  29. 2015 Things to look out for... ▪ Is the project

 (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?)
  30. 2015 Things to look out for... ▪ Is it well

 (Does it exist and is it good?) ▪ Can YOU use this project?
 (Compatible license?) ▪ Does it have a community?
 (Is anyone using it? Are there conversations about it? are there community helpers?)
  31. 2015 Sometimes things go wrong... ▪ Maintainers become disinterested OR

    the need is eliminated ▪ There's no community involvement / contribution ▪ 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
  32. 2015 Be diligent in your choices. Be nice.

  33. 2015 Got Feedback? Rate and review the session on our

    mobile app Download at http://ddut.ch/ghc15 or search GHC 2015 in the app store Thank you! irene@bocoup.com @ireneros