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.
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.
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).
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.
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.
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.
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.