Open source best practices (DARPA)
Upcoming SlideShare
Loading in...5

Open source best practices (DARPA)



Short talk at DARPA on open-source best practices

Short talk at DARPA on open-source best practices



Total Views
Views on SlideShare
Embed Views



2 Embeds 16 15
http://localhost 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Open source best practices (DARPA) Open source best practices (DARPA) Presentation Transcript

  • Open-Source: Community, Code and Infrastructure Matt Massie University of California, Berkeley AMPLab
  • The Fire Tetrahedron
  • The Open-Source Tetrahedron CO CODE M E R TU M UN IT Y RA NF I UC TR S
  • 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
  • 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!
  • 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.
  • 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
  • Thank you. Have fun!