FOSS model : reliability, accountabiity, support


#1

Folks,

so this is a discussion i had with a senior colleague at my workplace. a little background: we have an e-office system being implemented in our office by NIC, and i inquired the technology it is based around this guy from NIC tells me it works around open source technologies (PostgreSQL for DB and something else i cant remember ) and he explained why at NIC they moved away from Microsoft technologies ( citing majorly commercial reasons, lock-in, and them being taken for a ride by MS when support or system expansion is sought as reason).

so based on this i and this colleague of mine start discussing about why there is reluctance to implement big government projects or crucial applications around FOSS. My colleague, having seen few projects being implemented in his lifetime he makes few arguments which i think are worth answering in a little more detail:

  1. Accountability: Whose collar does an end customer hold and get a issue resolved? (Not that it very nice thing to do but in current scenario that is what happens in crucial projects, where crucial data is involved).

For example: if in a project lets assume XYZ IT firm deploys a solution around Oracle DB. and a issue comes up tomorrow . consumer can hold XYZs collar and ask for them to fix it. in turn IT firm can hold Oracles collar and fix it if necessary. ( and believe me this happens and be sure that customer always builds these clauses into the contract for such projects. and scenarios like these are common where support form actual vendor of a technology is sought to resolve a issue.) for such response from vendor, the user might be willing to pay butt loads of money as license fees to vendors. .

when it comes to FOSS, it is perceived that this collar holding isn’t possible. citing the reason that when a technology is developed by a loosely bound community, with no actual commitments, rather voluntary contributions, how can i hold somebody accountable. How can one guarantee that such support is available when i am deep in shit? who do i hold accountable ( more like who do i point fingers on)?

2. Reliability : Ooo this vendor has been market for ages. why would i choose a new FOSS technology whose reliability there is no backing for?

This criteria becomes all the more crucial when your data is more important. for example : a bank, or fare collection system of a transit system, ERP on which your companies processes are running etc etc.

so there might be a consumer who is willing to install e-office for his admin and HR departments since it is slightly less crucial. but when he has to take a call on which technology to use for handling crucial data/applications, the choice will be a proprietary product marketed by some big MNC, citing the same reason as market standing, been in market for so long ergo reliability etc etc.

  1. to this my answer was largely that these apprehensions are more to do with how you execute a project. but you cant really say the technology developed in FOSS approach is of lower caliber. If lets say some MNC is backing a product based around some FOSS technologies you might feel comfortable.

But then again, why dont you see IT firms, the likes of infy or tcs or wipro, wont market products based around FOSS but would still harp on products of IBM or Oracle or MS etc.

if you were able to survive that verbal diarrhea, you view points will be much appreciated.


#2

Microsoft and Apple spy on their users, yet you are unable to hold their collars :smile:


#3

Accountability is a valid concern

Whether a company is deploying a commercial or open source software for a mission critical application, one of the concerns is the same. How soon can you get a solution if a critical production bug is found in the underlying software?

It is not enough if you just buy a license from a commercial vendor. You must be able to get them to commit to an SLA (Service Level Agreement) or severity of the bug vs turn-around time. In addition, when the bug actually occurs, the burden is on you to prove that it is in their software. When you open the ticket, they will ask for scenarios to reproduce the bug, crash logs and so on. Even after providing all that, they may point a finger at your application that is running on top or the network or the operating system or any number of other things. Nailing the problem on them and demanding that they provide an immediate fix or work-around to honor the SLA itself will need skilled technical personnel and capable management.

Some companies do use open source software for mission critical applications. If you do, you have two options. You should either have skilled people on your team or you engage a support vendor who does.

On one occasion we used an open source encryption software for a banking application. When we ran into a bug, one of our star developers was not only able to find the root cause and develop a fix but also contribute that back to the open source software.

On another occasion my company decided to use Apache Tomcat as the application server. We located a support vendor who had people on their team with commit rights to the Apache Tomcat source tree. In the event of a critical production bug, they assured us that they will be able to quickly provide a patch to us to fix the bug. They would then contribute that patch back to the source tree so that it will become part of a future release. This support did cost extra but not anywhere near what it would have been to buy licenses for WebLogic or WebSphere which were the commercial options we had at that time.


#4

Ashoks answer’s valuable. Here’s some more:

The perception that Free Software is not supported needs to change. And most importantly, the perception that Free Software is developed without regard for enterprises has to be changed. It’s not as if Free Software developers are renegade anarchists trying to moon light as coders. :smile:

Several Free Software distributions have specialized, extremely stable versions of their software just for enterprises. For example, Mozilla has the Extended Support Releases (ESR). Ubuntu has Long Term Support versions (LTS) . Even LibreOffice has a stable conservative version for people allergic to drastic updates.

It’s not new news that RedHat, SUSE, and Ubuntu Linuxes have solid commercial support licenses backed by very rich companies like Canonical. But third party support is available even for completely community driven software. LibreOffice has support from Collabora, CentOs support can be obtained from Openlogic. We should somehow identify and clear the myths surrounding Free Software in terms of reliability and accountability.