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.
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
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
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
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
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.
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:
- unit tests
- platform independency
- clean implementation
- 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
- New hires might already use some of our code thereby reducing training cost
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
Outside of code tags, you may need to use entities for some characters:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||