You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Gunther Birznieks <gu...@extropia.com> on 2001/04/28 06:33:02 UTC
Re: an unusual [job request] + taking mod_perl to the
commercial world
As I think I mentioned, it's great that the people like you on this list
have a passion for delivering cool software.
I may have missed the intent of these two posts (micropayment and messaging
engines), but unfortunately, I don't really consider either of these items
to be application-level items. I consider them infrastructure.
eg it's nice that SmartWorker (as a toolkit) is open source, but opendesk
is closed source. And it's the applications (ironically) in opendesk that
make smart worker worth taking a look at. But it cripples (hope I don't
upset anyone) SmartWorker's marketing to have opendesk closed source
because people prefer downloading apps and then they learn about the
framework it was developed in. Rarely is it the other way around.
People rarely look at toolkits like payment gateways and messaging servers
unless there is an application that fits their needs that they can use
which happens to use these backend components.
So for Adi -- I think the messaging server is great and I am sure it is
cool and works well. And I am sure there are people on this list who will
benefit. But unless your company makes the healthcare system itself open
source, then it's another application that we don't have to make people
interested in using mod_perl from the application side.
Likewise, for micropayments, -- great that there is a micropayment engine.
But unless there are applications to show off using the micropayment
engine, then it's not really helping to bridge the gap except to provide
yet another infrastructural tool.
Will these things come out? Maybe, yes, probably? But there's always been a
lot of infrastructural tools for Apache and mod_perl (eg Apache::Session is
probably one of the most popularly used next to Apache::DBI I suspect) and
yet these components haven't increased the amount of real applications for
people to download and run on mod_perl servers out of the box that they can
modify for their needs.
I don't mean to be disparaging because I hope there is a light at the end
of the tunnel, and I do think applications will eventually come out for
these components, but it's not a given. Sun spends a great deal of money
every year making lots of infrastructural stuff written in Java, but it
doesn't mean there are a lot of open source Java applications either.
The problem is that most company's that spend the time to write an app
based on Java close-source that app. The same thing is true of the mod_perl
world if things like Adi's healthcare system or SmartWorker's OpenDesk
remain closed systems. I know that they consider it their business model to
have to keep these closed source. But it also means less applications on
top of mod_perl to entice the masses to it.
I am sure it will get better, but the economic climate of companies going
under without revenue/profits does unfortunately mean that I am skeptical
that it will happen all at once in this year without a lot of concerted
effort from the mod_perl community to open source their applications that
run on top of mod_perl rather than keeping them all closed source.
At 10:21 PM 4/27/01 -0400, adi@seneca.certsite.com wrote:
>On Fri, 27 Apr 2001, Jeffrey W. Baker wrote:
>
> >
> >
> > On Sat, 28 Apr 2001, Gunther Birznieks wrote:
> >
> > > 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)
> >
> > I will be demonstrating a canned micropayment system at O'Reilly in San
> > Diego this year. The reference implementation for the content provider
> > uses mod_perl. I think you are right that most people in non-tech
> > business want a solution that works immediately, rather than a toolbox.
> > The toolbox is already there with Apache, mod_perl, and DBI, now
> > application developers can just step up and deliver.
> >
>
>My company has developed an internal messaging application that is written
>as mod_perl handler / DBI / CGI. It is like the internal messaging
>systems you see at trading sites like etrade, but more featureful... it
>supports sending messages to other users on the system, attaching files,
>and SMTP connectivity. It was designed for use by healthcare parties
>who require a secure environment (we run it behind our SSL server).
>
>We are planning on releasing it as soon as we can fully separate it from
>the rest of our code. Mostly just wanted to let people know in case they
>were in need of something like this and were thinking of developing it
>themselves.
>
>Cheers,
>
>- Adi
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: an unusual [job request] + taking mod_perl to the commercial
world
Posted by Matt Sergeant <ma...@sergeant.org>.
On Sun, 29 Apr 2001, Gunther Birznieks wrote:
> At 09:14 AM 4/28/01 +0100, Matt Sergeant wrote:
> >On Sat, 28 Apr 2001, Gunther Birznieks wrote:
> >
> > > As I think I mentioned, it's great that the people like you on this list
> > > have a passion for delivering cool software.
> > >
> >[snipped]
> > >
> > > People rarely look at toolkits like payment gateways and messaging servers
> > > unless there is an application that fits their needs that they can use
> > > which happens to use these backend components.
> >
> >Actually there's an exception to this rule. Look at Zope.
>
> But Zope has an application? -- content management. A template engine is
> not an application, but a content management tool built upon templates
> surely is?
>
> I thought you would recognize this as you are building something to allow
> this on AxKit?
I don't disagree with you, I just think it's a very fine line. Content
management is a kind of meta-application, because like the core mod_perl -
you still use it to build other applications. It just happens to have a
bit of a friendlier interface to it. And that's what it's really all
about - friendly interfaces.
Case in point. AxKit wasn't an immediate success (in mod_perl scale
terms) because it's a cool project, or because I spammed the list over and
over about it. It was an immediate success only after I changed the web
site from a drab and dreary look to the new design (even though everyone
hates the purple!). I know most developers find that hard to fathom, and
it still irks me a bit, but that's the reality of it.
> Of course, I guess you could consider AxKit an application because
> presumably it comes with scripts to allow aggregration of news content in
> RSS format? I consider this a really nice application.
>
> But it's also a bit difficult to tell that this is what AxKit does. You
> might consider separating AxKit the engine from AxKit the applications to
> allow people to find your site looking for applications (eg news, content
> management) so that they want to use AxKit. And then when they want to use
> AxKit, they will want to use mod_perl.
Thats the intention, and the RSS NewsMaker module (the news content
management system that Take23 uses) is separate, but I haven't really had
time to make it easy to use and install yet, typically. Interestingly
though there is very little interest in it, which is strange, but then I
don't have a link to it from anywhere.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: an unusual [job request] + taking mod_perl to the
commercial world
Posted by Gunther Birznieks <gu...@extropia.com>.
At 09:14 AM 4/28/01 +0100, Matt Sergeant wrote:
>On Sat, 28 Apr 2001, Gunther Birznieks wrote:
>
> > As I think I mentioned, it's great that the people like you on this list
> > have a passion for delivering cool software.
> >
>[snipped]
> >
> > People rarely look at toolkits like payment gateways and messaging servers
> > unless there is an application that fits their needs that they can use
> > which happens to use these backend components.
>
>Actually there's an exception to this rule. Look at Zope.
But Zope has an application? -- content management. A template engine is
not an application, but a content management tool built upon templates
surely is?
I thought you would recognize this as you are building something to allow
this on AxKit?
Of course, I guess you could consider AxKit an application because
presumably it comes with scripts to allow aggregration of news content in
RSS format? I consider this a really nice application.
But it's also a bit difficult to tell that this is what AxKit does. You
might consider separating AxKit the engine from AxKit the applications to
allow people to find your site looking for applications (eg news, content
management) so that they want to use AxKit. And then when they want to use
AxKit, they will want to use mod_perl.
Re: an unusual [job request] + taking mod_perl to the commercial
world
Posted by Matt Sergeant <ma...@sergeant.org>.
On Sat, 28 Apr 2001, Bakki Kudva wrote:
> On Sat, 28 Apr 2001 09:14:10 +0100 (BST)
> Matt Sergeant <ma...@sergeant.org> wrote:
>
> Amen to that and there is Enhydra on the Java side. To get the
> functionality of these two frameworks I'd have to integrate many many CPAN
> modules, keep track of various versions, make sure each is active etc etc.
> A nice application framework like Enhydra or zope on mod_perl which is
> maintained perhaps by all the authors of individual modules would be a
> great start.
Actually there are probably more than one project of this kind, but we're
working on something like Zope (with more of a focus on content
management) at AxKit. You can see some information about it on
http://axkit.com/products/
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: an unusual [job request] + taking mod_perl to the commercial world
Posted by Bakki Kudva <ba...@navaco.com>.
On Sun, 29 Apr 2001 13:52:05 +0800
Gunther Birznieks <gu...@extropia.com> wrote:
I completely agree with the assertion that applications sell the
underlying technology. History teaches us that to be indisputable.
Also while applications should be an overall part of the vision, it may
not have to be there right from the start. I have been peeking in at
Enhydra from time to time and I remeber in the beginning all they had was
the framework consisting of the multi-server, xmlc and perhaps DODS. Now i
see they have complete apps like Brock, jFAQ, and the fairly complete golf
store application all of which could be, as YABW (yet another buzz word)
says, "repurposed". Same is true of Zope where apps are emerging only now.
The tutorial is a terrific example of a zope app. Perhaps the roadmaps
followed by these two opensource camps will have great lessons for
mod_perl.
As the technology catches on the core-developers could form a company for
support, training etc as shown by Lutris for Enhydra and Digital Creations
for Zope. That seems like the validation corporations look for.
moral: lay a great foundation and they will build :)
-bakki
> I would like to restate that while I think these engines are cool and
> useful, that they are not the things that bring the masses to your
> platform. This was the point I was making. I am not naysaying projects
> like Enhydra, but just stated that they are not as directly useful for
> bringing the masses to the platform.
>
> While it is true that an "Enhydra" type of engine makes writing
> application
> easier, what you really still always need in order to gain a critical
> mass
> is something more concrete that the masses can hook onto.
>
> I am not talking about techies loving mod_perl or Enhydra or AxKit. But
> everyday webmasters and CIOs saying "XYZ platform has so many
> applications
> for it.... I can see them demoed, my tech staff can install them within
> a
> day...." so let's use it.
>
> There are just certain things that are harder to market than others.
> Applications make platforms easier to market because it shows off the
> power.
>
> I was not at the meeting, but I heard Stas convinced one of our clients
> to
> go with mod_perl by showing them a site he created called SinglesHeaven
> in
> CGI and then in mod_perl. "Look how fast it is and you can see it's a
> real
> application". Showing the same people benchmarks of hello world and
> template renderings generally do not have the same effect.
>
--
.-. | Bakki Kudva__________________Open Source EDMS______
oo| | Navaco ph: 814-833-2592
/`'\ | 420 Pasadena Drive fax: 603-947-5747
(\_;/) | Erie, PA 16505 http://www.navaco.com/
Re: an unusual [job request] + taking mod_perl to the
commercial world
Posted by Gunther Birznieks <gu...@extropia.com>.
I would like to restate that while I think these engines are cool and
useful, that they are not the things that bring the masses to your
platform. This was the point I was making. I am not naysaying projects
like Enhydra, but just stated that they are not as directly useful for
bringing the masses to the platform.
While it is true that an "Enhydra" type of engine makes writing application
easier, what you really still always need in order to gain a critical mass
is something more concrete that the masses can hook onto.
I am not talking about techies loving mod_perl or Enhydra or AxKit. But
everyday webmasters and CIOs saying "XYZ platform has so many applications
for it.... I can see them demoed, my tech staff can install them within a
day...." so let's use it.
There are just certain things that are harder to market than others.
Applications make platforms easier to market because it shows off the power.
I was not at the meeting, but I heard Stas convinced one of our clients to
go with mod_perl by showing them a site he created called SinglesHeaven in
CGI and then in mod_perl. "Look how fast it is and you can see it's a real
application". Showing the same people benchmarks of hello world and
template renderings generally do not have the same effect.
At 11:06 AM 4/28/01 -0400, Bakki Kudva wrote:
>On Sat, 28 Apr 2001 09:14:10 +0100 (BST)
>Matt Sergeant <ma...@sergeant.org> wrote:
>
>Amen to that and there is Enhydra on the Java side. To get the
>functionality of these two frameworks I'd have to integrate many many CPAN
>modules, keep track of various versions, make sure each is active etc etc.
>A nice application framework like Enhydra or zope on mod_perl which is
>maintained perhaps by all the authors of individual modules would be a
>great start.
>bakki
>
> > Actually there's an exception to this rule. Look at Zope.
> >
Re: an unusual [job request] + taking mod_perl to the commercial world
Posted by Bakki Kudva <ba...@navaco.com>.
On Sat, 28 Apr 2001 09:14:10 +0100 (BST)
Matt Sergeant <ma...@sergeant.org> wrote:
Amen to that and there is Enhydra on the Java side. To get the
functionality of these two frameworks I'd have to integrate many many CPAN
modules, keep track of various versions, make sure each is active etc etc.
A nice application framework like Enhydra or zope on mod_perl which is
maintained perhaps by all the authors of individual modules would be a
great start.
bakki
> Actually there's an exception to this rule. Look at Zope.
>
--
.-. | Bakki Kudva__________________Open Source EDMS______
oo| | Navaco ph: 814-833-2592
/`'\ | 420 Pasadena Drive fax: 603-947-5747
(\_;/) | Erie, PA 16505 http://www.navaco.com/
Re: an unusual [job request] + taking mod_perl to the commercial
world
Posted by Cees Hek <ce...@sitesuite.net>.
On Sun, 29 Apr 2001, Adi Fairbank wrote:
> Thanks Gunther,
>
> We actually have discussed releasing our entire application open source.
> I personally would love to release it, being the chief architect, but
> there are other people involved who have put in a lot of work
> (directional/advisement/guidance... not coding) who would not benefit
> nearly as much as I would from it being open source.
>
> Also, as a company we have to evaluate what the best option is
> financially. We are currently a pretty low-budget operation, and if we
> release it what will prevent someone with deep pockets to come along, take
> it, and then dump tons of money into marketing it under a different brand
> name? I'm sure we could devise a license that would prevent such an
> occurrence, but it would have to be a pretty restrictive license, which
> would in itself limit the interest in the software.
I am in a similar situation with my company. Our main business is
building small to medium scale web sites for small businesses. Our
customers can build and maintain their websites and email accounts through
a web frontend (ie choosing a template, WYSIWYG editor, menu
builder, etc...). Everything we do is written in perl with a MySQL or
PostgreSQL backend, and I am in the process of mod_perl'ifying most of it.
Any new custom jobs that we do are also done in mod_perl. To simplify our
development, and to keep our development and design teams separate we have
developed a bunch of modules that simplify life in general (a template
engine, a DBI wrapper, a form handler, etc...).
We have talked about throwing our modules and apps out to the masses, but
like most other companies, we are faced with competition. A big part of
our marketing push is the easy-to-use tools for managing your website.
If we give these tools away to our compeditors, then we loose our
advantage in the marketplace.
Perhaps once our position is more stable in the market we will be able to
contribute back to the community with the work we have done...
--
Cees Hek
SiteSuite Corporation
cees@sitesuite.net
Re: an unusual [job request] + taking mod_perl to the commercial
world
Posted by Adi Fairbank <ad...@seneca.certsite.com>.
On Sat, 28 Apr 2001, Gunther Birznieks wrote:
[text cut]
>
> So for Adi -- I think the messaging server is great and I am sure it is
> cool and works well. And I am sure there are people on this list who will
> benefit. But unless your company makes the healthcare system itself open
> source, then it's another application that we don't have to make people
> interested in using mod_perl from the application side.
>
[text cut]
>
> The problem is that most company's that spend the time to write an app
> based on Java close-source that app. The same thing is true of the mod_perl
> world if things like Adi's healthcare system or SmartWorker's OpenDesk
> remain closed systems. I know that they consider it their business model to
> have to keep these closed source. But it also means less applications on
> top of mod_perl to entice the masses to it.
>
Thanks Gunther,
We actually have discussed releasing our entire application open source.
I personally would love to release it, being the chief architect, but
there are other people involved who have put in a lot of work
(directional/advisement/guidance... not coding) who would not benefit
nearly as much as I would from it being open source.
Also, as a company we have to evaluate what the best option is
financially. We are currently a pretty low-budget operation, and if we
release it what will prevent someone with deep pockets to come along, take
it, and then dump tons of money into marketing it under a different brand
name? I'm sure we could devise a license that would prevent such an
occurrence, but it would have to be a pretty restrictive license, which
would in itself limit the interest in the software.
I know releasing it open source would get plenty of interest from
developers, but would it generate interest from potential customers? We
concluded that it probably wouldn't make much difference since healthcare
is in general way behind the technology curve. Most people in healthcare
haven't even heard of Linux yet. (that may be a bit of an exaggeration,
but not too much)
In any case, we are still planning on releasing it eventually - to allow
it to grow beyond what our in-house development crew is capable of. We
really are just waiting to gain some significant market share and brand
recognition in order to make it more difficult for someone to take our
software and compete with us directly. We also need to rewrite parts of
it and document it. I personally would be embarassed if the open source
community saw certain parts of it. :-)
Any comments are much appreciated.
Cheers,
-Adi
Re: an unusual [job request] + taking mod_perl to the commercial
world
Posted by Matt Sergeant <ma...@sergeant.org>.
On Sat, 28 Apr 2001, Gunther Birznieks wrote:
> As I think I mentioned, it's great that the people like you on this list
> have a passion for delivering cool software.
>
> I may have missed the intent of these two posts (micropayment and messaging
> engines), but unfortunately, I don't really consider either of these items
> to be application-level items. I consider them infrastructure.
>
> eg it's nice that SmartWorker (as a toolkit) is open source, but opendesk
> is closed source. And it's the applications (ironically) in opendesk that
> make smart worker worth taking a look at. But it cripples (hope I don't
> upset anyone) SmartWorker's marketing to have opendesk closed source
> because people prefer downloading apps and then they learn about the
> framework it was developed in. Rarely is it the other way around.
>
> People rarely look at toolkits like payment gateways and messaging servers
> unless there is an application that fits their needs that they can use
> which happens to use these backend components.
Actually there's an exception to this rule. Look at Zope.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\