The Open-Source Tetrahedron
• Community provides the “oxygen” your OSS ﬁre 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
• Hackathons, Meetups and Training Camps are a great way to build camaraderie,
grow your team and open communication lines
• Be explicit and diligent about licensing -- it deﬁnes how you share your ﬁre
• Be pragmatic and open to change
• Diﬀerentiate your “core” source and interfaces from auxiliary code and have a welldeﬁned 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!
• 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 ﬁx it.
• As your project grows, separate out fast unit tests from longer end-to-end
• Setup your test infrastructure to create (and optionally deploy) your binary
• 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