All the Perl that's Practical to Extract and Report

Open Sourcing Code written at work for work

ajt on 2004-04-29T20:07:20

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

Why ask us?

petdance on 2004-04-29T20:37:46

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.

Re:Why ask us?

ajt on 2004-04-29T21:34:05

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 modules, some of which we may be the only users off.

The problem in both cases is not with our technical motivation, rather the non-technical boss who holds the keys. In the PM thread, you are correct the OP offers no reasons or suggestions, but the tread has many suggestions to in favour of a release. I though that the suggestions were similar to the ones we have had at work, and while I think that some of them are sound, I'm not convinced that alone they will convince a skeptical non-technical boss.

I could not agree more that there is no point in releasing something just for the sake of it.

It depends on the code itself

TeeJay on 2004-04-30T09:21:58

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 worse they could hold at least some IP on it.
  • Is it worth the effort of releasing? sometimes a piece of code simply isn't worth releasing. There probably won't be any interest in it and you could spend time mucking about releasing it when you could be working on something more worthwhile. In this case it might be worth mentioning on a relevent list and if anyone is interested provide them with a copy - hopefully they can worry about releasing, and provide you with feedback.

Having said that I have open-sourced 3 CPAN modules and backported some code to my CPAN modules from work projects at this company alone. I had good reason to - all of it was code that we use, all of it was code that we could do with help working on, and none of it would help our competition (unless they use an identical design, with the same modules doing the same thing).

The code we have released has had some very clear benefits - bug reports, testing and porting to new platforms (within a month we had FreeBSD and Debian packages built and tested by outside people, handily preparing the ground for the server environments we plan to deploy on), feedback and fixes. Of course the ebXML module has had a total of 5 downloads since release and not a word of feedback, but hopefully a few others might get interested and we can build on shared experience and code in a way that that benefits all our employers (as well as FOSS in general).

Re:It depends on the code itself

ajt on 2004-04-30T10:42:45

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.

Re:It depends on the code itself

rjbs on 2004-04-30T13:50:34

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 are not a charity.

Ok. Are you a software house? Are you going to sell it? Ever? If not..

* Supporting outsiders will waste your time.

I was surprised when someone here suggested that would be a cost. I just said, "I'm not going to write code on work time that doesn't help work. It wouldn't be good for my career." That seemed to ignite bulbs over heads. "If someone finds a problem that will affect us, great, I can fix it. If not, I'll ask the reporter to let me know when he fixes it on his own."

Are there other objections?

(I agree with the previous replies, though: getting this kind of thing approved is a hassle. It costs brownie points. Save them until you've got something to release that will earn you more brownie points from outside. Don't use up your office cred pushing to release Addition::Simple! :) )