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

4 of 139 comments (clear)

  1. good luck by quewhatque · · Score: 5, Informative

    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.

  2. Re:Tell them your reasons by jakobgrimstveit · · Score: 3, Informative

    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.

    --
    Jakob Breivik Grimstveit
    "I love deadlines. I love the whooshing noise they make as they go by."
  3. My boss was pretty cool about it by vsync64 · · Score: 3, Informative
    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.
    --
    TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
  4. Reasons by Julian+Morrison · · Score: 4, Informative

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