Giving back to open source

My Oct. 24 column, "Open Source Citizenship," attracted more than the usual amount of e-mail and Weblog commentary. Lots of people are thinking about whether, and how, to coordinate in-house development with open source projects. Licensing, employment agreements, open source culture, and government policy are some of the issues raised in the follow-on discussion.

With regard to licensing, several readers pointed out that a modified version of the GPL (GNU General Public License), the AGPL (Affero GPL), aims to close the GPL's "Web services loophole." The AGPL adds a section to enforce sharing code that powers a Web service, so if you host a Web service based on a modified AGPL-licensed module, you have to guarantee your users the same access to source code that the original module guaranteed its users. In-house developers would often like to give back to open source projects, whether or not compelled by a license to do so.

But there are a number of roadblocks. One reader notes that his terms of employment state that anything he invents or creates while working for his company belongs to the company. He wonders how broadly this constraint applies, as do I.

Another reader points to the differing priorities that govern open source and in-house projects. An open source project typically has no urgent deadlines and may invest heavily in supporting many platforms and configurations. An in-house project often reverses those priorities. Deadline pressure is intense and the deployment target is narrowly specific. Even when in-house developers are inclined to give back, the code (for valid reasons) is not always welcome. "The open-source project owner would frown upon changes suggested by people who have not yet earned their stripes," the reader says. "But the in-house developer has neither time nor availability to earn those stripes. The net result: multiple in-house forks and associated waste of resources."

Jonathan Bollers, vice president and chief engineer at Science Applications International Corp. (SAIC), says that SAIC forks open source projects for in-house development "almost without exception." The problem is that although there is often a desire to give back, it's "a tedious process fraught with more heartache than benefits." The bureaucratic hurdles include security considerations, export controls, and a host of other issues that Bollers sums up as "releasability remediation."

He asks a crucial question and proposes an intriguing answer:

"So how can the defense community give back, apart from well-shrouded blogging, discussion and Usenet postings, and seeding academic research? How can we be viewed as good open source citizens by releasing remediated code?

"In many cases, defense-related development could be a boon to those entrepreneurs engaged in IT commercialization. Modular and well-structured code, properly tagged for defense-sensitive algorithms, functions, identifiers, and key words could be effectively re-released as open source.

"The government might consider incentives for those in the IT contracting business, perhaps in the form of additional fees, credits, or preferential rating for future procurements, to remediate via software engineering for reuse processes that specifically target release to open source.

"These two-way-street incentives would not only revitalize thoughts and ideas in the open source community, they may also be the harbinger for the next wave of technical innovation in the post 'new-economy' economy."

Excellent idea! I'd love to see some of my tax dollars directed toward that end.