I’ve spent a good bit of time explaining the ins and outs of open source products: what they are, how to make money with them, and what they are not. Namely, products are products, no matter the source code license they are published under. But there’s a journey that a software project must undergo before it can be accurately labeled with the moniker “product.” This journey includes, but is not limited to, the open source supply chain going from upstream bits to downstream product, as well as a bit of special sauce branding, complete with trademark, that applies only to the supported product. But, I can feel a bit of grousing bubbling just under the surface: Why does it have to be so complicated?
Why can’t I just offer support and services for a software project? Isn’t that much simpler? In theory, yes, it sure does sound simple. And yet, history tells us that this approach fails almost universally. The reason? Too many people confuse “product” with “project” without understanding the massive differences between the two and how their trajectories are orthogonal. In fairness, offering support and services for a software project is a great way to bootstrap a startup before you really fill out your product jacket (mine’s salmon pink! Follow it on Twitter!) But that’s only for the short term and not a good way to scale a company beyond a handful of customers.
There are several reasons why your software project is not a product. Here’s a list of differences between the two and what those differences mean for software and service providers as well as end users.
The goals of a project are fundamentally different from a product
A project is not a place to put too many constraints. Your project is designed to a be a hub of innovation, and you never know where or when the ideas that drive your future revenue will strike. It could come from your engineering team. It could come in the form of a collaboration between your engineering team and others outside your company. Or it could result from your team collaborating with another team in the same company. Or it could come completely out of left field because Joe random developer started a discussion thread titled, “Hey, wouldn’t it be cool if…”
Not only is your project where the innovation happens, and you can’t accurately predict the time and place of that innovation, it’s also the place where people will use your software for off-label purposes. Maybe their use case didn’t quite fit your mental models, or perhaps they saw a unique dimension for your software that you never considered. This is why you create an open source community and project space: to make a safe place for innovation to happen. Constraining that space with product requirements is precisely how one kills a community or prevents it from ever really launching.
Products Are Designed to Reduce Risk
Where projects are about innovation and expanding horizons, products are specifically designed to scope out the lines of where, exactly, a customer use case is supported or not. You don’t want your product vision to expand like our universe, infinitely in all directions. You need to constrain it if you ever hope to be able to support your customers and scale out your operations. This means reducing your risk, as well as that of your customers, even if it means saying no to developing new features for the time being.
Having watched many products crash and burn, with a few actually succeeding, I’ve deduced that there’s a magic line where products are just innovative enough to be highly valuable for customers, but constrained enough to be profitable for vendors or other service providers. More on that in this article’s conclusion. But for now, think of this simple summary: projects expand, where products shrink or stay in a steady state. Failing to sufficiently reduce risk and thinking you can easily support software you just downloaded from an upstream .org is what I call a product management fail.
Product and Project People Are Different
In keeping with the above themes, separate goals also mean that the people you want working on each will have very different skills. You don’t really want your product management people heavily involved in an upstream project, and your forward-thinking project engineers are sometimes (often?) ill-suited for making the product sausage. Inviting product management to participate in an upstream project is like inviting investment bankers to an artist workshop: “yeah, that’s cool, but can I *sell* it?” There are exceptions, of course, and I never say never.
Obviously, engineering directives and requirements have to come from somewhere and don’t spontaneously generate from the ether. And often the upstream engineers will have valuable insight for turning the product crank, but it’s a matter of defining who drives what. Let the creative folks do what they do best, and let those who know how to fine-tune software be the most productive with their limited time.
The Project Risk Curve Is not Conducive to Supportability
I mentioned risk before, so what am I really referring to? There are several elements of risk relating to technology, but I want to focus on two which seem to come up fairly often in the software world:
-
The risk of software failing, causing an outage, or otherwise resulting in lost time and/or money. I’ll call this “infrastructure risk.”
-
The risk of being locked into a particular product and vendor. We’ll call this “lock-in risk.”
If you do a thought experiment and plot out the risk curves of each, you’ll find that they are inversely related. How so? An upstream project has significant churn: lots of new code checked in regularly, with many developers from multiple sources. The result of this is two-fold: Because no company dominates this upstream project, the risk of being locked into a particular vendor is very low. Conversely, the risk to your infrastructure is extremely high. One would have to do much more vetting and, in many cases, modification of software before deploying in production compared to most vendor solutions.
Now take a downstream product based on that upstream code: It will be an older release, having utilized significant QE and product management resources to hone the end product into something usable and reliable. Thus, the risk to infrastructure will be much lower, but because you’re using a solution from a technology provider, the risk of lock-in is quite high. Perhaps not as high as with a proprietary product, but still high nonetheless. I view the plotting of this risk curve as below, with a dashed line indicating the sweet spot for profitability for the provider and value to the end user:
Conclusion
In this analysis, I hope I’ve helpfully explained the difference between a project and product, why they’re both useful, and why one should never try to shoehorn the goals of one into the other. They’re different spaces designed for different things. Each is useful in its own right but to very different ends. A smart technology provider will have a nuanced view of each and will know how to utilize them effectively.
