September 04, 2009, 7:57 PM — If your company has built useful applications based on an open source framework or using open source tools -- or maybe even if it's merely developed some cool stuff that others might find useful -- at some point the development staff, at least, will contemplate the merits of releasing the software as open source. When's the right time... if ever?
[ See also: Convincing the Boss to Accept FOSS ]
That question has been on the mind of a close friend whose company has been extending the functionality of one open source framework to their niche needs. As active members of the open source community, they've certainly contributed bug fixes and features to the core application. But I'm speaking of the in-house apps they've built on top of it for their own purposes. Some features they've added would be of use only for their organization, but others... hey, maybe someone could use it? They've spent the last few days trying to decide when and if to package up the code and make it available to all; I don't think they've reached a decision yet.
I'm sure some developers would say, "Whatever it is, release it!" in the firm belief that all software ought to be free. But that's not quite realistic, particularly because someone outside the development organization is sure to get involved. While it might take a lot of effort to release corporate-developed software as open source, it does take some effort.
The obvious painful issue is legal. Company lawyers have to okay your bright idea to release the code, and in non-IT-centric organizations plenty of lawyers would require a serious amount of consciousness-raising. You probably already spend too much time in meetings; do you really want to spend a few more hours explaining the different open source licenses to the company's attorney? I'd rather pierce my ear with a railroad spike. Do you want to explain to the lawyer that she probably wants to run some kind of tool to ensure that the company has the legal right to release it—that's the code is already open source, or that it all was developed in-house? (If some part of your code came from an outside contractor, does the company have the right to release it? Answering such questions keep lawyers well-paid.) This does not sound like a fun afternoon to me.
Even if that weren't a significant barrier, the developers would have to do some work on the code itself to get it ready for public consumption. A while ago, I asked developers what they'd change in their code before releasing it as open source, and half the people who answered the associated poll (admittedly a small sample) said they would do more than minor work: either some code housecleaning so that nobody would snicker at their work or major changes (because of the awareness that others would look at their code). Even if the time to clean up the code to release it as open source is minor, it is non-zero. If it'll help other people, then sure, it's worth the effort. But will anybody care? Is it worth the effort?
Coming up with an answer of "Yes" requires a certain degree of... arrogance? confidence? helpfulness? Some of each, I think. Developers who release their (or in this case their company's) code under the GPL or whatnot have to assume that the code has value to programmers outside their organization. And that's not always easy to judge. Some categories of functionality are no-brainers. It is worth the effort without question if your company developed a better e-commerce module, or features that integrate a well-known open source application with a social network, or a mashup generator, or— well, let's just say that some things are pretty obviously useful.
And some things are just as obviously not useful, such as utilities that reinvented the wheel in colors that matched the corporate logo, or other "functionality" that might be helpful inside your company but make others roll their eyes. (I keep trying to come up with examples of wastes-of-time; perhaps you can suggest a few.) Yet sometimes this code, too, is released as open source. I have to guess that it's done mostly out of kindness and dedication, the spirit that says, "I am committed to open source, and that means I need to contribute back to the community." Which of course is all well and good... assuming anybody cares. And assuming that it's released with a good description of what the software does; I'm sure that you've run across listings saying essentially, "Here's some stuff we did; if you find any of it useful, that's great." Life is too short to paw through open source flea markets even if, hidden in your code, is a snazzy routine that could save the day. I've come to assume, however, that anyone who can't describe what the software does likely can't write a good app, either; if you don't care enough to tell me (the user or developer) what's inside the box, I don't have high expectations about what's in the box.
All of which brings us back to the not-quite-obvious question: When is it time to release the code for a company's enhancements to an open source project? (Or just as equally: at what point does it make sense to taken something completely home-grown and release it?) When is it "done" enough to make it worth sharing? How do you decide if others will find it useful... and whether that balances reasonably against the time and effort to prepare it and package it?
I don't know the answer. But I'm sure some of you, O Loyal Readers, have opinions and experiences to share. I'd like to hear them.
