Open source or Proprietary?

Open source or proprietary; what technology to choose and when?

I might be biased, in fact, I am biased. In my previous life, I earned a living writing open source projects for commercial companies. Actually, some lucky stars were shining brightly, giving me the chance to do that at the beginning of 2000. What was not pure luck, however, was my fascination with open source, and my belief that sharing is caring and maintaining something diligently out of pure passion is something that should be deemed with respect.

It is somewhat challenging to assess what impact it will have over a software product’s lifespan, the choice of platform and technology. At least on the enterprise side, most software products will have a lifespan of at least 30-40 years. One would expect that a product will be rewritten a couple of times entirely during this time. Reality teaches us that some products are, but the majority is not. Assessment is usually tricky because, as a software engineer, you interact with a limited number of companies, so you don’t get enough exposure to form an opinion.

But I have been fortunate to be part of many merger & acquisition teams in the past years in charge of the IT due diligence part. And, I got to see many successful software products. The nice part of the IT due diligence process is that you get to see a time-lapse view of a product’s evolution. As a software architect, this is extremely valuable as often, the result of an architectural decision can only be seen in a number of years.

One thing that I noticed during the due diligence process is that products built on open platforms (C, C++, Java, Python, PHP, JavaScript, etc.) tend to age better than products built on commercially locked platforms (Cobol, RPG, VB, PL/I,  Delphy, Uniface, Progress, ProIV, etc.).

I am not talking about aspects of technical debt. Given a long enough project, debt will creep in regardless of the platform or technology, although in different ways.

There are at least three areas in which differences emerge between open source and commercial platforms:

1. Availability of skilled resources
2. Inability to support technology-based innovations
3. Unsustainable cost constraints

Let’s examine each of the areas.

Availability of skilled resources

The entry barrier for open platforms is low. They cost nothing. You can find distributions prepared by enthusiasts or the corporations driving their development for many of the mainstream operating systems. Universities and schools choose many of these platforms for teaching purposes because of their open nature. Many of these platforms will be supported and used by enthusiasts in niche areas like the Internet of Things, Machine Learning, Big Data. All these reasons further increase the adoption and literacy across developers.

I wasn’t surprised to see python as the first real programing language in my son’s curriculum, taught in the 7th grade, but I still found C/C++ in the same manual. That means that systems built in C, 40 years ago, will have 40 years of graduates who, even now, officially learned C.

This implies that projects which have chosen open platforms have a much greater chance of finding developers. These developers are already proficient in or at least familiar with the technology and will not have to be trained from scratch in a particular niche technology. And we did not even address the question if these developers would have any interest in learning new niche technologies.

Inability to support technology-based innovations

Another observation is that you can never guess how a particular platform will age.

Cobol, for example, will genuinely “get” what is what their customers expect. The ability to run on newer and less expensive hardware, backward compatibility (40 years old code continues to work), support for more relational databases, scalability, and ability to integrate through standards-based SOAP or REST platforms.

But other commercial platforms will lose their focus, wandering off in strange areas or territories, confusing their users. At the same time, the worst of them will struggle with essential and important aspects like being able to provide basic integration means or straight-forward abilities like building a simple web interface.

Open platforms tend to fare better in supporting newer technologies or approaches because of the larger user base. Enthusiasts will usually invest in porting or extending the language with the new technologies or practices, thus providing better and cheaper access to innovations.

Unsustainable cost constraints

The most significant impact on a software product based on closed platforms is licensing costs in the long run. It probably has to do with the evolution stage of the platform itself. While in the early stages, customer growth is present, and licensing costs seem reasonable and probably in line with the benefits the platforms provide to their users. However, in time, as these products turn from stars to cash cows and turn slowly into dogs ending up squeezing their users for more and more revenue or force them to deal with discontinuation and big and costly rewrites.

From what I am seeing, it is not a question of if this is happening to all the proprietary platforms; it is more a question of when this will happen.

So what does all this mean?

So would this mean that all products should be based on open platforms? My answer would be, of course, yes, but. The but is a big but.

Most of the time, a specific platform is chosen because of an advantage that this particular platform provided (most of the time, this is productivity). We are still seeing innovative new platforms being developed that promise substantial productivity increases; you don’t have to look further than the new wave of low-code or no-code platforms. R&D managers are lured to these platforms exactly because of the advantages that they bring in comparison with traditional platforms.

I would suggest that for core products, the ones that are the foundation of your revenue and that you expect to invest and develop for decades, use well established open platforms.

For niche product modules, add-ons you can choose specific platforms that would bring you the most advantages. Especially for new initiatives that are yet unvalidated, you can decide to minimize your initial investment through platforms that trade openness for productivity. Still, with a plan to migrate them on open platforms, the moment the initiatives turn into core products.

If you already have your core products on locked in platforms, what you can still do is ensure you have the rights to use your existing versions of the platform perpetually. Also important would be to make sure you get the source code of the platform if the supplier sees to exist. It might not always be an option, and even if it is, it might not be the best option. Still, it is better than having to face a significant rewrite after a change in your supplier strategy.

As you can tell from the beginning, I have always been and will always be a big fan of open source platforms. Yet I have colleagues who fully support commercial platforms and see the added value for their clients. We have great debates on the topic, respecting each other’s valuable input. There is more than one religion, more than one road leading to Rome, and more than one opinion on platforms. Give me a call, or drop me an email, as I am always interested in hearing other people’s opinions.

By Remus Pereni, CTO Yonder