THIS IS WHERE I POST MY BEST THOUGHTS.

A line drawing by Pablo Picasso | What’s with the random art?

This is the second part of my previous post insights. the developer buying journey, where I walked readers through how the developer persona interacts with the buying process and their role in a sale. I briefly touched on how open source projects play into the buying process, but would like to spend a bit more time on it in this post. In addition to covering open source, I’ll spend some time on the value of creating a developer program to build community and affinity around the projects that you contribute to.

why open source?

I have a very strong belief that the future of software is open. There are a few reasons for this. Mainly, the enterprise is always pushing for the standardization of technologies, which allows business to seamlessly happen at a global scale. However, regardless of the efforts made by enterprise organizations, standardizations are rarely lead by the enterprise. When they are, there is always a competitor that pops up and puts them back to square one. Maybe this is because we inherently rage against the machine or maybe it’s because even when working together the enterprise is still competitive? Regardless, open source is community-driven and inherently winner-take-all game. Ultimately, creating a standardization (aka adoption).

Wondering if I’m making this stuff up? Here’s some data by The New Stack.

The second reason is that open source attracts the brightest minds resulting in the best solution. The top open source projects receive contributions from developers across various organizations, they are not limited to a select talent pool like a corporation is. Making a contribution to an open source project is difficult. The code review process is in theory done by a community of developers all invested in the success of a project. If your contribution is not up to par, it’s rejected. This sets the bar very high for participants in open source communities, much higher than the expectation in an enterprise organization.

open source and bottom-line growth

Now that you know why I belive in and push involvement in open source, let’s talk about the most common argument for limiting involvement in upstream communities. Conventional business theory would argue that investing in open source is a negative ROI activity that ultimately creates a competitive disadvantage for your organization. After all, if you give your software away for free, why would anyone buy it? The same principle holds for investing manpower into open source projects that you don’t own or even directly build on top of.

We need to consider what I wrote about in part 1 and how open source plays into the developer buying journey. (If you haven’t, I suggest reading that post before you continuing through this one.) Open source should be viewed as a marketing activity, its ability to generate ROI is dependant on your ability to create what I like to refer to as hand-shake moments.

Side note, if you wanna geek out, check out this post from back in 1999 by opensource.org - Making a business case for open source.

By investing in open source you are participating in multiple high-impact activities. First, you are making an investment into the success of the projects that support your product. If the projects that support or even play a foundational role in your product die, you have big issues to deal with. Second, playing an active role in upstream communities builds brand affinity with developer communities. It’s the proof developers look for when they question your expertise. Finally, you are creating paths from upstream communities back to your developer program.

the value of creating a developer program

Back to those hand-shake moments we mentioned earlier. We like to talk about open source as ‘free-software’ but that’s a bit of an oversimplification. Open source licenses do have restrictions on usage which range from mild to severe. But more importantly, open source software can’t just be deployed into a production environment. There is always a question about security, issues with scalability, not to mention basic maintenance, integration, and hosting.

This is where the enterprise comes into play. The enterprise takes an upstream project and turns it into a product that can be consumed and put into production without the vulnerabilities and issues that are associated with an open project. They provide documentation for specific use cases and services to help implement the software which is how you create a business model based around open source software. Not to mention, no one wants to build the software that they build their software on …

Developer programs create a bridge from the upstream project to the enterprise product. They do this by providing value to the upstream community. As developers identify a solution upstream, they make the connection to the downstream product that will be approved by their security and legal teams. This is that hand-shake moment.

Developer programs are a gray area, they are kinda upstream and kinda downstream. This grayness creates a safe place for developers to explore and learn without being pushed by a sales process. This doesn’t mean that developers who are apart of your developer program are leads, but it does give you data on account interests that can be used as a leading indicator of an account entering a buying process.

I hope this helps to bring the developer buying journey post to a close. Thank you to everyone who took the time to request a part 2 on slack or twitter.

Love what you read? Check out part 3. Understanding the developer buying process.