It’s almost certain you’re not going to use Senator Elizabeth Warren’s (now open source) campaign tools. Nor will you be submitting a pull request on Microsoft’s open sourced Windows calculator. And you’re definitely not going to be using Medtronic’s “open source” ventilator.

This, however, isn’t really the point. While it’s never good practice to just dump code onto GitHub, slap an open source license on it, and walk away, it’s also hard to predict exactly how code will get used. The best thing a person or organization that wants to open source code can do, therefore, is simply to make it usable for would-be adopters.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Utility is in the eye of the beholder

Way back in 2006, Tim O’Reilly moderated a conversation at an OSCON executive briefing. In that session we talked about Google’s and Yahoo’s contributions to open source. Both companies were early pioneers in open sourcing key technologies, but both companies in that conversation said, in effect, “No one would understand our code, or be able to make use of it– t’s too specific to a massive web company.”

Fast forward 14 years, and it’s clear that many “web-scale” innovations have gone mainstream as open source projects. Whether Apache Hadoop (Yahoo), Kubernetes (Google), or many others, it turns out that eventually we catch up to the future that web titans already live.

At the other end of the scale, the Warren campaign open sourced its tech because “Our hope is that other Democratic candidates and progressive causes will use the ideas and code we developed to run stronger campaigns and help Democrats win.” It’s very possible that Republican campaigns, for example, will use the code to win, or it’s even more likely that no one will use the code.

Not because of any lack of affinity for Elizabeth Warren, her ideals, or even her campaign technology. But perhaps it won’t be a good fit for smaller-scale campaigns (city, state, etc.), or it may simply be easier to build from scratch. There are good, tech-centric reasons not to use Spoke, her peer-to-peer texting platform, as well as Pollaris, her polling location lookup tool. 

That said, there may be other, tech-centric reasons to use these open source projects, and not necessarily by other political campaigns. You don’t really know until you open source it.

And, of course, just because a promising project is open sourced doesn’t mean it will succeed. Many years ago, as Martin Buckley reminded me, Novell open sourced NetMail as the Hula project. NetMail had been a credible webmail product, but as an open source project it floundered and eventually died (as Bongo). Salt Stack, by contrast, open sourced and soon discovered mega-corporations using its code, as Rhett Glauser has pointed out. 

You don’t know until you open source it.

Improving your open source odds

Or, rather, until you open source it well. Dumping code onto GitHub isn’t helpful, no matter how good the code is. The principles I detailed in 2005 haven’t really changed: Good documentation, use an accessible (and license), have a modular framework, etc. This is the essential blocking-and-tackling of open source. That doesn’t mean it’s easy.

Take documentation, for example. In a Slashdata survey of over 15,000 developers, respondents were asked what was most important to them. Though tech companies tend to spend huge percentages of their budget on trade shows and conferences, just 9% of developers identified these as important to their work. By far the most important thing (garnering 62% support of those surveyed) was documentation, followed by tutorials and tooling. That’s great, except that a 2017 GitHub survey of open source developers found that 93% of them hated the documentation they were having to use. 

If you’re looking for ways to ensure your open source project has the best possible chance of succeeding, it would be hard to find something more critical than getting the documentation right. Capital One’s Jennifer Riggins outlines a few ways to do that. 

In short, open source it. But make sure you also document it, or it may not matter. 

Disclosure: I work for AWS but nothing herein relates to my work there.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see