Reinventing the open source wheel

Why are projects coding it themselves rather than sharing code?


One of the greatest strengths of open source software development has been the notion that as an OSS developer, you can pretty much just pick and choose from the thousands of OSS projects out there to enrich your own project.

(There are caveats to this idea, of course, the most obvious being license incompatibility. But, the general principle still holds.)

But anecdotal evidence in the open source community seems to be demonstrating that the very opposite is occurring: new projects are often reinventing the wheel in their code, rather than partnering with someone else's project.

I was chatting online with an acquaintance recently, a gentleman who works for a successful vendor in the Linux ecosystem. He was lamenting the fact that within the halls of his company, he was continually running up against the "not invented here" problem. This problem was simple enough to describe: when engineers in his company put their own projects together, they were much happier reinventing technology that had already been done rather than tap into projects that were already done, were brilliantly made, and had no problems with any sort of license compatibility.

This was frustrating to my colleague, because he saw a lot of waste in such a practice, which by all rights should not be prevalent in an open source ecosystem. And yet, there it was, being demonstrated time and again by his co-workers.

It would be tempting to point fingers on large commercial vendors and accuse them of making their own open source code just because they have to own all the cookies in the cookie jar. But the blame is not entirely on the larger vendors… smaller software projects are increasingly getting lost in the noise of the expanding open source community, and sometimes don't do the best job of advertising their wares.

In such cases, the software is awesome and ready to use, but the project team may not have gotten the word out to the point where someone else can come along and partner with them.

Another potential barrier to inter-project cooperation might be a new-ish phenomenon illustrated by Andrew Aitken recently: super communities.

Aitken, a Senior VP with the Olliance Group, sees a trend towards what he calls super communities or "communities of communities":

"…[E]ssentially, these super communities are vertical industry-driven open source communities. The core driver for these groups is the recognition by certain industries that a substantial portion of the software they develop is non-differentiated software that absorbs a significant amount of resources that could otherwise be used to innovate, differentiate and compete."

This is certainly one way to avoid the problem of reinventing the wheel, at least within one of these super communities. Examples Aitken listed include:

  • "Polarsys, an aerospace community launched by Airbus and hosted by the Eclipse Foundation
  • "New York Stock Exchange-led OpenMama project, hosted by the Linux Foundation
  • "The GENIVI Alliance, a consortium of automotive OEMs and suppliers building an open source in-vehicle-infotainment platform
  • "OSEHRA, an open source community focused around electronic health care records management seeded by U.S. Department of Veterans Affairs."

Aitken sees this as being a positive development, over all, though he does see a potential for trouble:

"A potential negative impact might be fragmentation of the open source community if companies in the supply chain restrict their developers to contributing to narrow, vertically-oriented open source solutions. Fragmentation or 'balkanization' is a key concern today. Could open source become a victim of its own success?"

Aitken goes on to make the case that he doubts it--the very complexity and diversity of the open source ecosystem would seem to belie the notion of such fragmentation. But in his arguments, he points out the very same problem my colleague described to me. In the past, he argues, most open source software could be found within one or two repositories, such as SourceForge. Now, code is scattered across thousands of repositories.

To me, this situation would definitely exacerbate the reinvented wheel problem: with so much code scattered across so many sources, no wonder projects are having trouble finding each other. Where would they start to look?

There will always be reasons open source projects might not want to work together: commercial competition, political differences, or underlying technology barriers.

It would be disappointing if ignorance was another reason why cooperation between projects didn't happen.


Join us:






Answers - Powered by ITworld

Ask a Question