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: , , ,