From a business continuity point of view, such is called a "single point of failure".

Coding a custom CMS in any other language or even making a site within the framework of any of the more popular applications, will not alleviate this fear: you will still be the only one who knows what makes the custom CMS tick.

It is not because anyone with two connected braincells codes PHP sites that they will be able to maintain some highly evolved website (even one written in PHP) with many bespoke modules and functions.

In essence, the decision your customers must take is: do they want a run-of-the-mill website straight out of one of the popular site building applications or do they want to have a site specifically tailored to suit their needs? And depending on your customer's answers, you will have to (re)position your business.

Great insights. Thanks for the head slap that I knew some Monk would provide given the nature of a post like this.

I have a feeling your customers' concern has less to do with Perl per se, but perhaps more with the fact that you use your own homegrown custom CMS.

I think that about sums it up. And your challenge of comparing a CMS off-the-shelf vs a custom one is a good one. I have showed them live demos of both Joomla and mine and I think they see the profound differences (the publishing model of all the aforementioned PHP CMS's, and mine where if you want a new page you create a new page and not an "article"). I explain that ours came out of a request from client using Joomla and it was just too complicated for the folks in their office trying to keep up the site.

So, I have a viable product, I just need to put it all in the most favorable light and position it as something simple and intuitive...and easy to maintain.

—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

When I read this type of post, generally my reaction is: if you want to follow the crowd; go ahead, no one is stopping you.

But your particular formulation of this question is somewhat different to most. You appear to be saying that your customers are telling you that you should be developing their web sites using PHP.

That leaves me with one question. If they want PHP, and you use Perl, why are they your customers?

The other thing that strikes me from your post is:

The immense popularity of PHP due to open-source systems like WordPress, Joomla, Typo3, and Drupal have raised up a new crop of PHP coders, lots of them (see the chart on my personal node). From the looks of it, you could throw a rock in any direction and hit a PHP coder.

My reaction to that--as a staunchly non-web perler--is: do you want to be a small fish in a big pond; or a big fish in a small pond?

If you believe, given your knowledge of your customer base, that you can either, earn more money; or derive more satisfaction; by coding your customers web sites using PHP, then do that. If not, don't.

There is no point in being an Edsel salesman in a Mercury marketplace.

Thanks for reading my post in the correct light. That said, I don't think they are telling me to code in particular language, they are just trying to cover their butts and not end up with an albatross, albeit very unlikely.

Thanks for your question about earning more money or finding more satisfaction. For me personally, it's not about either, but if I were to answer it truthfully I would never use PHP.

Bottom line: being a small fish has its advantages.

—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

Hi!

clients have specifically expressed a concern about the ability to maintain our/their Web apps written in Perl should my business go bust

That is -of course- a legitimate concern. However it is not perl-specific. If your system would work with PHP, the concern would be the same.

Possibilities to address this concern would be

• show that perl is a mainstream-language, nothing exotic (e.g use the Tiobe Index)
• show that there are thousands of capable perl-programmers around ... not only PHP-coders
• show that your system/code is well-documented, so anyone can take over
• prove that your system is as stable as others (after all you are in business for 10 years)

However it is not perl-specific. If your system would work with PHP, the concern would be the same.

Great point and one that some of the other responders implied. The challenge I take from your reply is to make sure my Perl is coded well, "best practices," and well documented so that another Perl coder could jump in quickly.

And thanks for the reference to the Tiobe Index, very enlightening.

—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

That is -of course- a legitimate concern. However it is not perl-specific. If your system would work with PHP, the concern would be the same.

If PHP weren't as popular, the concern might be the same.

One of the questions that a serious client is going to ask themselves is, "If the vendor goes bust and I inherit the code base (because I was smart enough to write an escrow agreement into the contract), am I going to be able to find people with sufficient skill, and at a reasonable rate, to maintain and extend the product?"

That's an easier Yes if you're dealing with Java, C#, and maybe PHP and Rails.

" ... am I doing to be able to find people with sufficient skill, and at a reasonable rate, to maintain and extend the product?"

That's an easier Yes if you're dealing with Java, C#, and maybe PHP and Rails.

What makes you think that?

Perl programmers are not that rare, nor --I think-- that expensive.

It is not because there are more Java/C#/PHP/Rails programmers that it will be any less painful to find someone willing to maitain an "inherited" codebase.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

There are many ways to answer the maintainability question - having documentation available, work with other Perl developers to back each other up on the maintenance issue, take your CMS open source, etc. Its really not that difficult to address.

However, I would guess that the real issue is not maintainability. The clients are more likely just using it as an excuse because they really just want PHP or WordPress or Joomla or something else, because of the status or coolness that they perceive would come with it. Much like the general public, businesses often act like sheep and just want to follow the trends. Or maybe they want to hire the CEO's nephew, but have to jump through the appropriate hoops first. Either way, they'll ever admit it, and you'll have to read between the lines.

Since you have already developed your own CMS, does it really make sense to scrap your investment to start over and develop it again in another language? Is it worthwhile to start back up the learning curve of a different language? The only real way to answer is to objectively evaluate the viability of your business, not by reacting to "concerns" of a few clints.

Consider the possibility that you may be looking at the business version of an x-y problem.

Most of the Perl-using companies I talked to have problems finding Perl developers. Some companies have already decided to move away from Perl as they cannot find Perl developers and they see it as a risk. Even if they cannot really replace Perl with some other language they'll prefer to start new projects in other languages.

Some people suggested to ensure business continuity even if you go bust. You might even consider releasing your CMS under and open source license. That will eliminate some of their concerns. Especially if you can build a community around the product.

Some companies care of the language just because of the hype surrounding it. I believe we will be better off by creating some more noise around Perl.

Other companies don't really care about the language and technology you use as long as they can be sure they can replace you in case they want to or in case you go bust. For them what counts is the perceived popularity of the language and the availability of programmers.