Well, you know how I feel. :) But the others don't so...
I believe the most crucial and missing approach is to put resources into
making ready-made applications that work on mod_perl rather than core
mod_perl itself. This is also a problem on Linux, but that's another story.
A quantity of applications for mod_perl or that demonstratively show that
using mod_perl is a benefit (ie fast) is necessary (and I don't mean tech
products like AxKit -- which are great but not what I am talking about)
There is very little out there in the various product categories that works
as mod_perl registry script. Probably equal in number to the amount of
public domain Java servlets! If you talk platforms, PHP has surpassed
mod_perl-capable applications.
Of course, as you say, you want to work on core mod_perl (not doing forms
applications... :)) so that is a different story. But to me, mod_perl is
exciting enough at the core level and the work, while it might be cool to
do more for v2, is already basically there.
But if you want to generate excitement about a platform we have to start at
a higher level -- show a suite of complete applications that can run ready
made on top of mod_perl to make it obviously enticing to use.
I am not talking about AxKit, HTML::Mason, etc. These are tools, not
applications or application suites. Programmers on this list and the people
who like mod_perl are similar IMHO to the people who like Linux. Constantly
interested in improving the core stuff.
I think that passion and interest is great. But the problem is bridging the
gap that brings the masses to a product and generates a lot more
excitement. In marketing, this is called 'Bridging the chasm" I think. Most
commercial products (not just open source!) follow a life cycle of which
one part of the life cycle is extremely difficult to bridge.
I am probably going to get the steps wrong because it's been a couple years
since I read this book. But the basic idea is this.
The first step is the early adopters (this is you Stas -- with running Perl
5.6 before it's stable, being so interesting in mod_perl 2.0 a year before
it's out).
The second stage consists of the technical few who aren't early adopters,
but when the early adopters say something is basically stable enough, the
technical few can try it, like it, and start using it. These are most of
the people who post regularly on the list (probably someone like me -- I
don't like adopting things too early -- I prefer to wait til it's stable --
but I think I like cool technology).
The third stage is those that are more pragmatic. Not necessarily the
technical elite, but that it is possible for an everyday person to start
using the product. This is the stage that mod_perl is at now. I think you
are seeing a lot more people who have used mod_perl and are not afraid of it.
Then there is popular acceptance. This is the chasm that must be crossed.
There are a couple ways that this chasm can be crossed. They all basically
entail marketing the product in such a way that the masses feel that are
indispensable yet easy to use the new product.
I believe having more full-applications delivered that work in a mod_perl
environment (at least Apache::Registry format) is one of the keys here. The
ideal is rather than individual apps, it could be suites of apps that
demonstrate working together (ie SmartWorker, eXtropia, any others?) and
capable of running under mod_perl for extra speed.
The suites are ideal (but not necessary) because it makes it easier for
users to pick up one app and then understand how the other apps work. Most
unfortunately, we know SmartWorker had been way-laid by being a startup
that needed to pull resources towards a business product (eg opendesk).
And I can't say that eXtropia has been that much better in terms of
delivery -- although we (Stas) have devoted a lot of time to making sure we
have yet another generation of application to deliver in the coming months.
So hopefully that will come about before PerlCon.
The way our company works though is that we have spurts where we
occasionally realize "Oh shit, we need to complete XYZ commercial project".
So the open source gets delayed again for a bit. Usually our open source
development and our software releases tends to following a few months of
open source coding and then a few months of not open source coding on the
Perl side.
This isn't consistent, which isn't nice and ideal, but at least we spend
the money and time on it when we can as a company.
Actually it's not a matter of money for us anymore (thankfully) as much as
that we may get a job that turns out to be big enough that we need more
people -- but we can't hire fast enough to do the job that we commit to
because the lead time for hiring someone is a minimum a couple weeks of
interviews and then that person usually giving a months notice at their
current job.
Luckily for us, for example, the project that is being worked on now isn't
proprietary and although a bit rushed, is paying for our Perl stuff to be
developed by Stas, Ho Ming Shun, and a few others.
At least til Stas finds a home in a company that can afford to pay for core
mod_perl development -- which Stas deserves.
I think that Stas passion for mod_perl and the work he has put into it
shows a commitment that if anyone (other than Doug obviously) should get
paid to work on core mod_perl and would enjoy doing it, then that would be
Stas. I cannot recommend anyone else more highly for this role after having
worked with him in person. :)
Unfortunately for my company, other companies pay us for web applications,
not for technologies. So I know our company cannot really afford such a
luxury.
We always want to spend money on making apps that can get reused and put
back out in the open source community and would love those apps to be
tested and work as well as possible under mod_perl. But our company itself
is also growing and so we can't pay for someone to develop mod_perl as
their job.
I think all the commitment we've had to R&D over the last year for a
company our size (I think it is reasonable to quantify about 10-20% Open
Source R&D expenditure in salary time over the last year at any given time)
is pretty good. Especially consider so many companies are dropping like
flies and our grows (perhaps this is indirectly because of R&D?).
But at 18 people, 20% R&D is still 2-4 people. Right now, it is probably at
the 10% level and 3 months ago at the 20% level (depends on the project load).
So if you consider that we have a Java line of products (which ironically
sells better in the Asian market) that we should and try to devote one
person to, and a Perl line that at minimum we could devote 1 person to (can
be split amongst developers of course) then it leaves little room for
developing core mod_perl in terms of our business model.
I definitely think a company like Covalent or perhaps a company such as
ActiveState would be the ones (as they sell technology not applications and
are larger than us so they can probably take a larger R&D hit) to take the
helm and pay for mod_perl to be developed. In lieu of that, I'd like to pay
for the same thing, but I don't think it will happen until we grow to 40
people -- business reality. :)
Another issue (and may be for many companies) is that my company knows how
to market and sell web applications. It's what we've been doing for over a
year and what we had been doing as a hobby for 7 before that.
Our sales and marketing and business development folks don't know how to
sell mod_perl and mod_perl support. It would be a severe change in
direction for us to take on a Covalent-role and would burn many resources
including graphics designer and marketing people creating a pitch, creating
the graphics around it (sales collatoral), and just having one core expert
(eg Stas) on board would make the technical backing for such a thing weak
as 24x7 support become impossible (just give Stas a pager! and oh, he can't
go on vacation -- obviously this would not a good situation)...
And as I've always said... I think applications are as (and in some cases
more -- eg crossing the chasm) important to mod_perl than mod_perl itself.
An opinion that may not be shared by all, but at least this is my opinion.
Whether right or wrong, I believe in this concept so much that I am willing
to pay a salary to people to develop open source applications that can work
on mod_perl and committed myself to spending a year not having a salary to
build a company that is now profitable and capable of paying people
(including myself) to do this now -- as that was and remains my dream. :)
At 11:44 PM 4/27/01 +0800, Stas Bekman wrote:
>Well, I've talked to a few mod_perl guys over the last conference and by
>email lately and we have have all agreed that we are quite sick of
>generating forms and parsing them, no matter what cool toolkit and hype
>words we are using to do that. So we all are looking at doing core
>mod_perl, i.e. we want to develop *mod_perl* *itself* and tightly related
>modules.
>
>Since mod_perl is an open source, it's a tough quest. Basically what I
>want is get some company that will benefit from me working on open source
>project full time and pay me a salary. Of course it's probably hard to get
>a full time open source position, so probably some compromising offer,
>where we do some 50-75% of the time mod_perl development and the rest
>doing something else, if it makes the company more happy.
>
>Definitely I'm aware of the situation in the market. But you know what,
>look at the history, at any recession times there were always those who
>continued to prosper. Therefore I believe that some companies not even
>slowed down, but have accelerated their growth and have enough cash to
>invest into open source and make probably improve their image. Look for
>example at Covalent, I don't know all the details, but this company seem
>to stand strong on its legs. But Covalent has already Doug, so this is out
>of question.
>
>So if your company thinks it can directly or indirectly benefit from
>having one or more mod_perl experts doing cool mod_perl development, let
>us know. There are at least 3 people (including me) that want this job.
>I'm sure that there are many more that will be interested.
>
>I've mentioned in the subject that the request is unusual, so please
>respond only if you think you can stand behind this offer and not promise
>things that will never become true. I've bitten once on such an offer, and
>will try not to do the same mistake a second time in a row.
>
>Thanks a lot!
>
>On the related note, does anybody know about the financial status of
>Velocigen? How do they sell their products? We think to try to revive this
>old idea where we create mod_perl company, that will sell mod_perl and
>support. If Velocigen can do this with a closed source product, I believe
>we can do even better, especially with the drooling mod_perl 2.0.
>
>We have discussed this with I think 6 mod_perl guys about a year ago, but
>since all of us were programmers, we didn't get anywhere. May be we can
>come up with some nice business plan, and make a commercial mod_perl
>branch, boost the awareness of the product, get companies to invest into
>people developing it and make mod_perl a standard for webserver products.
>I know that it's a rewishful thinking, but with the right people and right
>companies I'm sure that everything is possible. I'm sure that you realize
>the potential of mod_perl.
>
>IMHO of course... I'm just a programmer, so if you ask about my business
>plan, I tell: you find a good business shark and push it forward, we will
>do the coding. Easy huh, but that's what we are good at -- coding, so we
>better do that.
>
>Anyway, fresh ideas are welcome
>
>_____________________________________________________________________
>Stas Bekman JAm_pH -- Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide http://perl.apache.org/guide
>mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
>http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
