Open Source Disruption: Will You Trust Your Community?
Research and consulting organizations don’t get much attention from prospective customers by saying everything is fine — “status quo.” So a firm like Saugatuck Technology can be forgiven for a bit of headline hyperbole when talking about the impact open source will have on enterprise IT management over the next three to four years. But “Open Source as Disruptive Influence” (research notes PDF, free registration required) makes a strong case for the impact open source is having on both enterprise IT organizations and the software and services vendors that sell to them. Saugatuck says:
“Thirty-two per cent of user enterprise executives expect that by YE 2010, more than half of their key on-premise software will be open-source.
This massive growth in adoption is one reason why open source software is rapidly becoming one of the most disruptive influences seen on IT and business – for users and for vendors. Open source is changing the way user enterprises perceive, buy, and use software. And as a result, open source is changing the way IT vendors and service providers develop, license and support software …
Open source is first and foremost a development methodology, not a product, a technology, a single license scheme, or a business model. Open source’s key advantages for users and vendors derive from its community-driven development model. The greatest benefits will go to those who understand this and use it to their advantage.”
I’ve been thinking about “community-driven” development for awhile now. Far too many organizations simply don’t trust their customers or their employees enough to let them truly collaborate on creating new products, despite ample anecdotal evidence that this makes better products and more loyal customers. Ask any developer pursuing an agile development methodology what their user collaborators say about the process and the outcomes.
This thinking applies to more than software. “When Rebuilding Confidence Becomes the Priority” (subscription required) in Monday’s Wall Street Journal highlights the need to involve the community in the product to survive a near-disaster.
When development delays of the giant Airbus A380 superjumbo drove launch customers to revolt, A380 program executive Mario Heinen “threw open Airbus factories and invited customers into planning sessions. “We shared details I can’t imagine other companies presenting,” he says.” While his moves helped restore confidence in the project, how much better would it have been if Airbus had more closely involved those customers all along?
So here’s a question for the IT execs in the audience: does using open source mean involving more than a community of developers? Can the larger user community within an organizations be a trusted part of the open source process?
Please post your responses and comments below.
Entries (RSS)
November 17th, 2007 at 7:07 pm
I think, generally, that most can’t comprehend the Open Source process. Just because the software is Open (source code) does not have to imply that the process is equally Open. Just look at the premium Open Source foundations like Apache, GNU (and to a lesser extent Eclipse). There is a huge layer of government that controls the process and the community.
Having been a change agent for Open Sourcing internally (corporate controlled/firewalled Open Source) within an organization and externally with the production of true Open Source software, I think it is far-fetched to expect that the customer would play an active/proactive role in an Open Source project. It would be a dream if they did, but then really if they did why would they need the you (the consultant role)? Can you have a product, that is open, and funded/sponsored by a customer? Yes. But, this is a completely different line of thinking.
Taking a look at http://producingoss.com reveals many roles for all stakeholders. The customer fits some well, and others just don’t make sense. The bottom line is that there is a huge difference between consuming and producing Open Source. Refining the argument around the two definitions will change your closing questions dramatically.