The best way to create demand for Perl is to have desirable, plug-in extensible applications out there written in Perl.
PHP is an extremely problematic language, but its community excelled at creating and supporting applications written in it. End users settled on PHP apps, creating a market for talent that went on to more than triple Perl's demand for programmers: http://langpop.com/.
Only a few years ago, the WebGUI content management system used to power huge amounts of the Web and create jobs for hundreds of Perl programmers. WebGUI was the number one most popular mod_perl application for many years, but like Zappos.com, Walmart.com or the original Amazon.com (http://oreilly.com/pub/a/oreilly/perl/news/amazon_0100.html), the fact that it was written in Perl was kind of a secret.
Mitsubishi, Brunswick, large .gov sites including america.gov, and many corporate sites were powered by WebGUI. http://www.cmsmatrix.org/ and similar sites still give WebGUI top ranking in terms of power, extensibility, and professionalism.
While frameworks like Catalyst were a huge step forward for Perl, we've still one step behind. When we were still doing CGI, PHP had an easy to use, easy to install Apache mod. By the time Perl was catching up with Ruby on Rails with things like Catalyst, most new sites were being built on of CMSes, and for good reason. A CMS gives you, out of the box, most of what any new site needs: a user system, verification, password recovery, user administration, discussion boards, photo galleries, and a pile of other useful things.
Advanced Perl programmers may prefer to start with a framework, but novices almost always start with a CMS and then learn how to customize it. For most applications, there's already a plugin (https://wordpress.org/plugins/) that gets you 90% of the way there. You can launch your new custom job/resume board in an evening, such as http://coinality.com did. WebGUI's Bazaar is competitive: http://www.webgui.org/addons.
WordPress is hard to extend and has a history of security problems. WebGUI has a rabid following among people who have used Dupal, WordPress, and a host of other systems, and declared it to be the most powerful, most extensible, most sane, all around best system... and it's written in Perl.
Here's the problem. After paying a dedicated programmer to work on the next version for over a year, Plain Black Corp apparently decided to focus on other things. Version 8 got left undone as an alpha. 7 is still being maintained, but 8 was a massive modernization effort that reworked core to use Moose, Plack, Try::Tiny, and cleaned things up.
Thanks to fantastic test suite coverage, the API and core of 8 work well, but the rewritten admin needs attention. Also, WebGUI has traditionally targeted large companies, so the difficult install process was not a major liability. To compete, installation has to be dead simple. The themes are not adequately modern (which is to say they look a little outdated).
I plan to get wG8 out of alpha, move it to a community development model, finish the installer I created for it and OSX support, and work with designers to create a modernized theme.
While I was previously employed by Plain Black Corp, this Kickstarter was not reviewed or endorsed by them. My motivation is simply loyalty to the friends I made providing community support and hacking on this thing with the denizens of #webgui and at WebGUI Users Conferences, a desire to see something awesome finished, and to create the demand I want to see for Perl programmers.
If you want to help with the code, fork http://github.com/AlliumCepa/webgui and see the tickets at http://webgui.org/8. My installer is at https://gist.github.com/scrottie/2973558 right now. I hope to merge it in.
I'm on Twitter! Follow me at http://twitter.com/scrottie. I've been showing off code examples of extensions such as a two player Battleship game I did for a presention on extending wG, danny_mk's video of my curses based installer, and other goodies.
If you're curious what wG offers, check out https://www.webgui.org/community/webgui-user-guides/content-managers-guide and https://www.webgui.org/user-guides/webgui-administrators-guide.
Risks and challenges
WebGUI itself was released under the GPL, so rights to code are not a problem, but, as much as I'd like to avoid it, the project may become forked if Plain Black decides they do not want to take my changes upstream. This hasn't been a problem in the past. Trademarks may also come in to play in which case the community would have to work together to settle on a name for the fork. WebGUI isn't the greatest name ever (maybe we need a code name?), but I'd prefer not to see things faction.Learn about accountability on Kickstarter
wG is quite popular in the real world. It had its own conference that drew hundreds each year. Large governmental sites and corporate sites used or use it. It was developed to maturity for real world use by an entire staff of people. The internals aren't bad, and it has hard to get right features such as configurable approval workflows, groups-of-group permissions, and an interactive visual survey builder. Entire other commercial Perl products are built on top of it.
Each page is highly dynamic. A PageLayout asset (what you normally pull up using a URL) can contain any number of other assets, each of which does things like show the most recently posted images to a forum, the most recent messages, bug tickets, and so on. Each asset has a customized appearance. Getting used for very busy sites such as some .gov sites, performance has been more important than DBIx::Class. wG also already provides an ORM abstraction. See http://slowass.net/~scott/tmp/Battleship.pm.txt for an example. Attributes defined with Moose automatically get restored from the database and persisted to the database at the start/end of the request. When creating new assets, you seldom have to think about the database at all, but creators of new types of assets certainly could bring in Moose, and maybe future versions of wG will add it to the core.
Support this project
- (30 days)