Moq, FluentAssertions, MassTransit, AutoMapper, MediatR – if those NuGet package names sound familiar, it might be from all the recent controversy.
The authors of these free, open-source .NET libraries announced they would be going commercial, and that lead to a predictable backlash from users. So much so, that we had to write an article on how to block FluentAssertions in ProGet article after dozens of inquiries.
As a commercial software vendor myself, I think the negative reactions from developers and companies are completely justified. Ultimately, this was a poor decision by those library authors and it will probably not lead to the outcomes they expect.
In this article, I’ll explain why and talk about what FOSS authors can do differently. Spoiler alert: it’s to follow a model like Inedo’s by building a freemium product like ProGet then learning how to market it.
It’s not easy, but this approach will create a lot of happy users (free and paid) and not only lead to profit and great jobs, but build interesting and fulfilling opportunities for all involved.
Why the Negative Reactions are Justified
I’m obviously a big proponent of commercial software and would love to see the authors of these libraries build a development-tools company like Inedo. But to sell software in this niche, you need to understand the buyer – i.e. developers and their companies – and why sudden-commercialization is a poor approach.
Developers: Feels like a Rug Pull
These developer libraries are more than just code – they represent an opinionated approach to solving technical problems. They’re a form of best practices, and adopting this kind of library means that you’re agreeing with the author’s opinion and advocating for it in your organization. Even if end-user developers don’t contribute to the GitHub code or discussion, many feel like they’re part of a community of like-minded developers. It’s not unlike fandom, and how consumers often feel invested in the creativity and production of television shows — despite never buying the DVD or merchandise.
But the most important factor is that the developers would have never used the library or followed the opinionated approach if it were commercial. This free library was a part of the value they brought to their employer, along with their years of experience in building software.
This sudden-commercialization now puts those developers in an untenable position. They would need to tell their employer that, in order to continue using the architecture and algorithm they advocated for, the company will need to spend more money.
Instead, it’s easier to take the opportunity find a newer, better approach and “write off” the transition as technical debt. Especially since they’re likely only using a fraction of the features in the library.
Company: Too Much of a Risk
To make matters worse, purchasing a suddenly-commercialized product is big risk that’s likely not worth taking. From the buyer’s perspective, this new company is now a fledgling startup with a unproven business model. It’s inherently unstable and a poor choice for a dependency. How long will it take to go from almost zero sales to profitable? What if pricing changes next year? What if they pivot the product? What if they go belly-up?
This makes it even harder for end-users developers to sell internally.
Contrast this to a popular OSS library with track record of bug and security fixes. Even if the author suddenly quits, it’s highly likely that someone else will pick up the pieces. And in the worst case, the library could probably be built from source code.
Sudden-Commercialization is Lose-Lose
With rare exceptions, suddenly commercializing an OSS library will make things worse for everyone involved. But especially for the author, who’s dedicated hundreds or thousands of hours over many years building it.
At first, there will be the glimmer of false hope – a number of sales from ardent champions. These will mostly be superfans with enough sales skills to overcome internal objections, and the sales will be staggered in a way that seems like growth. But overtime, the sales will slow. As will new user adoption. Developers will stop recommending it and, ultimately, there will be fewer and fewer champions who push through sales internally.
There likely won’t be enough sales for the author to quit their day job, let alone hire like-minded developers and start the company they were dreaming of.
Fortunately, there’s a much better route.
A Better Way to Commercialize Software
If you’re an OSS library author, this section is for you.
First and foremost, a hard truth. It doesn’t matter how much value your library ads, there is simply no market for developer libraries and components. There hasn’t been for almost twenty years, and the few remaining companies that sell components (e.g. our friends at Infragistics) have shifted their offering to UI/UX platforms.
If you want to make a business around your library, you to first build a product. There are three main choices:
- Services/consulting around your library / opinionated approach
- Customized/specialized versions of your library
- SaaS or server-based companion tool
None of these choices require or preclude you from maintaining your library indefinitely. For example, you could go the NServiceBus route and eventually drop the free library.
However, unless you want to rely on fate and sheer luck, all three options will require marketing to be successful. That doesn’t come natural to most engineers, and it took me a long time to learn.
I think keeping a free library is the right move and will help a lot with marketing. That’s what we do at Inedo, and it’s a path that anyone can follow to create a business around their software passion, whether open source or not.
Our Journey from Passion to Product
Before Inedo become a product company, we did software consulting with a focus on build and deployment automation. In those days, many companies had “build workstations” that developers would log-in to, run some commands, and then copy some artifacts to the server.
There was a lot of room for improvement, and I loved automating things. After implementing the same approach at a number of clients, I finally decided to invest in creating a product called BuildMaster. That led us to discover even more room for improvement, and eventually I invested in as second product called ProGet.
But for ProGet, I wanted to try something new: give it away for free. Or at least, the good parts – that is, the Core Value.
ProGet’s Core Value is Free
Anyone can experience ProGet’s Core Value with the free version. That means they can:
- Curate open-source packages from public repositories
- Centrally manage all their own packages and containers
ProGet Free edition has no limits on the number of packages, how many feeds (repositories) they can configure, or the number of users. I’ve seen free users with terabytes of packages and containers in a free instance – and it worked just fine.
So why would anyone pay for ProGet? There’s rarely a single reason for any buyer, but instead a combination of many reasons.
Users Pay for One-on-one Support
Inedo’s high-quality support definitely helps sell ProGet. Our secret is to not use chatbots or clueless customer service reps. Instead, our users work directly with our product engineers (including myself), to get help when they need it.
This not only translates to top-tier support with no escalation needed, but it also gives us – the tool builders – feedback on how our products work in the real world, and how we can improve them. Which we can quickly apply, especially if they’re bug fixes.
Paid-only Features Also Sell Software
ProGet’s paid-only features also help sell, but the features by edition won’t make much sense if you’re not a ProGet user.
Broadly speaking, there are two types of paid features:
- Simplify ProGet Management. For example, retention rules will automatically delete unneeded content to declutter and save disk space. Another example, LDAP integration means users don’t have to remember “yet another” account.
- Introduce New Use Cases. For example, Vulnerability Scanning & Blocking features automatically scan open-source packages and container images for vulnerabilities, allow users to assess the risk they may pose, and ultimately block risky content.
Over all of these years, I can’t remember a single user complaining about us adding a paid-only feature. Just the opposite – adding a feature was exactly what they needed to push a purchase through.
Keep the Core Value Proposition Free
I really struggled to apply the freemium model to BuildMaster. We tried so many things over the years: 5 free users, 10 free applications, 20 deployment target restrictions, and then various combinations of the three.
None of it really worked, and it was pulling teeth to get feedback on why users weren’t buying. The little feedback we received didn’t make much sense; it was always something like that’s a lot to pay for that 6th user.
That was really frustrating to hear. We already had a lot of paying customers with 10, 50, 100, 250+ users! They never felt it was too expensive.
The problem should have been obvious: we were not giving away the core value proposition.
BuildMaster’s Core Value Proposition
With BuildMaster, the core value proposition is to give the entire team visibility and control over the release process while automating builds and deployments.
By restricting the number of users, we prevented teams from successfully implementing a:
- Centralized Command Center for application and development tools that provides real-time information across applications, deployments, and releases for everyone involved in software development, especially stakeholders
- Multi-cadence Release Cycle so that different applications can explore and implement stakeholder-driven releases that balance stability and innovation while maintaining centralized visibility and governance
- Self-service Deployment that promotes a culture of ownership and accountability among development teams and enable stakeholders to review, approve, deploy, or even rollback releases without communication bottlenecks without worrying about compliance with governance
That’s the core value proposition of BuildMaster, and that’s now free.
Finding the Right Path to Commercialization
Although Inedo is not a FOSS company, we do provide powerful free tools and have a ton of nonpaying users that will never buy. On paper, these non-converting free users look like a drag on the business. That’s why, back in our scaling-up days, our advisors and investors pushed hard for us to drop the free editions and focus on sales.
In retrospect, I’m glad I was too stubborn to follow their advice. Just like a suddenly-commercialized FOSS project, dropping our free editions would have certainly led to a handful of begrudging sales. But it would come at the cost of years of goodwill and trust – and even if that somehow led to faster business growth, the cost is just not worth it for me or the team I enjoy working with.
Instead, we will continue to make money the old-fashioned way: studying our market niche to build products and features that users will find valuable enough to purchase. That’s worked out great for everyone we’ve followed, and and I hope to see FOSS authors take this same path.