Re: an unusual [job request] + taking mod_perl to the commercialworld
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
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
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. -- /||** 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
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/ -- /||** 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
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. -- /||** 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
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
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
Re: an unusual [job request] + taking mod_perl to the commercialworld
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
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 R&D. > > 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 "R&D" (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
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 R&D. 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 "R&D" (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
> 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 R&D. 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/
