Our prospective customers, especially those from larger companies, often ask us for access to our system’s source code.
Something may happen to you, they say, and generally why not?
In some cases we grant their request (against hefty financial guarantees of no leak) and give our source code away to the customer.
Those cases are when the expected profit reconciles us with the client’s bizarre whims.
Because he needs our source code as much as a fish needs an umbrella.
Open source software is simply in vogue, dear readers. Just fashion, and nothing else.
Any fashion trend rests on a number of rational assumptions that are true for a limited set of cases.
However, if thoughtlessly applied… As Barak Husseinovich Obama said, ‘Just because we have the best hammer does not mean that every problem is a nail.’
There are three such initially rational theses that apply to open source software:
- Open source code is safe and reliable.
- It lets you modify software on your own.
- And be independent from your vendor.
The safety and reliability thesis
... is true for simple applications with limited functionality. Full stop.
The open source model means that an indefinite number of developers have access to the software’s source code and can propose changes.
In the case of simpler software, there can well exist an enthusiast (or group of such) who developed it initially and can keep an eye on its entire code and monitor its development in an efficient manner.
However the dedicated person (and/or group of persons) bears no responsibility whatsoever, even theoretically, for the quality of the software’s operation.
It depends exclusively on the individual’s (s’) goodwill and personal integrity.
Here is a real-world example: a catstrophic safety failure of the SSL encryption protocol (which adds the letter ‘s’ after ‘http’ in your browser’s URL bar).
The point is that for nearly four years, 2011 to 2014, the main Internet encryption protocol based on open source software had something more than a vulnerability – a mega hole the size of the Grand Canyon.
Some five hundred thousand ostensibly protected websites were at risk.
Importantly, the mega hole appeared in OpenSSL exactly as a result of the open source model: some external dude suggested still another modification, the enthusiasts’ team didn’t check it thoroughly, and the faulty code got into the release and was disseminated at once.
If a commercial vendor had released OpenSSL and somehow managed to stay in business after the scandal and the resultant lawsuits, they would have certainly been forced to fire all their management to the dogs. To make an example for their successors, so to say.
What sanctions do you think were imposed on the Open SSL developers?
That’s it.
Incidentally, more than three hundred thousand sites were still in the vulnerability area as late as two months (!) after the problem was detected, according to the same Wikipedia entry.
For big and complicated systems (and full-fledged ERP system, particularly the Ultimate IEM solutions, comprises millions of lines of code), a sufficient number of organized, competent, and unmercenary bona fide enthusiasts cannot be found even theoretically. Otherwise, Communism would have really been built by the year 1980.
On the other hand, a commercial software vendor has both an organized team and money to maintain it. And, most importantly, it is obviously and strongly motivated to keep its product working well.
And is responsible for it.
Modifiability
Freedom to handle any programme’s source code certainly makes it modifiable to the greatest extent possible.
However, as we shift our gaze from the proverbial spherical horses in vacuum to the down-to-earth needs of a business, we must understand that ‘the greatest modifiability possible’ is by no means equal to ‘the greatest modifiability that is useful’.
If it were not the case (why not fly high?) we’d have to use open-source operating systems only, and only CPUs with modifiable instruction sets, etc.
What might not happen!
The enemy is on the watch! Reliability, safety and import substitution are our priorities!
Any junior lieutenant or Federal Security Service officer will tell you that.
And if we are guided by common sense (= maximized profit for the business in the long run), we should reword this question as follows:
- какие требования к уровню модифицируемости системы налагал бы императив возможности реализации любого потенциально полезного функционала?
It turns out that this problem definition is well satisfied by open systems (not to be confused with open source code!) that have interfaces for implementing virtually any custom functionality – while the system’s own code is closed.
A mundane example of an open system is the Windows OS. A system with a proprietary source code, on whose basis, however, a Windows application can implement almost any possible behaviour.
And the restrictions imposed by the operating system mainly relate to security, differentiated access to the physical PC resources, and multitasking.
If we descend from the theoretical empyrean to our muttons, our Ultimate Solid platform is similar to the Windows OS.
And the 100% open ‘configurations’ that run on top of it (the commercial ones, eCommerce, eService, Industrial, or the Ultima 2C freeware; or any other, written by an external developer) implement any useful features that are conceivable.
Vendor Independence
As you may have guessed, the extent of real-life independence is similar to the safety and reliability situation.
And the causes are the same.
For large-scale and complicated systems, this ‘independence’ dialectically turns into its opposite.
Again, here we are enslaved NOT to well-motivated commercial companies that depend on their customers’ loyalty and satisfaction, even financially, for their survival – but to a loose assemblage of anonymous geeks for whom supporting and developing the product you’re using is no more than a hobby.
Your grievances will be most welcome there, of course.
Or maybe you are as cunning as a fox and think, “well, we download the source codes, take programmers on the staff and go on ’supporting’ and ’developing’"?
Under kind of full control and careful guidance?
How far away now is all that lightness
And all that innocence! Ah, backwards yet,
From black winter fled, to the Springtime of regret,
From my disgust, my boredom, my distress.
Paul Verlaine
There is no guarantee that the changes made by your developers in open source software will be accepted by its Core Team.
False self-confidence compounded by a lack of competent guidance (which is nowhere to be found in your company) leads your hired programmers to tamper with the open source code instead of using the open interfaces.
The must be wearing that Imbecility and Courage chevron (an Internet meme) and thinking: ’Am I a schoolboy to read your API documentation? I’m nobody’s fool – I’ll get into the core now and fix it all’.
It thus becomes less and less possible and, eventually, quite impossible to upgrade the system from its common repository.
These are the small but rapid steps that you make to SUDDENLY find yourself helpless with homebrew software.
We must note that we ourselves consider making the Ultimate Solid publicly available now and then.
As sort of a preventive answer to all source code fans. So that we don’t wrangle with everyone separately.
But each time (at least for now) we abandon this idea.
And not at all because we fear competition that may use our own developments.
On the contrary: being (b) down-to-earth but (b) on top of the problem, we understand that hardly anyone will ever want to wade through those very millions of lines of code.
And especially to undertake the gigantic and surely unprofitable task of ‘improving’ them.
It is exactly fears of reputational risks that stops us.
An upstart fool may well appear (and for some mysterious reasons, such persons are as energetic in direct proportion to their incompetence), ‘improve’ our source code and start promoting an ‘upgrade’ loosely related to Ultimate Solid right and left.
To fatally compromise the original.
And the megabytes of the source codes of Ultima configurations, the system’s very layer that implements the functionality of interest to business operators, are all open already.
You can never modify them all.
