in reply to How to convince a client to release Perl code to CPAN?
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
|
|---|