Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ajt (2546)

ajt
  (email not shown publicly)
http://www.iredale.net/

UK based. Perl, XML/HTTP, SAP, Debian hacker.

  • CPAN: ATRICKETT [cpan.org]
  • PerlMonks: ajt [perlmonks.org]
  • Local LUG: AdamTrickett [lug.org.uk]
  • Debian Administration: ajt [debian-adm...ration.org]
  • LinkedIn: drajt [linkedin.com]

Journal of ajt (2546)

Thursday April 29, 2004
03:07 PM

Open Sourcing Code written at work for work

[ #18553 ]

There is a very interesting thread on Perlmonks where someone asks "How can I persuade my non-technical boss that open sourcing some of my code is a good idea?".

It's interesting because it's very good timing: we have been having similar thoughts at work, and some of the comments are the ones we already thought off. Most of the arguments appeal to human nature: greed - this will save us money or decency - we are paying back to the community that we have greatly benefited from. While I can see the logic of these arguments they don't overcome corporate phobia of liability or paranoia.

The arguments are pretty much:

  • If we give the code away, people will use it and give us ideas and bug reports that will help us make our code better, and that's free debugging help. The more eye-balls and pairs of hands argument.
  • If more people use the code, then you'll be able to replace/augment your staff more easily.
  • We are using open software already, so we are simply paying back, plus we can get good publicity from it.
  • We are a blue chip company that makes stuff, software isn't our business, so it's not as if it's any specific help to our nearest competitors.

The counter arguments from a non-technical boss are fairly strait forwards, and while some of them may result from general ignorance, they must be countered if we are to overcome.

  • If it's useful we should sell it, we make money we are not a charity.
  • It's a distraction on your time, and the support requests will waste more of your time.
  • We can't give anything away it's all company confidential, just think what would happen if our competitors got hold of this code?
  • The lawyers will have a fit, what would happen if someone dies because of this, we can't afford a lawsuit.
  • You can give away a closed-source thing only, the source code must be hidden.

Now you can always release on CPAN and strip the companies name out, or even publish under a pseudonym, there is a VERY long history of this already, but it's stupid and potentially risky...

What is a community spirited perl hacker to do... ?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Open Sourcing Code written at work for work 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It's not a very interesting question at all. The Anonymonk has given us no reasons. Why would we come up with reasons why he would want to release the code? How do we know where his benefit is?

    A reflexive "let's release the code!" isn't useful.

    --

    --
    xoa

    • I have no idea what the Anonymonk's reasons are.

      My perspective is that, our code may be useful, avoiding wheel re-invention and all that, and I think that extra eyeballs would be useful - we're a small team, and we're not a software house. In principle, I feel that if others may find something useful it's worth releasing. Over time this may prove to not be the case, and the module can be deleted, or taken over by someone else, but if you never release, you'll never know. We have benefitted from other's mo

      --
      -- "It's not magic, it's work..."
      • The most important thing is the code itself..
        • Is it directly contributing to a 'product' or 'service' ? in which case, giving it away does reduce your competitiveness. (although Redhat has shown otherwise, as have some others)
        • Is it related to another companies IP or any agreements your company has signed? in which case, its not worth the hassle of even looking at releasing
        • Is it code that a customer has paid you to produce or customise from them? if so then they will be pissed if you release it, or wor
        --

        @JAPH = qw(Hacker Perl Another Just);
        print reverse @JAPH;

        • In our case the code is not in any of our products, is all in house and has no external attachments, and is not something we did for a customer. As far as I'm aware it's there are no actual legal attachments, but that's not to say that there are no perceived legal strings...

          The main criteria of is it worth it, doesn't wash with management, they don't care about that one. In this case I believe that it's probably worth it, but we need to convince management that they won't lose anything, and may even gain.

          --
          -- "It's not magic, it's work..."
          • You said the costs are:

            * Could be confidential.

            Well, then you say this probably isn't a factor, here, so you can cross that off.

            * Could help competitors.

            Again, if it's not trade secrets, this doesn't matter, right?

            * What if someone dies and we get sued?

            The license precludes any such suit. Anyway, It Just Doesn't Happen.

            Also, you said: "You can give away a closed-source thing only, the source code must be hidden." This isn't a cost. What's the associated cost?

            * If it's useful we should sell it; we
            --
            rjbs
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.