Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-29 Thread Matt Sergeant

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 commercialworld

2001-04-29 Thread Adi Fairbank



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 commercialworld

2001-04-29 Thread Cees Hek

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
[EMAIL PROTECTED]





Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-28 Thread adi


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




Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-28 Thread Matt Sergeant

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  **
 \\//
 //\\
//  \\




Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-28 Thread Matt Sergeant

On Sat, 28 Apr 2001, Bakki Kudva wrote:

 On Sat, 28 Apr 2001 09:14:10 +0100 (BST)
 Matt Sergeant [EMAIL PROTECTED] 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 commercialworld

2001-04-27 Thread Stas Bekman

 I think there are two paths... mod_perl needs more market-awareness... it
 needs a PR and marketing company.. then companies will start using it, then
 there will be more dreams jobs like you described.. simple fact is, I
 couldn't name more then 3 companies in my area who use it, and I never
 expect to do work with it again.

that's the long term path, we won't survive without a support from the
outside. It's hard to have a garage kind of a startup these days.

 Other path--- start your own company who has some product or web based
 service which uses mod_perl as their platform of choice.. market it, and
 sell it.. takes capital, but..nothing the collective efforts of an open
 source community couldn't do... gotta have that idea though..

Hey, we have a product -- mod_perl. All we need is to nicely pack it,
start selling it, support it and put the money back into mod_perl RD.
Most of the big companies are still reluctant to accept the fact that
something can be available for free. They are ready to pay for it, as long
as you provide a support.

_
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/





Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-27 Thread Doug MacEachern

On Sat, 28 Apr 2001, Stas Bekman wrote:
 
 Hey, we have a product -- mod_perl. All we need is to nicely pack it,
 start selling it, support it and put the money back into mod_perl RD.

Covalent does this already.  all of the bundle products include
mod_perl, and anybody can buy support packages where support for mod_perl
is covered.  Covalent also puts a great deal of resources back into
mod_perl RD (me :)  not to say it couldn't be taken a few steps
further, bundling a Perl distribution and useful CPAN modules along with
it.  and of course, Covalent is the only company that can offer such a
product.





Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-27 Thread Stas Bekman

On Fri, 27 Apr 2001, Doug MacEachern wrote:

 On Sat, 28 Apr 2001, Stas Bekman wrote:

  Hey, we have a product -- mod_perl. All we need is to nicely pack it,
  start selling it, support it and put the money back into mod_perl RD.

 Covalent does this already.  all of the bundle products include
 mod_perl, and anybody can buy support packages where support for mod_perl
 is covered.

Oh, I didn't know that [Covalent sells mod_perl]. I guess that's because
I'm not on the buyer side. Does it announce this fact? So why don't we
have a link to Covalent from the perl.apache.org site? I think this is
very essential for mod_perl to tell people that there are companies which
sell mod_perl and provide a support! I think Covalent won't mind to have a
such a link too.

 Covalent also puts a great deal of resources back into
 mod_perl RD (me :)

This fact is well known and appreciated :) Thanks to Randy and other
Covalent folks!!!

 not to say it couldn't be taken a few steps further, bundling a Perl
 distribution and useful CPAN modules along with it.  and of course,
 Covalent is the only company that can offer such a product.

You mean Covalent is the only company that can offer such a product now.
It doesn't mean that some other company will provide a better packaging
and sell it too, right?

IBM is selling their WebSphere, which is essentially pretty much a
slightly modified Apache server. I'm sure they can sell mod_perl too. I
think having someone like IBM backing up mod_perl will give mod_perl a
huge boost in product recognition. Think about IBM's PR capabilities.

So do other big companies. We just need to find a way to make them want to
do that. That's why I thought that may be some of the employees from those
companies are listening now, take notes, talk to their managers, get the
lead, hire more mod_perl programmers, and make the world a better place to
live.

_
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/





Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-27 Thread Doug MacEachern

On Sat, 28 Apr 2001, Stas Bekman wrote:
 
 Oh, I didn't know that [Covalent sells mod_perl]. I guess that's because
 I'm not on the buyer side. Does it announce this fact? So why don't we
 have a link to Covalent from the perl.apache.org site? I think this is
 very essential for mod_perl to tell people that there are companies which
 sell mod_perl and provide a support! I think Covalent won't mind to have a
 such a link too.

yes, i've been meaning to put a link on perl.apache.org
 
  not to say it couldn't be taken a few steps further, bundling a Perl
  distribution and useful CPAN modules along with it.  and of course,
  Covalent is the only company that can offer such a product.
 
 You mean Covalent is the only company that can offer such a product now.
 It doesn't mean that some other company will provide a better packaging
 and sell it too, right?

whoops, that was supposed to say 'is _not_ the only'.  i will say again
what i meant: and of course, Covalent is not the only company that can
offer such a product.





Re: an unusual [job request] + taking mod_perl to the commercialworld

2001-04-27 Thread Jeffrey W. Baker



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.

-jwb