Open Source is the key to industry collaboration

Saturday morning, and I’m at my usual haunt reading through science papers, news, and other aggregates of information. Most of what I’ve subscribed to is related to science – much of it computer science related – but also technology and business. One of the articles I ran across this morning caught my eye: Nicholas Negroponte says Apple is not helping the tech industry.

Given that WWDC is next week, and I’ve long been a very happy consumer of Apple’s technology innovations, I was curious what stones the “One Laptop Per Child” creator was throwing at Apple. (Raspberry Pi by the way, kicked OLPC’s ass in low-cost – although not low power – computing innovation). I don’t know if this is just the way Jenni Ryall wrote the line, or if it really comes direct from Negroponte, but the line that immediately caught my eye was:

He claimed that in 20 years, the company has not written one research paper or attended any external research meetings, such as working groups, government-funded workshops, or held their own onsite research meetings with external scientists in the way Google, Microsoft and Facebook often do.

It’s a patently false assertion, given the company’s noted inclusion even while Steve Jobs was still running the company in the web standards efforts, including what I consider one of the most effective collaboration means: open source with webkit. Apple is going even further these days, an example of which is the swift programming language ( While the company still has secrets and is noting for maintaining that secrecy, it is also more open than it’s ever been.

There are other companies that are more open: Google immediately comes to mind, and Microsoft with Satya as CEO is making some damned impressive inroads in that direction as well. But the most notable part of what I’m seeing as effective serious collaboration isn’t meetings with scientists and attending industry forums, but creating and actively participating in open source.

When I think of industry collaboration or research meetings, I usually think of standards committees and industry collaboration forums. It may be a limit of my own imagination and experience, but my viewpoint is these groups make a small problem into a tangled rat’s nest of overcomplexity. The results of those collaborations tend to be a morass of group-thought half-solved problems or “business opportunities” cited by architecture astronauts for implementig the “defined” APIs or logical constructs. The good ones go all the way to operable demos. Almost none actually get to the level of vetting interoperability.

If you want to drive an open standard or collaboration, share the ideas, API definitions, AND an implementation. It is an intentional choice to commoditize, to agree on how to collaborate or interact. To really get there, you need to do it, not just talk about it. Get it out there with concrete code. The interoperating implementations highlight what *actually* works, and what doesn’t – and people finding it useful to solve problems is the true measure of value.