Why your organization should open source its software

The question why organizations open source their software, is perhaps a mystery to most. Over many years of experience in software has taught me why. In this article I wish to share why it makes sense.

The article is subjective to people building general purpose software and looking to scale its use-cases over time. It also assumes that the technical know how (Technical IP), to build it or fundamental components are public domain or will be public domain in the the time it may take to actually market the product or software.

Technical IP in this article, refers to technology and not the domain aspects of your application or software, that cannot be replicated easily without significant investment in time and money.

If your revenue depends on your technical IP as defined above, then the matter in this post may not apply.

Lessons from my past

I have been writing programs and software for over a decade; short of two decades to be precise. After working on applications written for businesses over most of this time; I decided to venture on my own into e-commerce, B2B and B2C applications, Apps and founded my company under which I wrote my own platform to service multiple clients. The platform performed (and is still performing) beautifully in pure technical terms. At a point in time, I was able service multiple (15+) clients without any additional staffing as I grew, sustained over years and without a single critical bug in production. I should add that this involved getting the business, requirements, customizing it myself, operations, maintenance. Most of these applications had custom needs too. I’m not talking trivial website projects, but also business logic intense complex applications. This led me to believe I had a secret sauce, and why would I want to share it or open it! But the lessons I learned later is what this article should help you understand why I believe otherwise today. These lessons are further strengthened by similar observations in organizations and start-ups I have worked with.

Software as a liability

Any business is looking to make profit. There is a tendency to hold onto your golden goose. As a consequence of your investment in time or money, it is quite natural to go by instinct to only protect what you build. However, one needs to realize that …

Software is sometimes more a liability than an asset

… For anyone who has ever invested in building software, this should not be a surprise. Over time documentation, manually testing and operational aspects like deployment, bug fixing, regressions of software become challenging and drain.

I personally was aware of these from the get-go from my experience in enterprises earlier and was able to mitigate these risks; but there is even a bigger realization even if you were to overcome this…

Most proprietary code is inconsequential

The realization that most proprietary code itself is inconsequential in the long. The more one protects it; the more vulnerable it is to decay, lack of validation, constant strain on an organizations resources.

Not to mention IP costs, if one were to go that far. I did even consider patenting my software; lucky for me the IP laws in India were weak and I saw little point.

Even the sales people selling your software, sell it on its abilities and perhaps care little about what is inside.

Technical people make the classic mistake of believing that what is inside matters. It matters in a very literal here and now way, but not in a way should matter to any business.

When I say literal; how a system works matters to its current state of existence. I have learnt that business is about scale. I define operational scale as; Investment in assets which increase profit by reducing costs as volume increases.

Code is not an asset; unless it is supported by documentation and testing that evolves with it. A great way for evolution is to involve or create a community.

We will discuss communities more later in this article.

Risk of being captivated

There maybe a time when the daily routine of maintaining something which is not directly earning revenue, may prevent you or your organization for seeking newer opportunities. As you build, you maintain. If not open, the entire pressure of maintaining the system rests on your organizations shoulders and will need further investment internally or externally in terms of additional funding. In other words you are not only loosing new opportunities where your money and time can go, but have captivated your self in a fallacy.

Security

The world of software security does not trust the brilliance of your software; it only trusts validation and accreditation for formalized industry standards. Open Source gets validated. Organizations may question you on standards like PCI/DSS compliance, SAST, DAST, SCA. While PCI/DSS compliance is a different beast; using open source makes SAST, SCA possible and also a lot easier with adoption of your code by others and validated by others. Taking this responsibility alone (proprietary) is a daunting task. Going Open not only helps you detect these vulnerabilities earlier at a lower cost but also gain credibility as adoption increases.

How will I make money and what to Open Source?

At the beginning of this article I suggested that If your revenue depends on your Technical IP you may skip. Excluding that, we can be certain that nothing you are building can’t be built by your competitors. Which means the value add is assumed from the domain expertise or business model. This implies, that it is the final layer that puts it all together as a service is what brings in the cash flow.

The logical next step is to understand that most of the building blocks that you spend maintaining, do not bring you money but cost you as explained in earlier sections (liability). … (1)

Consider an alternate argument to further strengthen the above if you are still not convinced. Lets assume you used no open-source technology. How much time and money would it take you to reach the end goal of your product? And did it even matter that those building blocks that you happily consider ready to take were built by you or someone else? … (2)

If you combine (1) & (2), your reach a corollary that the building blocks do not contribute to revenue directly. Plus the added benefits of trust, validation, communities.

What is great, is that in addition to your direct source of revenue from you service layer; if your components evolve and prove useful to a sizable community then there is every chance for you to recognize future revenue streams as services over them and monetize them.

Communities

A software must evolve and not just depend on the people who built it. Evolution implies its value being validated by a community. The community must be free of internal leadership decision making. The community brings in the following value:

1. Validation : Is it really worth it or just your perception
2. Adoption: Software adopted by a community, is less likely to fail as adoption increases. Microsoft windows was pirated a lot in the 90's. But that same piracy led to mass adoption of a generation that later was more versed with windows and resulted in commercial benefit. Macs success was also based on community defined by people who identified that the mac was artistic and cool. True, while these were not open source, however on the point of adoption they did have communities and cults.
3. Liability becomes responsibility: A direct consequence of adoption is that your liability mostly becomes a responsibility. So your costs may not reduce, but the nature of investment in your software going in more long lasting activities at least.

Creating and managing a community is a responsibility and has its own costs. However this can become an investment in building a brand and a product at the same time.

Type of community and license

Think about the kind of community to build and how your organization intends to support it. Read up on Open Source license types, to suit your long terms business goals and community.

If setting up a community seems to be daunting or confusing then consider contributions to the software stack you are already building on and being part of the community it is based on.

Contributions

If your organization does not have the maturity or resources to manage one, it may be a good idea then to join an existing one and contribute to that. Build a product on the same platform the community supports. In a way this is what most people do anyway, but sadly only leech of open source software without contributing back in any way. Contribution is the next best thing to developing your own. The upside of contribution is that it also teaches you more about communities and building one in the future.

It is the same reason why someone else would contribute to your initial work.

Eat your own dog food

Lessons learnt looking at proprietary software

When building my e-commerce platform. I had to look at existing open source, and SAAS models like Shopify. I built comparison models.

In my research at the time, I uncovered based on data available that most of the proprietary e-commerce did have higher revenues than the open source ones who were making money of services. So in a way I felt discouraged to make it open-source (and I did not). Looking back and tracking the same today, I realized the following:

1. In the long even for proprietary software to survive, base versions were open sourced to drive community adoption and lower entry to barrier.
2. Adoption driven by communities turned out to be essential.
3. Many large proprietary products cannot sustain on product revenues alone in the long. The open source ones will eventually catch up and out grow them.

Conclusion

I don’t believe I am a great or even a successful business man, however I have understood what will not work in the long. Some people are hustlers and good at making it in the short. I cannot talk about success achieved that way. But open source and community building has its commercial benefits as explained at the fundamental level. Last but not the least, seeing something you build grow beyond the seeds you sow has a satisfaction that even numbers cant explain!

Reference

• 9th Nov 2023 added: Building a Business on Open Source