Can good governance clash with business interests?

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

chs's picture
Today I would like to mention an issue that is somewhat of a taboo inside the Free and Open Source world. There is a categoy of software that is developed, released and distributed in full compliance with the license (GPL, Apache, BSD, etc.) but that ends up locking in its users because of poor or absence of documentation and complete lack of access to software information. This adherence to software is thus not the apanage of proprietary software. Yet, sometimes some software that are released under a FOSS license are just as bad as proprietary software.  This issue can be addressed in two ways.  First, FOSS projects widely depend in popularity, size and audience. I think that Firefox or OpenOffice.org will always be more popular than a software tool helping out with statistical analysis on biological data. Between those examples you will of course find many shades of grey. However, you can expect that the popularity of a software will translate in to a larger community and ecosystem, resulting in a wider choice in terms of support and a better documentation. Conversely, the statistical analysis tool may have documentation, but in reality, documentation is often the most overlooked part of FOSS projects.  Second, there is software out there that is released under a FOSS license but that effectively locks in users through absolute lack of documentation, choice of support contractors and in general lack of access to software information. This exists sometimes when one IT services company is the sole contributor to one specific software. This company's business model is to sell services on top of that particular software. The issue here is twofold: when there's noone else offering equivalent services on this technology, the software is in effect as bad as proprietary, unless you have valuable IT resources in your organization. Your IT department could then in  theory maintain the software and gain knowledge on it. But is this an effective way to use your internal resources? Better appropriate the software to yourself, fork it, and get rid of your supplier (especially if this software is critical to your core business). The other side of the issue is the one of supplier: the supplier has a vested interest in not disclosing any information about the software and provides limited or no documentation.  In this case, you may want to look elsewhere or strike a deal with the supplier that will ensure he will not be the only one who "owns" the software anymore at the end of the contract.  Of course, you will find cases where the supplier may not have had the time nor the resources to write documentation. But a contract service should always include the delivery of documentation to your organization, and it should better be the right kind of documents (not the end user pamphlets).  What can be objected to this is that the supplier needs to have some level of lock-in in regard of its customers in order to survive in a highly competitive services market. This argument does not fly for the customers. The main reason why a customer wants support is not that it doesn't want its teams to read documentation; it's that its resources are either non-existent or busy elsewhere, and nobody wants to train its IT department in a pool of kernel hackers when all your organization does is manufacture, sell and market toothpaste. The only viable argument in favour of this business model of "services captive" is  to put entry barriers to the competition.  I don't think this argument works either; at least, it does have a very limited impact on the IT services industry. If you're really the only one owning the software, hidden costs will put a heavy burden on your organisation; training will become inceasingly expensive for once, and not selling widely available solutions on a commoditized market only works for niche, not for mainstream. Besides, if your company can develop software, many others will be able to develop similar, competing software, and you will find yourself in a walled garden, hurting both your customers and yourself.   This blog post is of course not a critique of the IT services industry. It is rather a call to the market to gain a better understanding on the technologies that are integrated everyday in organisations and how FOSS works. This blog post is not a call to use only widely popular software: software diversity matters a great deal. But again, it's about awareness and understanding.
Thoughts? Comments? Your input is welcome.
andrew's picture

Due diligence / measurement

You raise some good points here, and I think the message to take home has to be that once more we should not make assumptions and that due diligence is required. A F/OSS label on a project should not be seen as the mark of utopian software!

Whether it is the proprietary software industry or open source community, there will always be actors with more egotistic motives, that will do whatever they can to effect lock-in. Just as with both camps you will see those who strive put the customer's needs first, and also those who may not have set out to lock a customer into a given technology, but through bad development practices and/or poor documentation end up doing so.

The question for me is: how do we accordingly assess F/OSS? I'm not sure that strict formal assessment frameworks are the answer, and believe that empirical evidence and reputation are key factors. However, we would of course get the most benefit from methods that can be easily described and give consistent results.

Open v Secure

It strikes me that open source should be that. I repository holding the source should be a first requisite with free access to download.

The degree of documentation is slightly trickier. A system that processes credit cards, for example, may wish to limit knowledge on how to modify the system for security reasons. 

IMO There needs to be a clear distinction between commercial lock-in and security.

 

andrew's picture

Proprietary != secure

Open and secure are not mutually exclusive and in fact many would say that the former leads to the latter, whilst "security by obscurity" as an approach has many times, and quite publicly, lead to failure.

Linus's Law according to Eric S. Raymond states that "given enough eyeballs, all bugs are shallow", and you quite often see a fast turnaround on security holes in FOSS, whereas with some proprietary software known exploits can exist for many years. And leading security expert Bruce Scneier frequently writes about failed approaches to security, which might have enjoyed greater success had they not been the product of closed development.