Hey Steven --
> If we could show Sun that they can make money off of Perl
> (e.g., with support
> contracts or proprietary modules that support sun-specific
> features) then they
> would have a reason to "sell" Perl. It will always be a
> step-child to Java but at
> least they won't be antagonistic about it. Hard thing about
> that is getting them
> to admit Java isn't everything to everyone everywhere --
> which has been their
> sales hype -- and still save face.
Right on!
Actually, Sun makes a little money off Perl right now -- in the form of
classes. (BTW, this is more proof that Sun isn't in the hardware business
-- they're mostly in the software and services business!) I don't know how
good, or profitable Sun's Perl classes are, but I would like to find out
more.
I am right there with you in terms of recognizing the need to provide a
profit-incentive for Sun (and ALL companies!) to use/advocate Perl. As a
matter of fact, it was profit-incentive which motivated me, and my company,
to release code to CPAN! This might prove a useful Perl-advocacy anecdote,
so I share it with you all:
The business of the company for which I work, Vanguard Media, is building
custom software for our clients on a contract basis. The software we build
for our clients is ultimately owned by them entirely -- lock, stock,
copyright & barrel. Straight work-for-hire. They pay us, we build their
software, and we hand it over to them. Very simple and straight-forward
(just like I like it!).
Starting about three or four years ago, we established a library of Perl
modules we had built over time to perform some low-level tasks related to
web-application development. These were libraries which evolved and became
more formal as our use of them became more frequent. In a nutshell, they
were developed because they represented things we did all the time -- Apache
authentication and authorization, application foundation classes, database
connection abstraction classes, templating modules, etc. Using these
libraries made our job easier (i.e.: more profitable), and so we preferred
using them on every client project, if our client would let us.
Here was the catch: Because our work is work-for-hire, we had to have a
separate license with our clients just for these libraries. We were not
charging them for the code -- we just wanted to use it without giving them
ownership. It saved us money, and it saved them money as a result -- a
win-win if I ever saw one!
Much to my surprise, some clients couldn't accept the fact that they didn't
own every bit of code we wrote for them. (Never mind the fact that they
didn't own the RDBMS or the web server or the operating system we used!)
This became a sticking point with those types of clients. Ultimately, we
would be forced to charge them more to create a "license-free" version of
their software. Kind of silly. We basically would be ripping off our own
work to re-do something we had already done. We weren't thrilled at the
situation.
At some point, the idea occurred to me that these clients also didn't raise
an eyebrow about all the OPEN-SOURCE code in their software, either! If we
released the modules we most valued, we would have the benefit of their use
while effectively side-stepping the whole ownership issue. We've released a
number of modules since then, and nobody has heard a complaint since! Of
course, we also have gained all the other benefits of releasing software
(too numerous to recite). Our libraries have improved in the past couple
years as a result, as has our ultimate work-product and our business
bottom-line.
TTYL,
-Jesse-
--
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jesse Erlbaum ....................... CTO
[EMAIL PROTECTED] ............. Vanguard Media
v: 212.242.5317 x115 ...... New York City
+-+-+-+-+-+- http://www.vm.com/ +-+-+-+-+-+-+
