Open source best practices (DARPA)


Published on

Short talk at DARPA on open-source best practices

Published in: Technology
  • Be the first to comment

Open source best practices (DARPA)

  1. 1. Open-Source: Community, Code and Infrastructure Matt Massie University of California, Berkeley AMPLab
  2. 2. The Fire Tetrahedron
  3. 3. The Open-Source Tetrahedron CO CODE M E R TU M UN IT Y RA NF I UC TR S
  4. 4. Community • Community provides the “oxygen” your OSS fire needs • New members can bring in enthusiasm and new ideas. Keep a list of “pick me up!” issues for people who are want to chip in • Have a welcome page for new developers that tells them what they need to know about contributing -- source repo layout, code review process, etc. • Setup a mailing list and encourage group decision making and collaboration • The goal is allow people to take ownership -- requires letting go of control at some level • Hackathons, Meetups and Training Camps are a great way to build camaraderie, grow your team and open communication lines
  5. 5. Code • Be explicit and diligent about licensing -- it defines how you share your fire • Be pragmatic and open to change • Differentiate your “core” source and interfaces from auxiliary code and have a welldefined branching strategy for your source repo. • Keep your documentation with your source. Provide example code. • Provide utility classes that make testing easier and require tests with contributions • Use a standard build environment for your project when possible -- makes it easier for new developers to use, integrate with IDEs, release artifacts, etc • Push code upstream!
  6. 6. Infrastructure (Testing) • Use a Continuous Integration systems like Jenkins or Travis to test every commit or pull request. • Share your test infrastructure results publicly -- builds trust • Don’t allow failing tests to continually fail. Find the root cause and fix it. • As your project grows, separate out fast unit tests from longer end-to-end tests.
  7. 7. Infrastructure (Sharing) • Setup your test infrastructure to create (and optionally deploy) your binary artifacts • Consider technology like Docker (containers) or Vagrant (VMs) • Write documentation with your audience in mind - have a deployment guide and a developer’s guide • Publish binary artifacts to well-known repositories, e.g. Maven Central, aptget/yum package repositories, Docker, etc -- increases your project visibility • Use social media to get out the word about your software
  8. 8. Thank you. Have fun!