Convincing Your Superiors to GPL the Code?
jakobgrimstveit asks: "At work I've been developing an intranet/extranet portal framework in PHP based on many other peoples work, including quite a few PEAR modules. I've always wanted to release the coding framework as GPL and publish it on SourceForge, and my boss has - impressively enough - not been too negative about this. This has been going around in the organization for quite a while now, and finally the reply from the company's president was (not surprisingly): 'Why should we do so?' I now have the task of writing a document listing the main reasons for GPLing the code, and this is where I turn to the highly competent Slashdot crowd: How do I convince my bosses to GPL the code I've written? I assume many other developers have the same problems trying to convince their bosses to open up their code."
the highly competent Slashdot crowd
Oh, sure, them. We'll just wait for them to get here...
Slashdot - where whining about luck is the new way to make the world you want.
In Fortune-100-America, everything possible must be stamped with a (c) or (tm) or patent#. Advancement up the technical ladder is difficult without getting a few patents for the company.
I think people here would have a heart attack if they knew I ever even thought about GPL'ing code, as that's almost tantamount to selling trade secrets.
If you've wanted to GPL it since the beginning you must surely have some good reason for wanting that, right? Just tell them that reason, focusing on the business benefits. If there are no business benefits and you want to open-source it for idealogical reasons then you might need some help. Find business reasons (by looking at other business-led open-source projects, preferably similar to yours) or give up.
Why is anything anything?
you might think it's a good deed for society, donated quality code to the public, but what would a business care about good deeds. they are doing business, which into itself stifles good competition, creating a better market, which does benefit society.
the only way you can convince him is to state the advatages it gives your company, and not what it gives society.
1. other people can fix your bugs and security holes for you
2. other people can add features for you
3. no need to pay for beta testers
tell him you can still maintain your rights of it in that you still have the final say in what gets merged into the source code, and that code vandalism wont happen (people putting in their own backdoors)(as if anyone can immediately donate code and have it show up).
do tell him that one negative of it is your competitors could also use your code, you wouldnt want to get fired for not telling him that someday.
Amazing magic tricks
The real question here is why did you wan't to GPL the code if you didn't already see tangible benefits to doing so. Don't get me wrong I love Open Source. I use it all the time in my job and at home. But if you don't already have tangible benefits in mind toward opens-ourcing the code then why did you want to open-source it in the first place.
Or were you asking for benefits your companies exec's would understand? That may be a trifle more difficult to expound upon since we don't even know what your company does.
If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS
If you can't find a coherent argument for why it's in your companys interest to release the source code under the GPL, then there is probably little reason to do it...
Then again, unless your company is in the business of selling "intranet/extranet portal framework"s then it shouldn't hurt much.
Apart from GNU ideology, the decision boils down to:
If you can find reasonable answers to those questions, a reasonable boss will make a reasonable decision :-)
1) Savings on coder time, extra bugs fixed - in each case by external devs your company doesn't have to pay. Downside: unless your project becomes well-known, this may never actually happen, or not enough to pay for itself.
2) Code stability. You can sell services or derived products to third parties and tell them that the product is safe against your company going bust because the code is public. Downside: you then have to do the harder work of convincing the buyer not to "cut out the middleman" and implement a homebrew with the published GPL code. GPL code cannot be your only source of value!
3) Compatibility with 3rd party extensions. If you GPL, you get a license to merge in anything else GPL'd and thereby add maximum features for minimum effort. Downside: if you muddy up who has the copyright, you may not be able to un-GPL it (nor sell special-case licenses to users who'd prefer closed source)
4) Why not? If it's not a "strategic" asset but only an in-house tool for a secondary task, GPLing can't hurt. Downside: publishing code and dealing with bug-reports and user gripes can eat expensive dev time. If the business case is that marginal you may be forced to "publish and abandon".
You do realise that it will often NOT make sense to open-source the code? In particular, a "strategic" app, or one that implies sensitive info through its design, or one that presents a public face you don't want to be hackable. Or simply if your boss thinks "I can't spare dev time for this nonsense". Businesses aren't charities (unless you're tax deductible).
1. Code is released under GPL, nobody cares, code is never updated and might as well never have been released.
2. Code is released under GPL, code is pillaged and partially moved to other systems leaving the original code obsolete and inferior.
3. Code is released under GPL and takes off as a succesful project.
Option 3 is least uncommon by far.
Unless you have good reason to think your system will be sufficiently popular to actually gather a community (remember; there is no OSS community; only individual OSS developers), you'll have a hard time making a business case.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
That's what I did.
One of my team wrote a little interface wrapper between Ant (build system) and AlienBrain (source code management software), because he couldn't find one anywhere else.
I argued that, without the FOSS nature of Ant, we had saved money and it was therefore our duty to contribute.
The main stumbling block was that I had to show that this wouldn't materially advantage our competitors.
The final version is at http://sourceforge.net/projects/antab/ in case anyone wants to look at it.
Sean Ellis
Follow OfQuack's antics on Twitter.