On the world stage, both failures and successes can loom larger than in the corporate cubicle. Developers who plug into the reputation-driven meritocracy of open source -- while advancing the goals of your business -- are a force to be reckoned with. [InfoWorld: Open source citizenship: October 24, 2003]This column was based on the observation that corporate IT shops are apparently more likely to fork an open source project for internal development and use, than to join and contribute to the project. Some correspondents were puzzled by my comments on licensing, so I'll try to clarify. The open source licensing regime, as Tim O'Reilly has often pointed out, has as its basis the distribution of source code. As we move to a service-oriented software ecosystem, that basis will necessarily erode. If a GPL'd module is copied, modified, and then deployed behind a firewall to power a service that's world-accessible and free (as in 'free beer'), then am I as a user of that service free (as in 'free speech') to modify and share it? In one sense yes, I can wrap the service in a novel service of my own creation -- if the provider's terms of service (a different layer of licensing) allow me to. In another sense no, the internal modifications that make the service more interesting/powerful/useful than the GPL'd original are not available to me for modification and sharing.
I'm not suggesting that a different licensing regime could, or even should, prevent such a scenario. But I am saying that some habits that evolved decades ago will need to be rethought in a service-oriented ecosystem. Another example, which I mentioned in a column on open services a while back, touches on the way tests are bundled with open source projects. Here again there is a presumption of source distribution. But when a user of a service never acquires its source, and invokes the service from a different programming language than the one in which it was written, it may make more sense to deploy tests as auxiliary SOAP/WSDL constructs.
Back to this week's column, here's what I think is really the most salient issue:
Like the Internet itself, the modern enterprise now relies on the fruits of the most successful open source projects. But the commoditization of operating systems, compilers, and servers only scratches the surface of what's possible. All sorts of infrastructure software can benefit from the open source model. Business software, not all of which is necessarily proprietary, is ripe for commoditization too.If we're going to get substantial commoditization in the business layer, based on an open source development model, it won't be the result of licensing innovation. Rather, it will happen when captive developers are allowed to come out and play, to explore the boundary that separates proprietary intellectual property from sharable infrastructure, and to work together on commoditizing that sharable infrastructure.
Former URL: http://weblog.infoworld.com/udell/2003/10/28.html#a833