I have a client with tons of Perl code, some solving issues that are not available from CPAN. The developers are aware of CPAN, some of them have even started to use modules but they - as in my experience most developers in companies - hardly use the services the community provides.

I would like to convince management that it is for their advantage to release some of this code to CPAN. I've written this to help me think over my reasons before talking to them and to get your opinion on the issue.

Propriatery company
One of the reasons they might not want to release is that they think the technology they created is unique (in fact, it is not available from CPAN) and as a company that lives from propriatery software it is hard for them to release any code as Open Source. Even though this code is part of QA and nothing to do with their products.

In addition to the code that is not available from CPAN they also have plenty of code that basically provides the same functionality as some of the CPAN modules but were written internally. Some were written even before the relevant modules were available on CPAN, others were written despite the fact that there were similar modules available but either bacouse of some technical problem or because of the NIH syndrom, the CPAN modules were not adopted.

So now, because they have not released those modules to CPAN when they were new, the company has to maintain a set of internal modules spending lots of time and money. Most of this work could have been outsourced to the community by getting some other people involved in the development or passing the maintainership to some interested people.
These modules are usually also less flexible than their CPAN counterparts as they only solved some subset of the problem and as we encounter more of the same problem we have to improve these modules. Replacing them by the relevant modules from CPAN is not easy as they have slightly different APIs.

Releasing code takes time
They are afraid that the extra work needed to create a CPAN distribution and then to support the users is too much and is a waste of time.
The developers will also have to spend time now researching other CPAN modules, discussing issues on mailing lists etc. just in order to get their modules up to CPAN.

I think that many parts of the extra work should be done anyway if we want to maintain our code with high standards. (Easy packaging, unit tests, documentation. I am directing them in that direction anyway.) The support issues should be either rejected and users should be told to implement their extra requirements as subclasses (but then of course we need to implement our modules with clean separation and easy subclassing in our mind) or should be accepted as patches or just seen as opportunities to get free QA on our code.
IMHO the extra time spent on getting involved in the community will pay off extreamly well for the company. The employees will be much more knowladgable about the tools they use, they will be able to solve problems much faster as they have the help of the community, they are also going to be much more satisfied as they see their code is being used by others.

Releasing trade secrets
They are afraid that some of the code that goes out might actually reveal real trade secrets of the company.

I think the internal code reviews of management should be good enough to avoid such situatuion. This is easier when we are talking about source code that is in the QA department but can be done even if the code is part of the product or service.

Helping the competition
They are afraid that by releasing code they use internally for testing they give tools to the competition free of charge.

While among other companies, competitiors can also use this code most of the users will probably companies that are not competitors at all.
Also usually these modules are not some Earth shattering inventions and I think the advantages of releasing code are much bigger to our company than to the competitors. Besides, in a short while someone will upload such a module and then we are left with the costs and the competition still got the help free of charge.

So that's it for now, I would be glad to read your opinion on the issue.

Update

Interestingly above I was focusing on defending the reasons to release code instead of pointing out the benefits. So let me do that now, partially based on some of the existing replys:

What can a company gain by releasing some of their code to CPAN?

peer review, more people looking at the code and improving it
finding and fixing bugs even before we hit them
finding and fixing corner cases
making sure the code runs on several platforms even before we can test it
forcing us to provide better quality:
- packaging
- documentation
- unit tests
- platform independency
- clean implementation
- reusabilty
Getting our developers involved in the community will make them become more productive
Help attract good Perl developers, help in recruitment
Help retain the good developers
Allow them to reuse code written here on their next job, thereby getting them to improve our tools even after they leave our company and are on someone else payroll.
Make the developers interested not only the pay they get for writing this code but also by having their name associated with some code that the next employer can examine. That is, writing good and reusable code will be a clear interest for them.
New hires might already use some of our code thereby reducing training cost

Comment on How to convince a client to release Perl code to CPAN?

Replies are listed 'Best First'.
Re: How to convince a client to release Perl code to CPAN? by philcrow (Priest) on Jun 22, 2007 at 12:37 UTC
They are afraid that the extra work needed to create a CPAN distribution and then to support the users is too much and is a waste of time. The developers will also have to spend time now researching other CPAN modules, discussing issues on mailing lists etc. just in order to get their modules up to CPAN. We build all of our code in CPAN style distributions and use a private mini-CPAN to install on our production boxes. We also have some modules on the actual CPAN which are of more general use than the applications that only support out business. It takes less time to work this way. You get a convenient package, a place to put tests, a test harness, a central repo of internally released code, and an easy way to send to CPAN when you feel like sharing. As for discussing and maintaining, the time spent is a two way street. Yes, you get some RT tickets for issues that you don't want to fix. But, you also get patches for bugs you hadn't hit yet. It is very easy to send a simple message to bug requesters whose problems are spurious or outside what you want to spend your shop time fixing. For the genuine bugs (especially the ones that come with patches) you save time. They are afraid that some of the code that goes out might actually reveal real trade secrets of the company. Make sure that whoever is afraid of the possibility is consulted throughout the development process for code going to CPAN, not just at the end. They are afraid they will miss something in a press to release, take away the fear with more information over a longer time period. Further, establish guidelines for what constitutes publicly viewable code and don't go near the line. They are afraid that by releasing code they use internally for testing they give tools to the competition free of charge. Let me relate one story about release benefits. Our parent company is a newspaper. They have developed a CMS internally. About two years ago, at the request of the lead developer, the company decided to release the framework (but not the CMS itself). It became the open source django project. Since then, they have made major sales of the CMS. Some feared at the time of the open sourcing that developers were pushing for that so they could take the code with them to a new job. Their fears were realized. Now at least one of the developers is paid by a different company to continue work on the framework. Having a former employee still doing essentially the same job (at least part time) on someone else's payroll is just too good. Our own shop has released a web framework for business apps http://www.usegantry.org and several other small modules to CPAN. None of them tell you a thing about our business outside of some passing references in the docs. A final note about helping the competition. Even if the competition is smart enough to begin using your CPAN modules, you don't necessarily loose. Consider the insurance industry. They constantly pool data about things like mortality rates. That is the competitors help each other when it saves everyone money. Yet they still compete on the products they offer. The trick is to find the areas where pooling resources is a money saver which does not impact your core products. Good luck. Phil The Gantry Web Framework Book is now available.	[reply]
Re: How to convince a client to release Perl code to CPAN? by clinton (Priest) on Jun 22, 2007 at 09:41 UTC
Besides the obvious benefits of peer review, having their name associated with CPAN released code will help to attract good Perl developers when they are needing to hire. Clint	[reply]
Re^2: How to convince a client to release Perl code to CPAN? by szabgab (Priest) on Jun 22, 2007 at 09:45 UTC
Good point, as they in fact are having trouble finding good Perl developers.	[reply]
Re: How to convince a client to release Perl code to CPAN? by merlyn (Sage) on Jun 22, 2007 at 21:14 UTC
One thing that's worked in the past is that I have a frank conversation along two angles: If I hadn't used the CPAN, this project would have cost you $X more money. The CPAN exists because everyone contributes a little, so that everyone saves in the long run. You're not legally obligated to return a bit of the new development based on the CPAN stuff, but I'd suggest you're ethically obligated. How about it? If we submit the core engine of your project (but not the localized bits) to the CPAN, then there'll likely be more people making it better than just the folks in this building. This also means that you can hire others and not just me when you need updates, because other people will also understand it. And with more people understanding the technology, you'll get competitive bids from more than just me. Usually, one or both of those is pretty convincing, from a business perspective. In fact, you could even take a moral stance on "no using from the CPAN unless I give to the CPAN", and submit two bids, one with CPAN exchange, one without. -- Randal L. Schwartz, Perl hacker	[reply]
Re^2: How to convince a client to release Perl code to CPAN? by DrHyde (Prior) on Jun 25, 2007 at 09:21 UTC
I never came across any successful business (apart from the occasional weird hippy selling vegan shoes and related foolishness) which took ethical considerations seriously. Sure, lots of them pay lip-service to it, but all they really care about is screwing as much money as possible out of people. Even nice fluffy co-operatives are all about making money for their members. If you're going to convince your boss to open your code, you need to show him how the company will benefit from doing so. Ethical considerations don't enter into it. As an employee, I approve of that. It's his job to make the company a ton of cash, and if he doesn't do his job I get smaller pay rises. As for your last paragraph - that actually means he'll get three bids, one with CPAN and one without from you, and one from someone else where the developer will take from the CPAN but not give back.	[reply]
Re^2: How to convince a client to release Perl code to CPAN? by Gavin (Archbishop) on Jun 23, 2007 at 18:16 UTC
You old smoothy you!	[reply]
Re: How to convince a client to release Perl code to CPAN? by roboticus (Chancellor) on Jun 22, 2007 at 12:08 UTC
szabqab: I think the way that I'd argue your case would be something like: Suppose your company makes spatulas. You have to have machines to build your spatulas. These machines are definitely proprietary, as any innovations would help you build your spatulas better/faster/cheaper. But these machines are made of motors, screws, wire, brackets, etc. Suppose you're building your own screws for your machines. Chances are, you're not building them as cheap as possible, and probably not to standards. (After all, you guys make spatulas and are interested in screws only to the point that you can make your machines.) Also, it's unlikely that your machines will interface with new machines you want (such as one that puts your spatulas in indestructible plastic-wrap). So you have quite a lot of effort invested in making screws that (a) aren't as good as they could be (i.e., they could fail in unexpected ways at the worst possible time); (b) aren't standard (so you have to do even more work building things to interface your machines with others); (c) have a much higher unit-cost than screws you could get off the shelf; and (d) aren't critical in any way to the process of building spatulas. How do we address this? If you give away your screw-making process, then others have the option of looking it over and make improvements at no cost to you, which helps case (a). If others use them, you build a community standard so your machines will more easily interface with others because you're using the same fasteners as other companies, mitigating case (b). Someone may decide to be a screw specialist and make great screws, and because that's all they do, they'll bring the price down (the better to crush their competitors), alleviating case (c). And none of this will impact your manufacture of spatulas, with the exception that the personnel who used to be making screws can be improving the parts of your spatulatronic genesis device that are critical to the arcane art of riveting flat flexy metal bits to handles. So if others use your CPAN module and improve it, you can only benefit. If no one uses it, you get the benefit of putting your module into good order (since it will be in the public eye), and you get the benefit of always having a backup of it! ...roboticus	[reply]
Re: How to convince a client to release Perl code to CPAN? by DrHyde (Prior) on Jun 22, 2007 at 10:27 UTC
I too have to convince my boss to release code soon. I shall argue that: Anything that implements our business should not be released; Anything that doesn't care whether we make spacecraft or whether we schedule street sweepers should be released. Not releasing what makes our product unique makes sense, partly for financial/competition reasons, but also because no-one else would be interested in it anyway and we'd not gain the benefits of ... Releasing stuff that does not make our product unique, such as a Class::DBI plugin, means that someone else will find and maybe fix our bugs for us, thus saving us money. So what if our competitors can use it? It's not like it would be hard for them to re-implement it from scratch in a few hours, and the benefits we gain by being a Good Citizen (which helps with recruitment) and getting bug fixes from other people would outweigh that.	[reply]
Re: How to convince a client to release Perl code to CPAN? by zentara (Cardinal) on Jun 22, 2007 at 12:08 UTC
Would it qualify for a tax-writeoff? If not, it at least makes for good karma. :-) I'm not really a human, but I play one on earth. Cogito ergo sum a bum	[reply]