Archive for February 25th, 2009

Transparency and dependability for external partners

As a consultant, it happens frequently to answer questions about “what makes open source better”. Not only for some adopter, but for companies and integrators that form a large network ecosystem, that (up to now) had only proprietary software vendors as source of software and technology. Many IT projects had to “integrate” and create workarounds for bugs in proprietary components, because no feedback on status was available. Mary Jo Foley writes on the lack of feedback to beta testers from Microsoft:

“During a peak week in January we (the Windows dev team) were receiving one Send Feedback report every 15 seconds for an entire week, and to date we’ve received well over 500,000 of these reports.”

Microsoft has “fixes in the pipeline for nearly 2,000 bugs in Windows code (not in third party drivers or applications) that caused crashes or hangs.”

That’s great. Microsoft is getting a lot of feedback about Windows 7. What kind of feedback are testers getting from the team in return? Very little. I get lots of e-mail from testers asking me whether Microsoft has fixed specific bugs that have been reported on various comment boards and Web sites. I have no idea, and neither do they. (emphasis mine)

Open source, if well managed, is radically different; I had a conversation with a customer just a few minutes ago, asking for specifics on a bug encountered in Zimbra, answered simply by forwarding the link to the Zimbra dashboard:


Not to be outdone, Alfresco has a similar openness:

Or one of my favourite examples, OpenBravo. Transparency pays becuase it provides a direct handle on development, and provides a feedback channel for the (eventual) network of partners or consultancies that “are living” off an open source product. This kind of transparency is becoming more and more important in our IT landscape, because time constraints and visibility of development are becoming even more important than pure monetary considerations- and allows for adopters to eventually plan for alternative solutions depending on the individual risks and effort estimates.

1 Comment