It is commonly accepted that where a supplier as part of its infrastructure installation provides a proprietary software solution and something goes wrong, there are SLAs and other guarantees that can be invoked to ensure that the supplier is not hit with penalty charges, further where there are issues with the software the supplier can look to the proprietary software manufacturer to offer patches and fixs or an alternative solution to bring their software up to scratch as part of their ongoing obligations.
However where OSS is used, the argument goes, there is no similar means of offsetting the risk. Can people please provide comment as to how this can be overcome, or indeed if you are currently using OSS within a school environment how you have or are overcoming this obstacle. Thank you.
By supplier I assume you mean reseller.
It depends whether the reseller is just box shifting or adding value in which case they would be a VAR (Value Added Reseller). If the later they may be providing their own support/ maintenance for the product and in which case (if part of the contract there may be an SLA). However, the SLA may exclude services which fall outside their control e.g flaws in the software being provided by the software manufacture.
If the former, then the reseller has no responsibility for fixing the software, that lies with the software manufacturer. e.g. You don't get you patches for a MS operating system from PC World, you get them from Microsoft/ PC manufacturer, even though PC World sold you the PC.
With OSS software, if you purchased it through a VAR and you had suitable SLAs in place, then there is no difference. As the code is open source the VAR may offer a patching service if they have their own programmers or suggest a work-around until a fix is found. What they offer is dependent on the terms of the SLA.
If you just downloaded the software from the software manufacturers website then there is no contract and no SLA and therefore no commitment for the software producer to maintain the software. OSS dies either through "forking" or people losing interest due to better OSS products being made available.
The bottom line is that like commercial software, if you want support for OSS then you are going to have to pay for it. If you can afford to live without the support and put up with the consequences e.g. Handbrake is currently broken for Ubuntu 9.10 http://handbrake.fr/downloads.php and there is no indication when a fix will be made available, then OSS has a financial edge.
Here is one example of many.
OSS is not necessarily about "do it your self"
It is about freeing up the market and allowing people to sell services.
For example, I have my car serviced, I could service it myself but I choose to get a third party to do it because they offer me a good service and I like the convenience. They also guarantee their work via a warranty.
No body has to hide how engines and cars work for this agreement to work. If my Toyota is no longer made there are no end of suppliers who continue the service.
When software that is proprietary goes end of life, not having access to the source code prevents anyone offering to continue the service.
Proprietary sw producers abuse their position as holders of source code. Here is a clear example. Citrix would not release new versions of their ica client for sparc based solaris because they fell out with Sun. Nevermind that sparc users had been using Citrix for years and needed that client. The only thing they could do was scrap their investment and buy new product.
The very question posed implies that OSS precludes a complete professional business relationship. It doesn't. Furthermore, it produces massively superior products in all sorts of key areas. <
Brian Lockwood
"look to the proprietary software manufacturer to offer patches and fixs or an alternative solution"
How long will that take then?
Two years ago we had a problem with a particular piece of OSS that was essential for our student's coursework - it broke and we did not have a clue why. However, we had a fix 60 minutes later after my sysadmin contacted the authors of the software on IRC.
That is just one advantage that OSS has, and this therefore is an advantage of OSS resellers that most proprietary resellers can only dream about.
it depends what is more important to you. Knowing who to blame, or knowing you can fix it (or get someone else to fix it - which unlike proprietary software does not necessarily have to be the person who broke it in the first place)
Take another practical example. Let's say you bought and used IE to access a web site and found IE was broken or lacking in some way. (eg lack of support for semi-transparent images in IE 6. SVG support? SVG is the ISO standard for vector graphics) What would the chance of a school successfully suing MS or indeed putting any pressure on them to fix these? Zero and I doubt they would even try. What would be a the chance of the same school getting a patch into say Firefox? Perhaps not certain but higher than the IE case. So the risk with the proprietary product (particularly if it is in a dominant market position) is greater. Simple risk analysis. Nothing is risk free, what matters is relative risk overall. It is very easy to argue that the risk of lock-in to a single source of supply is greater than the risk posed by perceived lower accountability. How many people are locked into MS Office? What is the combined value of that risk? How many people have tried to get redress against open source companies through SLAs and found they lost out? What is the value?
It is not sensible to do a risk analysis on FOSS without applying the same to proprietary including the bigger picture for both.
There are two separate issues I can identify here. The supplier, and the the software itself.
> there are SLAs and other guarantees that can be invoked to ensure that the supplier is not hit with penalty charges
Indeed, and that entirely depends on the terms you agree with your supplier (even if they dictate them). Note what you have said protects the supplier, and not you as a customer. For software alone, neither proprietary or free open source software offer a warranty. This is where support contracts come in.
> where there are issues with the software the supplier can look to the proprietary software manufacturer to offer patches and fixs or an alternative solution to bring their software up to scratch
Whether you are just buying software off the shelf or downloading free software from the Internet, licence agreements (shrink wrap, eula, gpl, whatever) typically make it clear that there is no guarantee of further improvements or patches (the warranty I mentioned). This is where a support contract comes in. For example while Microsoft says they will support Windows XP until (iirc) 2014, the EULA makes it quite clear that they offer no guarantee that any particular problem will be fixed.
With both FOSS and proprietary software you almost always have a support contract with a reseller rather than the actual software development company, the difference really starts when a developer is unresponsive, goes bust, stops supporting your version of the product or otherwise won't fix your problem:
Whilst your average proprietary software support supplier can quite happily reconfigure and work around issues with the software, they are totally reliant on the responsiveness of the upstream software developer to fix a software defect. As a school, I have yet to receive any fixes to problems I have encountered from a proprietary software house. We are simply too small to make enough waves for a large (or apparently, any) proprietary company to bother with looking after specifically. As the developers offer no guarantee, neither can your supplier.
Support from a FOSS software supplier on the other hand is quite different, as with access to the code your supplier can fix it themselves. Should they not be able to, they can either pay someone else to fix it, or if they are a total failure you can go to someone else entirely. There is no artificial lock-in to a particular supplier. The other side benefit is that you can also pay your supplier to build additional features if no-one else is doing it. Releasing those changes back to the community not only helps everyone else, but other people may well build upon your change and you benefit yet again.
Speaking personally, we have a support contract with a FOSS supplier following on from a large infrastructure replacement project. While deploying our new infrastructure, we came across some annoying software bugs. These were fixed with minimal fuss, very quickly (in the case of a simple bug, in under an hour), as the support engineer could access the code directly. Could you imagine that happening in a normal proprietary environment? Even something as simple as a typo on one line of code would be impossible for a supplier of proprietary software to diagnose, and given the responsiveness of the average proprietary developer...
One of the risks inherent in the use of proprietary systems (can we have some balance here please?) is that of lock in. Being dependent on a sole supplier of a system e.g. a school MIS system, exposes the customer to all manner of monopolistic practices and pricing. So it is not unusual for schools and local authorities to incur some hefty charges when the system provider brings out a new version, with open source that is far less likely. A Microsoft lock in can result in features that do not work unless the clients are using IE or MS Office. The supplier of proprietary systems has an interest in maintaining that state of affairs, which is why Microsoft undermines open standards.
It seems a bit odd that we should be trying to solve the suppliers' problem when one of the fundamental principles of sound procurement is that the solution should be the suppliers. If not, the supplier is handed a get out of gaol card which says that they supplied what we specified, which has happened in many big contracts. It is also surprising that this risk-transfer model has not received much more critical scrutiny given the role that pass-the-parcel with highly questionable assets (AAA rated by Standards & Poors and Moodys) played in the credit crunch. The recent experience of London tube maintenance where the contract had to be taken back should also alert us to the difficulty of transferring risk at an affordable price.
Even if we accepted that using proprietary systems facilitates a genuine transfer of quantifiable risk, we would have some genuine doubts about the price.