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."
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.
highly competent Slashdot crowd
It's funny, laugh!
I like my women like my coffee... pale and bitter.
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
Well, that was your first mistake.
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
sell the support. that's what the linux folks do (RH, SuSE, etc.)
- 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!
UNIX? They're not even circumcised! Savages!
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. --
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
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
I think it would be more productive if you would share a practical reason for GPL'ing the code, if you had one.
-jpeg
Another potential positive aspect is relicensing. Some companies are so GPL-phobic that they will pay to have you (or your company) give them a one-off, non-exclusive waiver, so they can use your code without the (perceived) GPL albatross hanging round their necks. I've worked on open source projects (e.g. HMMER) that have made money this way.
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 :-)
If the company doesn't feel okay about GPLing this piece of software, but doesn't really care about hanging on to it you might be able to talk them into simply disclaiming copyrights over it. One imagines that copyrights would then devolve to you, and you could GPL it.
Outside of that check out ESR's various works for "business minded" reasons to go "open source". He has particularly compelling arguments for just the sort of thing you've written.
-Peter
1) Assume, you're not as bright as you think you are
The security architecture flaws in the code will be revealed, exploits developed that with your self ingratiating credits attributing your handiwork to your company by way of email addresses with the companies domain and along with the unwitting conspirators names and emails who helped with the code all of which are very easy to track down using Google.
GPL Lesson 1
Do not attribute the code so that it can be linked back to the associates or persons or company you work for that uses it.
Do not gain personally from your companies work. It just smells like your trying to look good in the GPL community.
Assets of a company are company property even though you conceived developed and birthed the ugly baby, remember you're just its care taker.
Do you really need that much attention; are you able to keep up with and tolerate hands all over your pride any joy?
What happens if that encryption code you implemented, you know the one with the name "Base64_encryption() turns out to NOT be encryption at all, but no one bothers to tell you for 6 months?
You and your company could suffer irreparable damage to the public's opinion when all their accounts are stolen from your base 64 encoded databases.
Lesson 2 if you still have to enlarge your ego,
Get a large consensus of reviewer in company, including legal department, and at least one officer of the company before anonymously releasing your baby into the world.
By eliminating the perception of self ego ingratiation, you will gain true respect( A harder commodity)
If the resulting GPL release could ever be traced back to theft of records, the SOX and HIPAA folks would roast those responsible.
But the best reason to forget your idea, is simpler then all of the above.
If god wants your source code GPL'd he will accommodate you by way of haxxors who will know if your code is good enough to publish better then you do when they see it.
--
Why did the haxxor cross the road? To bit to the other side..
Ask "Is keeping this closed going to make us money?"
If it won't, and it's something that others (not your competitors) may find useful, then you may as well GPL it, to let others discover the bugs before you do.
builds goodwill of a community (that may be your customers (?))
can result in free development work by hobbyists that use your code
allows you to legally make use of the vast library of other GPL code out there
a free alternative may supplant proprietary solutions of your competitors (see IBM's various contributions..); best if you have no commercial plans for your product
open source is a cool buzzword to have attached to your product and company at little cost
Of course, if you can sell him on FSF dogma, then there are loads of philosophical advantages, too.
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).
> 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).
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?
Consider this senario: you want to convice your boss to open source. To do you could first show him all the other open source code which is available to use. Without the viral clause this would work fine, your boss would see all this code, use bits of it and a year down the line might actually consider contributing some of their own code.
The viral clause means this senario won't happen. Your boss will read the GPL and notice that by linking in that code they will need to also release their code under GPL. For an open source newbie this is not something he'll be willing to do. The consequence of this is that the boss will instantly dismiss the ideas of open source and never get to see the advantage. In essence the viral clause creates a block to acceptance.
To get around this block, hunt out LGPL code or the other open source licences which do not restrict the freedom to distrubute products incorperating open source code under their chosen licence.
Alternativly consider becoming a contractor. The rules of engagment of different here. As a contractor you have more freedom to develop your own code base. Employers pay you for the knowledge (and code) you have built up over the years and be more understanding of your need to continue building that.
p.s. Yes I know viral probably not the best term to use here (see slashdot passim), just can't think of a better term.
There are four sorts of people in the world: fools, lunatics, idiots and morons. - Umberto Eco, Foucaut's pendulum.
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.
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.
That's nice but irrelevant. GPL doesn't invalidate a copyright, it relies on a copyright holder to offer the source as GPL. Whether that is a person or a company does not matter.
If you don't like the company owning everything you write don't take their money, their health insurance, etc. That's the tradeoff, every relationship has some give-and-take. "Size" doesn't really matter, why should the company spend time/money evaluating your code and scripts to determine what is worth keeping and what is worth letting go? And finally why you expect one employer to allow you to take something they paid for to your next employer?
As I programmer I understand being emotionally attached to what one writes but come on, be realistic. Sure I would like to have some of the stuff I wrote in the past but damn I sure did like those regular paychecks that never bounced and just kept on coming so predictably.
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.