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."

Comments

hahahaha

[heinousjay]

the highly competent Slashdot crowd

Oh, sure, them. We'll just wait for them to get here...

Meh

[interiot]

You must work in a different corporate america than I do. My biggest hope is that my company doesn't enforce their "all your copyright are belong to us" policy, wherein every little unix script I write, no matter how small, and even if nobody at the company will ever make money off of it or even use it, can't be taken with me to my next job.

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.

Re:Meh

[MrResistor]

Well, yeah, that's because Corporate America is run by MBAs who could care less about actually running a successful, efficient company, and really only implement policies aimed at getting them the cost-reduction bonuses specified in their contract, and then move on before anyone has a chance to realize how badly their cuts have screwed the company.

The upside is that they generally have no idea what their employees are actually doing, so it's pretty unlikely that one of those clauses will actually get enforced.

Still, shame on you for signing that contract. You should have negotiated.

Who, us?

[elemental23]

highly competent Slashdot crowd

It's funny, laugh!

Tell them your reasons

[Finuvir]

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.

Re:Tell them your reasons

[jakobgrimstveit]

Sure. I have many reasons for publishing the sourcecode, but couldn't write them all up in the post. Here's a few reasons:

* Other people can gain knowledge from my code
* I can gain knowledge by other people commenting/submitting patches to my code
* Security vulnerabilities will be found under peer review
* I will get Good Karma [tm].

But me wanting to publish the code is not reason good enough for a boss, of course. He needs to see what he (as in "the company") can gain from this, so I'd like to get as much input as possible on how to articulate myself.

Re:Tell them your reasons

[Marxist Hacker 42]

It's that second one that will convince your boss- but it needs rewording. Plugging into the Dogbert Buzzword Generator for a second, try:

"I wish to maximize my productivity by leveraging the efforts of the Open Source Development Community, thus getting us development resources at no extra cost to the company."

Re:Tell them your reasons

[heinousjay]

If I were granted mod points, I would mod you Evil.

Re:Tell them your reasons

[XO]

Yes, agreed.

Exactly why IS it that you want to GPL the code?

Will ANYONE benefit by having it GPL?

Difficult to present a sales pitch only knowing what we want to achieve, and not having any inkling of the steps inbetween.

Re:Tell them your reasons

[stinerman]

-1 ... you didn't use "synergy".

good luck

[quewhatque]

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.

Re:good luck

[chris_mahan]

There is an advantage to your competition using your code, especially if a lot of the competition is using your code. You will be seen as the de-facto standard settig body for the software, and that will attract good-will in the industry, allowing you to potentially hire their finest and brightest.

Also, bear in mind that this will give you an insight of how they run their business.

Finally, you could then turn around and sell them "SuperSoftware Enterprise Edition", since they alreay know and use and love SuperSoftware Standard.

Ultimately, though, your boss does not care unless the business makes moeny off it before year's end.

Remeber Google: If you want to build an $80B company in 6 years: Use linux and develop your own software.

step by step argument

[rnd()]

Here is the argument:

• GPLing the code may have the effect of creating a community of people to enhance and debug the code.
• If it's not a product that provides significant competitive advantage to your company, there is no harm in spreading it around in exchange for the benefit in the first bullet point.
• There may be some positive PR associated with the company "founding" an open source project. Who knows, there may even be some way to consider it a charitable donation and write it off of the company's taxes.
• Most importantly, there are a variety of Open Source licenses, so if your president balks at the GPL, consider the LGPL or one of the variety of others. They provide many of the benefits of the GPL but allow the boss to feel a bit more in control. You can always move to full GPL next year once his/her comfort level has increased.

Re:step by step argument

[swillden]

The LGPL still requires permission for others to sell derivative works.

No it doesn't. As long as the others distribute the source of the LGPL'd code along with the closed binaries, they're in compliance. No additional permission is required.

But since it allows for some closed source arrangements, it may be preferable to some bosses.

Why would some bosses prefer that others be able to use the company's property in closed source products, commercially, without permission? I would think that they'd prefer to start with a license that is more restrictive than the GPL, rather than one that is less restrictive.

support

[file cabinet]

sell the support. that's what the linux folks do (RH, SuSE, etc.)

Some ideas

[Zocalo]

• Free development of new features, some of which you might not otherwise have thought of yourselves if you can get a development community started.
• Free beta testing across a broader range of users and operating environments which should identify and enable the fixing of bugs far sooner.
• Free positive P.R. for your company, especially if things really take off.
• Free advertising for your company as well if you brand the package with your company logo and colours by default. Lots of people don't bother taking that kind of stuff out if it's not too obtrusive.

There's far more things that can be free than just "beer", and it's libre too, so you can even have some free Karma.

Realistically though some of that is going to need kickstarting which will require some small financial and time outlay. Things like provisioning the initial website and forums for your applications users to bounce ideas and code back and forth. Some man hours, probably yours, to apply patches and integrate new features until such time as you hopefully have an active enough community to let others external to the company help maintain the code on their own time and dime. Be realistic and give them some negatives too, albeit with a positive spin, to show that you've thought things through and demonstrate that the benefits outweigh the expense.

Oh, and if you do eventually get the product GPL'd, submit the news to Slashdot as a "Slashback"; that should give your fledgling userbase and development community a running start!

My boss was pretty cool about it

[vsync64]

He even let me set up a Web site to host some projects that we've made from scratch (more on the way) as well as just submitting patches to existing software. As far as convincing, it wasn't hard:

• He already knows a little bit about open source (although he did complain about how TightVNC "ripped off" VNC), and said that he's seen firsthand that good software can come out of that process
• Fixes and enhancements for things we use internally
• A chance that if I get hit by a bus, someone else out there has already used the code and can be hired to help
• Recruiting tool to technology people; shows some of our techniques, style, discipline
• Increases our perception as a participant in the community, thereby making people friendlier when we ask for help, enhancements, etc.

The real question

[Zphbeeblbrox]

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.

I agree...

[joto]

...with your boss.

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:

• Will it create good relations to someone the company cares about?
• Is the source code embarassing to show to others?
• Will the company actually benefit from other users sending patches? (and no, this isn't as clearcut as open source ideologes claim, see the question below...)
• Will this take significant amounts of your time that would be better spent doing other things that benefit the company more?

If you can find reasonable answers to those questions, a reasonable boss will make a reasonable decision :-)

Reasons

[Julian Morrison]

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).

Re:MehFortune-100-America includes IBM, Sun, HP,..

[hadaso]

> In Fortune-100-America, everything possible must be stamped with a (c) or (tm) or patent#.

Fortune-100-America includes a few small corporations (E.G. IBM) that find it useful to contribute to open source. They don't do it because they "feel like giving away their property". They do it because they figured out it would produce more money for them.

So the first thing one should tell one's boss is "See, it's good for IBM!".

The point is not that if it's good for IBM it must be good for you. The point is that Releasing the code that you don't intend to sell as proprietary software might save you in development and maintenance (even if you do have a product that might be sellable, you still might gain more from releasing it and getting IBM to contribute in its development).

If your boss understands the reasoning behind IBM's contribution to to "free software", then the boss's reasoning would become "reasonable, as in evauating savings in costs. (Actually the experience emplyees would obtain in one open source project can save indirectly when it applies later to incorporating "someone else's" open source project into your company's infrastructure).

What can happen to a new OSS project?

[mwvdlee]

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.

Ask him...

[seanellis]

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.