It was a long weekend here in the Toronto and I met up with two friends from university. They told me of a "guaranteed" system for winning at Blackjack that they had discovered. I won't get into the details of the "strategy". When I used a coin and then a spreadsheet to "prove" that their system didn't work, they kept joking that my proofs didn't seem "truthy enough".
I feel the same way about the notion that: "access to the source code prevents vendor lock-in and is immeasurably important in keeping the OSS vendor focused on the customer".
I don't propose that the above statement is a blatant lie. I only question whether it is an absolute fact. We in the OSS community really provide a superficial discussion on such questions. We accept the answers as obvious truths. I did this also. But my experiences over the past 2 years have compelled me to reconsider. I don't know if my conclusions are correct. But questioning these "truths" seems to paint me as "someone who is oblivious to the world passing by". I should state again for the record that I am a proponent of OSS & Traditional software existing together. I do not believe that OSS will completely take over the software world. Nor do I believe that OSS is a market force to fight. Actually, I wonder if I should paint myself as Dilbert in the comic that Zack wrote about here :-)
I agree that access to source code aids in creating community. I understand that source code access helps customers who may never touch the code because (a developer at) customer ABX has the ability to contribute, thereby benefiting the whole user community. But does this really prevent vendor lock-in or ensure that the vendor is focused on customer needs?
(Note: the following does not apply to projects/products that are implementations of open standards).
If the answer is yes, then I'd propose that the answer is only "truthy enough" when the OSS project is a multi-vendor backed project. Linux, Apache Web Server, Eclipse or Apache Tomcat are great examples of such a projects/communities. I do not feel that yes is a "truthy enough" answer if we are discussing an OSS project backed by a single vendor (which most seem to be these days). I mentioned this to Matt in the comments here. I don't want this statement to be about any particular OSS vendor, so I'll generalize.
I propose that, in most cases, a 3rd party cannot provide the maintenance and future development leadership for OSS software to the same level as the founding vendor of the (single vendor backed) OSS project.
If the project was an implementation of an open standard, then my previous statement would be false. Open standards help reduce vendor lock-in. Open source may help reduce vendor lock-in, but not nearly to the degree that we’ve led customers to believe.
Meeting customer needs must be a core competency of any software vendor, OSS or not. The notion that OSS vendors are more focused on customers than Traditional vendors is a view that irks me. If this were true, a majority of new software purchases would be OSS based. I’ve listened to the argument that because the source is out there, OSS vendors must deliver first-rate support and additional offerings or risk losing customers. Sounds great on paper, but in reality, do customers head for the door if they don’t receive the customer experience that they expected? Where would they go? In a single vendor backed OSS project, there is no real alternative choice. There is only an allusion of choice (in single vendor backed projects). One option is that the customer can decide not to renew support from a vendor and handle the support in house. However, if the customer has paid for support, they’ve signaled their intent of being "willing to spend money to save time". Self support does not align with this intent. There may even be a degree of buying support as insurance/CYA, and little that the OSS vendor does would change this purchase decision.
Please disagree and explain why you feel I am incorrect in my conclusions. I'm happy to reconsider my views.
PS: I should state: "The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions."