Everything I know about open source I learned from SpaceX

Five lessons from the spectacular Falcon Heavy launch for people working on open source projects.
359 readers like this.
Star Trek: inspiring people and their tech since 1964

Public Domain

You probably heard, but the private rocket company SpaceX did a thing last week. And while it was really cool to watch live video from a freakin' rocket on my pocket computer, that's not all there is to it. As I thought about the Falcon Heavy launch, I realized it contains a lot of lessons from my experience in open source projects.

Sometimes things go boom

Yeah, rockets ride a fine line between a controlled explosion and "OHMYGOSHDIDYOUSEETHAT?!" Most launches go off without a hitch, but sometimes—especially in the early days—spectacular failure happens. Open source projects generally don't explode in a literal sense, but the figurative explosion happens all the time. Whether it's drama in the community or a major security bug like Heartbleed, your project will face a big failure at some point. It's not a question of if, but when.

So it comes down to how you plan for your eventual explosion and how you react when it happens. Do you have a code of conduct? Do you have a security response plan? Do you have a plan for dealing with a compromised committer account? Contingency plans are important to rocketry, and they're important to your open source project, too.

Oh yeah, and while most people understand that failure happens, a few people will use your spectacular failure to rain hate on you. You can let them get to you, or you can forge ahead.

A common mission helps you meet goals

SpaceX has mostly achieved in putting satellites into low Earth orbit and sending supplies to the International Space Station. And this is good, useful work, but it's not what the company is after. Everything SpaceX is working on is a step toward a much more ambitious undertaking: crewed flights to Mars. Your open source project might share that goal (after all, SpaceX probably uses open source for a lot of its IT). But even if your aim is much more terrestrial, a shared mission gives your contributors something to work toward.

Mission statements are something we love to mock, but when everyone shares one, it's powerful. You may have a plan for the next release or two, but what's beyond that? Missions can be asymptotic. Maybe you'll never quite get there, but you'll keep heading in that direction. You can go from release to release without having an overarching mission, and if that's how you roll, then good for you. But consider having a mission to aim for.

It doesn't always make sense

SpaceX needed some payload to test the capability of the Falcon Heavy. Understandably, there was no paying customer cargo to put on it, so it launched Elon Musk's Tesla with a dummy named "Starman" behind the wheel. Okay, that looked really neat, but why? Because it's neat, mostly. It could have sent any number of things: rocks, trash, your obnoxious neighbor Frank. But the person in charge made a decision that was harmless but silly, and that's what SpaceX went with. If your open source project has a "Benevolent Dictator" leadership model, you might encounter things that don't make sense. What you do about that is up to you.

Partial success is still success

Shortly after the launch, the boosters needed to return to Earth. Two were set to return to the launch site, with the third landing on a barge at sea. The first two nailed the landing. It was beautiful. The third... well the live stream went out and we didn't hear if it landed successfully. I asked a friend who works at SpaceX. He did not spill the beans, but he told me, "We nailed the important parts of today's mission." As Elon Musk later said, the third booster hit the ocean at 300mph, which is not a good thing if you want to use it again. But what my friend told me is absolutely right. The main goals for this launch were to prove that the Falcon Heavy could not only launch but also could get a payload way the heck out there. Your project can have some failures (new bugs introduced, features that didn't make the release cutoff, etc.) and still be an overall success.

Even the new stuff isn't very new

The Falcon Heavy launch was a big deal, but it wasn't entirely new. The Falcon Heavy is, crudely speaking, just three Falcon 9 boosters strapped together. Falcon 9 has flown many times, and it has safely returned to both land and sea. It's how SpaceX took what it's already done and built on it to do something new that's so interesting. Your open source project can do the same. Use what people have already figured out and build on it. Stand on the shoulders of giants, even if the giants are you.

User profile image.
Ben Cotton is a meteorologist by training, but weather makes a great hobby. Ben works as the Fedora Program Manager at Red Hat. He is the author of Program Management for Open Source Projects. Find him on Twitter (@FunnelFiasco) or at FunnelFiasco.com.

1 Comment

Great job. Thank you for your video and post.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.