Open source givers and takers

Taking without giving isn't the problem. We need better open source contribution metrics.

Dana Blankenhorn’s recent ZDNet blog points to Accenture’s “hockey stick for open source” and notes that while 69 percent of the companies Accenture surveyed plan to increase their open source investment in the next year, only 29 percent plan to contribute back to the open source community. That sounds very plausible. But is it a problem? I’m not so sure.

First, I don’t think “all take and no give” is a failure. Or even a problem. If you’re giving, you shouldn’t be surprised if people take. If you’re taking something that’s been freely given, you shouldn’t feel obliged to give back. If you do, that’s great. And if you’re a giver, you should be glad that people are taking, whether or not you’re getting something back in return.

Second, “how many companies plan to contribute” isn’t the right metric. One of the things I’ve learned from my involvement in industry is that the most successful and effective groups are small. The right metric is “are there enough contributors to move the project forward?” For the key projects (like Apache), clearly the answer is “yes.” “Enough” is much more important than “how many.” The last thing we need are projects that slow to a crawl because of the bloated development-by-committee that characterizes many corporate environments. In the late ’80s, I worked for a startup that developed (among other things) a FORTRAN compiler. We sent our 10-person compiler group up to DEC for a meeting, where they found out that DEC’s FORTRAN compiler group had 2,000 people. DEC couldn’t understand how we got anything done. More to the point, our guys couldn’t understand how DEC got anything done.

Further, I suspect that the extent of corporate contribution is significantly higher than this study reports. Twenty-nine percent is probably correct if you define “corporate contributions” as “contributions made by employees while sitting at a company desk and on company time.” A better measure would be “contributions made by someone who develops or uses the software as part of his job.” The software is used on the job, but the contribution is often made by the individual, at home. But that’s hard to measure; it’s not what the projects are set up to track. And yes, it would most likely be better if these guys were compensated for their work. In many ways, they’re the heroes of the open source movement. But that brings us back to my first point: what was freely given may be freely taken.

The level of corporate contribution would almost certainly be higher if you limit the question to corporations that have something to contribute. I don’t mean that facetiously. Apache is probably the most widely used open source project in the corporate world. How many corporations have actually modified the Apache source code to add a feature or fix a bug? Very few, I’d bet. They use it “off the shelf.” And if you haven’t touched the code, contribution is a moot point. And that’s just fine.

There’s one more issue worth considering. If you look at any open source project hosting site, such as SourceForge, you’ll notice a few projects that are successful, and a much larger number that have clearly failed: “abandonware.” Maybe they once served a purpose (like getting a dissertation finished), but they’re buggy, incomplete, and stagnant. Could these projects have been contenders, and if so, what went wrong? It seems to me that projects fail for three primary reasons: bad project culture, poor source code base, and “not really needed.” The project scratched someone’s particular itch, but not enough people had that same itch.

Would corporate backing have allowed some of these failed projects to survive? Maybe. Corporate projects frequently have culture problems, bad source code, and poorly-defined markets. So it’s not clear that corporate participation would be a huge win. I’d really like to see a good study of failed open source projects: what, why, and how. I think we’d learn a lot. And one question worth asking would be whether more corporate involvement would have helped the project to survive (and whether survival would have been a good thing).

To put this in a specific context: much has been written about RedHat’s significant contribution to Gnome, and Canonical’s much smaller contribution. But that’s not the right issue. Would Gnome be better (or some definition of “better”) if it had 20 percent or 50 percent or 150 percent more contributors? That’s not clear to me. Blankenhorn’s comment is right on:

Everyone is free to take just as everyone is free to give, and that is what makes the idea powerful. GNOME is far more valuable to Red Hat than a Red Hat UI could ever be, because it’s open source, because it’s a commons.

That’s precisely the point.

I certainly don’t want to discourage any corporation from contributing to the open source community. There are many projects that do need help, many projects that could profitably be started, and many sites willing to host them. And I agree with Blankenhorn’s larger point: that by engaging with open source projects, companies engage with their customers, their competitors, and people who can help.

Although giving back to the community is an option, it’s a good option, and something from which corporations can profit. But before we gauge corporate participation in open source, I think we need better metrics than the ones Accenture is using: how many projects need more committers, and where are the committers coming from? How many companies have employees who work on open source projects on their own time? And how many employees work on open source on company time, unbeknownst to the managers who fill out Accenture surveys?

tags: , , ,
  • SteveL

    I think the survey is missing a few points

    1. Everyone who uses your OSS project is not using someone else’s software, possibly denying it both money and momentum. The more users you have -even not contributing- the better.

    2. Anyone who files a bug is a contributor.

    3. If you don’t contribute code and you want your problems fixed on your timescale, you will have to pay a contributor for it. That’s why RHEL have done so much: they get the support contracts.

  • tib

    Look at Java, a successful, largely open source language that is in the news today for being somewhat less than open source. How much of Java’s success is due to corporate sponsorship? How has that affected the language and it’s ecosystem?

    • Those are excellent questions. Corporate contributions to the Java ecosystem have almost certainly been larger than to the (say) Python ecosystem. But both are healthy. I do not think Java could have established itself without corporate backing. On the other hand, corporate egos, infighting, and the like have also been a problem in the Java ecosystem (and obviously are continuing to be a problem). A number of key Java APIs have suffered from corporate requirements (“our customers need feature X,” rather than “does feature X make sense?”). I don’t think Python has had similar problems–certainly not to the same extent.

      So corporate backing has both helped, and hurt, Java.

  • Kent Johnson

    You also have to consider what and who was asked.

    The Accenture page says, “less than a third (29 percent) are willing to contribute their own solutions back to the community.” Does this mean that they are opening up their own projects or contributing back to the projects they are using? It’s not clear.

    Assuming it means contributing back to the projects they use, who was answering the question? The chief technologist? Does he know about every bug report or doc patch contributed by someone working for him? Small contributions are important and could easily be under the radar for a survey like this.

  • Ken Williams

    Extremely well said, Mike. For me, this same thinking is why I tend to choose more “permissive” licenses like BSD, MIT, etc. rather than GNU-style licenses. When I’m giving something away, I really want to just give it away.

  • Stan Thow

    This is very interesting, but you have to remember human evolution. This problem at different levels is as old as history and I don’t think that it will get resolved in our lifetime or even ever. But It is important that we discuss it and know that it is a problem.

  • Stan Thow

    You have to remember human evolution. This problem is as old as history. I don’t think that it will get resolved in our lifetime or even ever. But It is important that we discuss it, and know that it is a problem.

  • ec

    When people get jobs with a particular technology it encourages everyone to be interested in that technology. Why do people contribute to Python? Becuase they know about Python, if Python was some obscure language noone would be interested in contributing to it.

  • Robbie Williamson