While driving home this evening, I was still thinking of some mail I sent earlier during the day, to someone who is looking into establishing an Open Source Center to be used as a political lobby organ and a means to dissipate information about Open Source and business to Flemish companies. My mail was very close to a rant, stating that we do regard ourselves as being quite unique in our little corner of the world, since we do not only use open source software in an effort to create more cost-effective solutions for our customers, but we also build, preferably with the customer, open source software.
Of course, we are lucky to have clueful customers, who know IT application frameworks most often are not at the very core of the data that runs their business, or will only enable, but not capture the domain knowledge and business processes which differentiate them from their competitors. Building a database reporting framework is child's play compared with amassing all customer's data to fill that large datawarehouse so that you can actually run those reports. It's the data and business flow/logic that counts, not the infrastructural technology.
This kind of reasoning is luckily quite orthogonal to our line of thinking. Either the customer cares about open source or not, but in the end he just wants a framework that enables his business processes. We, and many other concullegas just as well, are able to provide him with such a framework, either by building from scratch, by downloading an open source framework, or by building and releasing. In the end, it might only be the reduction we give to customers which allow us to release the results of our collaboration, that eventually convinces them to "go open source". Technically, releasing the source won't help them much in reaching their goals sooner or at a lower cost.
So, what is the value behind building open source, then? As usual, in the end, it all boils down to the people, and the environment they operate in. If you are used to work inside an open source project, you are used at working with a non-strict environmental context. Interfaces can and will change, there will be discussions about design, and you better make sure your code is designed for maintainability and extensibility, or someone else will go in and refactor the hell out of it. Also, you have to stand up and defend your ideas, and you're aware of the fact that people are looking into each and every code change you are committing to the source repository.
Quite a few of our customers, who were lured by us into using CVS as the shared workspace, were surprised to see us going mad when their initial interactions with CVS were resemblant to the use of "a shared network drive with some versioning". We immediately tried to explain them that one is supposed to commit atomic (enough) changes, that log messages should be sensible, and that one must not forget about local environmental context changes in somebody else's sandbox. Not everybody has its CVS modules checked-out in e:\projects\blablabla. Not everybody uses Eclipse with indent set to (godforbid) 3, with tabs instead of spaces.
As you see, we have an attitude towards development practices. We learned these practices out in the open, by running into walls while others were watching over our shoulder. If we hadn't been involved into some open source projects, we might never have learned and experienced how different one must explain, code, document and interact, when working in a volatile, collaborative context.
So, what does our customers buy with this we-build-open-source thing? Flexibility and strong interfacing in design, resilience in the build setup, and the ability to cope with changing requirements and project plans. Oh, and that attitude as well, of course. ;-)
Very interesting read. Thanks, Steven !