Image: Rawpixel Ltd, Getty Images/iStockphoto

In his OSCON keynote, AWS open source chief Adrian Cockcroft urged developers to “always move to a less restrictive license,” in order to keep an inbound supply of code coming. While in general I agree with Cockcroft’s contention, I’d perhaps amend it a bit to instead read something like, “always move to the developer experience that introduces the least friction.” Or, put even more succinctly, bank on developer convenience.

Much more than a license

For years we debated free vs. open source licensing. Over time, open source (e.g., Apache/BSD-style licensing) won out. Why? As I wrote back in 2013, it was a simple matter of developer convenience: “The exigencies of the GPL weighed down development, requiring a degree of license management that was as burdensome to the developer as it was frightening to the attorney. To the mainstream developer without a political axe to grind, Apache offered the path of least resistance to getting work done.”

Note, however, that most developers can’t be bothered to sit around all day, counting the number of angels that can dance on an Apache-licensed pin. They have work to do.

This penchant to “get stuff done” helps to explain why open source took off (no more need to get someone in Finance to approve the purchase of this or that software package), but also why cloud computing has boomed. Public cloud providers like AWS and Microsoft Azure have made almost unlimited hardware resources available to try for pennies.

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

One of the great ironies of our (software) times is that even as some criticize the public clouds for taking open source and closing it off, arguably much of the popularity of open source is because of these clouds. As AWS’ Matt Wilson has suggested, “The way I look at it, Amazon (as a whole) has contributed to the OSS ecosystem well in excess of the value Open Source provided in building Amazon itself, not the least of which is in building AWS’s cloud in a way that amplified the ability for Open Source to be rapidly adopted.” Put more simply, “the cloud was built for running [open source].”

But whether open source or not, cloud services have dramatically expanded developer options. As Tim O’Reilly once said of open data, “cheap and accessible” is “open enough” for most developers’ purposes. It’s a question of convenience, not license.

Mean time to dopamine

Why does this matter? Because no matter your business, developers should matter to you and, hence, developer convenience should matter to you. If you’re artificially slowing down developers (whether through licensing gymnastics, poor documentation, or something else), you’re artificially hurting your business. That’s dumb.

I love Sarah Novotny’s “mean time to dopamine” concept as a way to think about this. With Kubernetes, Novotny and others on the project worked hard to build easy on-ramps for contributors. The Google team that initially open sourced Kubernetes had to do a great deal of work so that would-be newbies to the project wouldn’t have to. The sooner a developer could become productive with the project, the more likely they were to become a long-term, active contributor.

SEE: The rise of Kubernetes epitomizes the transition from big data to flexible data (ZDNet)

The same is true simply for adoption. At Adobe we focused on improving our “time to Hello World.” We wanted our burgeoning developer community to spend minutes, not hours (or days!), getting things built with our APIs and other code. It became a driving mission for my developer ecosystem team, and was mostly about improving documentation, APIs, etc. and not about open source (though we did that, too).

Improving mean time to dopamine is also a matter of marketing (defined broadly). As former MongoDB executive Jared Rosoff explains of the MongoDB concept of “shelf space”:

I meet a lot of developers tools startups who seem to think that having this shelf space presence is something that just happens because you wrote great software. You need to invest in it. I’ve described how we approached it at MongoDB, and your software or service may be very different; but I believe the core tenants are the same – you must build SDKs, integrations, documentation and community that are targeted at the market segments you hope to capture, and you need to measure the creation and use of that content to gauge whether you’re making progress.

This was a sizable investment at MongoDB. In the early years, as much as 50% of the engineering organization was focused on SDKs and integrations. We had dedicated evangelists, docs writers, alliance managers and community managers who worked together to drive all of this forward.

The point of this and the other things mentioned above is to make it easier for developers to get productive, however that happens. If your first thought is how to make life hard for potential competitors rather than how to make life easier for potential customers (and their developers), you are doing it wrong.