Slashdot Mirror
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."
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.
"Piter, too, is dead."
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."
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
I'll tell you what you should write: code.
./run" style working processes. GPL and F/OSS are about code and code is all about what runs, not what someone 'thinks' about it.
Seriously, if you want to convince anyone of the 'superiority' of open source versus hidden source code, then simply write some glue code of your own which does something special.
That is to say, position yourself with GPL/OSS code in such a way that you prove that the open stratification of code, abstract on whatever levels you choose, is worth the effort. Write an app using GPL'ed API's that nobody else could've written, quite so quickly, if a deep and sudden understanding through direct study of contributed frameworks wasn't done first.
The way to profit from F/OSS begins with your own territory. Stake out a claim, find those who support your effort, apply their work to yours, and do it fast.
I wouldn't bother with 'reports' and 'presentations'.. thats all horseshit in the reality of "./configure ; make ; make install ;
Face reality: it ain't good enough until you've added your bit.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
First off, there's no downside:
- It costs nothing
- It risks nothing, as there is no marketability
- The licence clearly states no warantee, no support
It's "fair" and good for "the community"
- You use open source, so you should "give back"
- Others may benefit from it, appreciate you
- If everyone takes cost free steps for mutual benefit, everyone will be better off
The upside is all positive:
- You may get help finding & fixing bugs
- You may get help enhancing it
It highlights publicly good work that your company has done
- Releasing code is comparable to publishing in a trade journal, and is valuable for the same reasons
- Associates your company, department, and you specifically with an area of expertise
- May place your company in higher esteem among the IT community, which helps hiring
- Generally, networking with others with similar business problems is good experience
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 :-)
My biggest hope is that my company doesn't enforce their "all your copyright are belong to us" policy.
In the past when I've worked for companies with overly broad copyright assignment clauses in their contract boilerplate, I've had them reword it to allow me to maintain copyrights on code that could be considered general purpose. The wording generally goes something like "... with the exception of code that implements functionality basic to the day to day tasks of software development," but sometimes is " retains the copyrights on pre-existing code brought to the company with him, and on modifications and enhancements to such code." I've never had anybody say no when I've asked in the past. Typically the terms are written by lawyer-folk who try to get as much as they can when writing contracts with the expectation of negotiations later.
Either way, it can't hurt to ask. Worst case scenario, they say no. Same goes for when you're discussing salary.
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.
It costs the company nothing & you get a near complete app which needs further development.#2
Impress him with the features and ease of use/cost.
#4 Explain that it must be rewritten at a significant toolkit/developer cost
or
for nothing, we can release it under the terms of the GPL.
His next question is what are our requirements under the GPL? Every CD ships with the source code, keep copyrights & GPL notices, done. In my case, He agrees, since we are a hardware house and his money isn't made with CD sales anyway but with device sales.
YMMV, he wants to know whats in it for him, NEVER FORGET Your time costs him money.
OSGGFG - Open Source Gamers Guide to Free Games
Simple. Infrastructure code is not a competitive advantage. If we don't GPL it, our others will simply build effectively the same infrastructure on their own.
If we GPL it, though, other people will adopt it instead of writing their own. We then reap the benefits of their improvements to the infrastructure.
And just to be clear: We aren't GPLing our code that makes us unique & that is our real value.
Not to mention the goodwill GPLing the code will generate for the company. Or possibly good press. Or the karmic benefits of giving back after having leveraged PHP & other open source code in building our business.
The only real advantage the higher-ups would consider is whether people who use the program would be people who are interested in whatever products your company sells. Open Sourcing a program is a good way to get your name out to people who may not have heard of your company's name (and make sure to put the name in the program to keep them happy, and the 2.0 release to say bad things about them because you got fired last week). The only problem is if your company doesn't have anything would be of special appeal to the open sourcers, then it might not make much sense. Heck, if they sell some product, could just call it free advertising. Yeah, yeah, we could talk all day long about linux, GNU, FSF, and the GPL, but the higher-ups' brains would have checked out long ago. That's the only really special appeal I could think of that they might consider.
You're going to sde a lot posts about "show him the business reasons" and "make a business case for it" and "find a company that's currenlty benefiting from open source and share that"...and they're all great reasons if you want to spend the next 2 years convincing him (in which time your framework will be out of date and worthless).
:)
:)
Or you could take a couple of steps back and think a bit about human nature. Most people (99.9999%..ok, I can't back up those stats) will take 2 years to make a logical decision and 2 minutes to make an emotional one (yes, even CEOs)...and what's the biggest emotional motivator? Fear!
"Hey bob, did you hear company X (where X is a random competitor) is open sourcing their framework?"
Now forget all about it, go have a coffee, when you come back to the office you will miraculously have one of upper management not only giving you permission, but actively directing and tasking you on his/her new "open source vision"...which he/she will sell as their idea, which is a double bonus, because if anything goes wrong it's not you in the firing line, however if it all goes right then people know who wrote the code
Niccolo would be proud
This is just a thought.
I'm not a tax law expert but could a "code donation" be considered a charitable donation. Figure out how long you worked on the project and determine the monetary value.
Tell them that using GPL code reduces their costs because you do not need to "reinvent the wheel" every time you work on a project.
Technically you don't need to release any changes or additions you made to GPL'ed code if you keep the project in house. If your employer does allow you to release the code, you can always argue that there will be "free labor" from developers in the community. In reality, most projects on Sourceforge get little help from the community. Many projects go unchanged after they are posted. This does not detract from their value. There have been many circumstances where I have found a project that fits my needs but the maintainer is no longer active. These projects are often a great reference or starting point for a new project.
If your employer still does not allow you to GPL your work tell them you will not use GPL code in future internal projects. You can tell them future projects will take longer because you will have no base to work off of. More time and lost productivity from you.
That's basically a limited analysis. What you forget is that any piece of code can immediatly improved on and suddenly generate a small profit stream. As soon as it is released, the cahnges are easily made withoit help from the company, this sealing off that source of potential revenue.
While there are ways around this problem, they generally require planning beforehand (e.g. source release scheduling).
Besides - a lot of people haven't read the GPL fully enougd te understand it's ramifications. There's bound to be at least one newbie lawyer or administrator that thinks nothing can't be dane against code obfuscators.
Do you know that for sure?
R&D costs cannot be recouped as easily. Any competitor that needs to cut back will explore existing software before attempting to write their own.
As a variation on a theme: "Give a man a fish, you feed him for a day; teach a man to fish, you created competition."
Of course Pepsi isn't interested in Cake's formula. However, this does not mention other companies that would just love to get a boost in sales with something like counterfeit Coka Cola.
There's plenty of arguments for GPLling code - the trick is finding some that work best for the business. Anything else is BuckShot reasoning.