Open-source software solutions, including components and libraries, are the preferred choice for many developers who need to solve some particular task or add a feature to the software being developed. Yet commercial libraries can offer more than you can think of.
Open-source software (i.e. software offered under free licenses with freely accessible source code) gains popularity day by day. The reason is obvious – price drops for the end-user software make it harder to invest cash into software development beforehand. And in case of in-house activities stiffer IT budgets make programmers choose code snippets of unidentified quality.
However while open-source libraries and code snippets seem to have zero initial cost of use, they start to consume resources later, during life cycle of your software. And commercial libraries can offer more than you can think of.
I will focus on professionally developed commercial solutions: putting a price tag on your code piece doesn’t magically turns the code into the industry-level commercial product. Commercial library must be evaluated thoroughly to answer the question of how professional it is. Not everything with a price tag is good, that’s obvious. But if it’s commercial, chances are great that you will get the things missing in open-source offerings.
Let’s review what exactly commercial software (and specifically component and class libraries for software developers) can offer, and then discuss objections and counter-objections.
Documentation and samples.
With modern APIs becoming increasingly complex documentation and samples allow easier and faster code reuse. You just copy the piece of code from the sample and it just works. If you need guidance, you can look into documentation to figure out where to go next or why the function could fail.
Adepts of open-source software claim that the source code is the best documentation. Maybe it can work as documentation when the code itself is well-documented, with comments and well-written (with proper formatting and variable and function names). In most cases the code is not the most entertaining reading in the world though.
Various studies show that presence of source code sometimes helps in diagnostics of various issues, but does not help much in use of the software simply because you don’t know what to look for.
Also documentation should be written by technical writers, not programmers – programmers don’t like and don’t know how to write proper documentation. Let programmers do coding and technical writers write text.
Carefully crafted APIs
Any software as a complex engineering product requires design and development before it can be implemented in bare metal in code. Writing 1000 lines of code from scratch is not the same as designing those 1000 lines beforehand and then implementing the design. Proper design can turn 1000 lines of code into 200, and bad design would lead to 10K lines of code that needs to be written.
When it comes to open-source libraries, many of them are developed evolutionary, i.e. something small is created, then features are added like new toys on the new year tree. And in the end you get the construct that is as fragile as a new year tree.
In opposite, commercial APIs are in most cases designed with both ease of use and extensibility in mind. Often there are several levels of APIs in there, for low-level operations (where you get maximum control) and for high-level tasks (where you an get the job done quickly).
Finally, open-source libraries are mainly developed by coders, while professional commercial solutions are usually designed by software architects and analysts, and only then coded by programmers.
As the goal of open-source developers is to deliver something and do this fast, usually only the most popular functionality in certain application domain is implemented.
Developers of commercial libraries have to stand out of the crowd and implementing wider scope of functionality is one method to accomplish this task.
The problem of extensibility (i.e. getting a feature that you need) can not be easily solved with open-source other than coding the feature yourself, which is almost always not an option, especially when the issue to be addressed is far from your area of expertise. With commercial software you can negotiate the extension to be made for you or to be included into the future software releases.
The motivation of the commercial vendor is to keep his business running, and this is the effective motivation. For open-source developer even one-time fee you can pay him can be not sufficient to motivate the developer to extend the product (which could have been abandoned long time ago, as it frequently happens in open-source world).
One more benefit of unique features offered by the component vendor is that such features let you create a USP (unique selling point) of the end-user software that you create. And when you do in-house development, those feature let you please the boss and show your attitude towards helping your colleagues and the business itself to act efficiently. In other words, those features show that you care about your user.
One of the most valuable assets of every business is trust of its customers. You can’t run a business for a long time when customers don’t trust you. And in software business, where relations are long-term and information flies easily, trust is a must.
When the bug is encountered, it’s the best interest for the commercial vendor to fix it, or trust will be lost. And the customer needs to be assured, that should the issue arise it will be addressed in the shortest possible time.
With open-source libraries, even if you submit a bug (when the developer provided you with such possibility), you usually have little hope for this bug become fixed in any foreseeable future. In opposite, bug fixing is sometimes offered by open-source developers for a fee that far exceeds the cost of the license for comparable commercial product.
IT world is about links and connections between various actors – servers and services, client systems, mobile devices etc. With so many actors, changes and updates are frequent and you have the environment to which your software must adapt all the time. Otherwise you get compatibility problems, dissatisfied and complaining customers and finally business losses.
When you use third-party components in your software, they need to be adapted as well. And as with new features, adaptation of third-party components and libraries is much easier when the author is motivated for this.
Also for the running business maintenance and compatibility updates are one of the ways to inform their users that the business can be relied upon. So there exists a big chance that the required adaptation will be performed by the vendor even without your request.
It’s not a secret that you often don’t need a third-party code when you can write this code yourself. That is true for general-purpose code, but can you take the risk doing the same in low-level programming or neural networking, OCR or cryptography?
No person is a specialist in everything, that’s why we have so many different professions and specialists that focus on some one particular question.
Commercial vendors, especially those offering specialized software and components, use services of such narrow specialists to provide high-quality products. The vendor has a specialist in the application domain (eg. in OCR or networking), a specialist in software design and a specialist in programming environments and computer platforms. Cooperation between those specialists lets you get a reliable product. But in case of open-source this is a rare situation. Specialists in application domains most often prefer doing their job for money and spend free time with their families and hobbies. It’s hard (though not impossible) to find a specialist who is a good software architect and programmer at the same time.
As a consequence, with commercial software you usually get a product of the higher quality (not just programming quality but quality of the application domain) than in case of open-source.
Initial development of the open-source software is often driven by curiosity, desire for publicity and other similar emotional factors. This works well for a short time, usually enough for initial development, but not for maintenance and especially not for assisting you with the product. In other words, if you need help, you need to search for it anywhere you can… or pay for it to the developers.
As with bug-fixing the cost of such individual assistance services usually exceeds the cost of the license for commercial software. The reason is simple – the business of the commercial vendor is based on insurance model, where total development and support expenses are spread among all licenses sold no matter how much support you “consume” (extra support packages are sometimes offered as well, but the overall scheme is the one described). In case of open-source products the only source to compensate development and support is to charge you for everything possible.
Investment in future
The “save tomorrow for tomorrow, think about today instead” mantra has brought humanity to the edge of ecological catastrophe. Apple’s bias towards end-users (which is just a cloak for desire to sell more hardware) has hut the whole software industry badly. People are used to pay 0 to 1 dollar for software and then ask “what? Do I have to pay another $0.99 for a new version of the software title that I’ve been using for 3 years? Are you insane?”. That attitude poisons the industry and slows down innovation. For some time the race for the first places in the AppStore and Play Store will make developers invest their time and resources into software titles, but calculations and studies show, that this race is more of a lottery with a little chance for small developers to succeed.
Paying for software and motivating the users to pay as well is a culture of consuming the software which will let the ISV industry, and especially small vendors, continue to innovate in future and do this with satisfactory budgets.
Finally, if you don’t pay for books you read, writers will stop writing and there will be no new literature to steal to read. If nobody pays for software now, there will be no skilled vendors in 5-10 years and no good and sophisticated software. Unlike music records, software vendors can’t give software away for free and do something else for living – that’s not a viable business model. So they will simply go out of business, and the world will become full of open-source stuff, unsupported and of unknown quality.
* There are many open-source titles, which deliver exceptional quality. Yes, there do exist software titles (mainly end-user and server software, rarely libraries) which are open-source and which offer great value. But if you look carefully, most of them are (a) commercial products, just sponsored by big companies or institutions, (b) often free only for non-commercial use but who reads those EULAs, (c) not as great as initially seems, with internal management problems, bloated code and design and implementation flaws that lead to necessity to rewrite the titles from scratch from time to time.
* Open-source is free and nothing can beat such price. Yes, the cheese in the mouse trap is also free. But unlike the mouse trap, free software is a trap for each mouse involved. There are costs involved in maintenance and bug-fixing and in migrating to other solutions later if the chosen open-source stuff suddenly stops working. And such costs can exceed the initial costs of the commercial solution in a several powers, especially if you try to rely business processes on free solutions. Even when you keep using the open-source solution, assistance either needs to be paid or you need to hope that someone in programming community helps you for free (with absolutely no guarantee).
* Open-source offers source code. Yes, and so do most commercial libraries. Commercial end-user software is rarely offered with source code, that’s true, but as mentioned, there’s very little use in such source code (other than to satisfy curiosity).
* Open-source is documented. Yes, with mystifying comments and unreadable and badly formatted code. Wiki and publicly maintained knowledgebases are a weak substitute to professionally written documentation.
* I can ask for samples in the programming community. You can ask but this doesn’t promise you the answer, neither you get a guarantee of the quality of the provided answer. The fact that something works in one particular case doesn’t prove reliability of the solution in real-life conditions.
* Open-source has as much features as commercial software. Yes, the feature list can be the same initially although this needs proof: commercial libraries have to stand out and features are a good method. In any case extensibility of open-source software is lower due to lack of the main driving force for such extensibility and often due to bad design.
* Open-source software has great APIs. Yes, and shamans can sometimes offer good medical services. But it’s a better idea to go to the hospital.
* I can modify the open-source product myself. Yes, and you can do the same with the source code of the commercial library.
* Open-source can also deliver unique features. Yes it can, but only for some time. All easy (and inexpensive) unique features become common quite fast. And really unique features need resources to be implemented.
* Open-source is better tested due to larger audience. “It’s better tested” doesn’t mean better quality. It means only more bugs in the bug tracker. And as bug fixing is generally slower in open-source than in commercial software, the latter one has a better chance to be of higher quality.
* the open-source library I use worked fine for me for years. Yes, in closed environments and in simple tasks the code which has been tested once will work for years and decades. However if this code communicates or interacts with other software and network, changes of external actors can bring your business down in minutes, and when this happens, you will have very little time to react.
* I have very simple tasks where no expertise is needed and where open-source works for me. A match (the one to get the light with) is a trivial thing. Or is it? The components of the match were developed for decades by numerous scientists in chemistry, biology and physics. Things you consider trivial now are the result of years and centuries of scientific research. And in software there are no trivial tasks and no trivial solutions.
* I can get assistance from community, I don’t need a paid service. And you surely ask community for health care, legal services, car repair services etc. But this is not effective and is like playing with fire – one incompetent suggestion can get you into serious trouble. Professional services are a must for any activity of the modern civilization.
Eugene Mayevski takes a post of Chief Technical Officer in EldoS Corporation, the company that specializes in development of security and low-level system components for software developers.