Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Building a Perl based business

by johnnywang (Priest)
on Feb 02, 2006 at 03:03 UTC ( #527221=perlmeditation: print w/replies, xml ) Need Help??

Recently I've been reading some discussions on the JoeOnSoftware's Micro-ISV section, and started to think about products and businesses. From many discussions here on PM, and my personal experience, it looks like most Perl programmers work for a company, consult or run a website. Are there people selling Perl based products? I'm using the term "prodcuts" as something you develope and can sell again and again, packaged or not. What is the career path for a Perl programmer? I always feel employed/consulting is not a scalable business proposition. What are some examples of successful Perl based businesses besides consulting and web sites?

Replies are listed 'Best First'.
Re: Building a Perl based business
by dragonchild (Archbishop) on Feb 02, 2006 at 03:51 UTC
    Part of the issue with selling a Perl-based product is that Perl is inherently opensource. While this doesn't always mean "free as in beer", it tends to be that way, culturally.

    I work for a very small company that builds and customizes a reporting web application as part of a package that another large firm sells. It's currently written in Perl, so it would be a Perl product that's sold again and again.

    What's special about our product is that it's not a product, per se. It's more of a service that happens to be written in Perl. In other words, we're a consulting firm in disguise. And, frankly, that's how you're going to have to think of yourself. While you may be able to ride the gravy train of a certain product for a few years, you're not going to build your business unless you're a domain expert first and a producer second.

    There's a lot of really bad programmers out there*, but it's not like they have their abilities tattooed on their foreheads. You need to have all the credentials in the world in order to be a recognized domain expert. For example, Stonehenge is a well-known Perl consulting firm. Why? Because Randal Schwartz and brian_d_foy are there! If you want to hire someone, you want to go with the best you can afford. Stonehenge has two of the TOP names in the Perl world. In other words, you have to compete with that if you want to grow your business.

    Now, it's not all doom-and-gloom. You can go away from the Perl-centric idea and just build a good web-based product to market. For example, that's what Basecamp does. I bet you can't figure out what language they're using. I'll give you a hint - it's not Perl.

    *: According to some estimates, the top 1% of the world's programmers are more efficient than the other 99% combined. Figuring out which side of that line you fall on is tough. But, the nice thing is that it's easy to go from one side to the other, if you're willing to devote yourself to it.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      I know that Basecamp is in ruby, in fact RoR. I guess the same question applies to the other languages: php, python, ruby. Websites are great because the language is hidden, and there are lots of very successful ones out there (not to mention google/ebay/yahoo/amazon). But is that the only way "out" for Perl(php/python/ruby) programmers, besides selling by the hour?
        Here's the issue - what's the greatest strength of Perl(PHP/Python/Ruby)? It's the ability to write something and have it (almost) truly be cross-platform, not have to worry about compilation/linking, and 90% of every application is already written for you (at least in Perl). This ease comes with a price, but most scripters consider that price to be worthwhile. We'll discuss that price in a second.

        What does it take for an application to succeed in the marketplace that you're describing? Well, it needs to be installable on Windows in the same fashion that Firefox is installable on Windows. You download something, double-click on something, click "Yes" a few times, double-click on something else and you're up and running.

        This takes a lot of infrastructure on the Windows machine. While it's all possible to do with Perl, it makes a lot more sense to do it in a language that already has all that infrastructure in place, like C# or Java. Why compete in a space that's already saturated?

        Instead, it's much better to work within a space that doesn't have that cost of entry, like rich web applications. Have you used Basecamp? It's a damn slick application - I like it ... a lot.

        As for "only way out" ... I make a fine living doing exactly what you're describing, and so does nearly every other serious Perl/Python/Ruby developer. Just because it's not flashy doesn't mean it's not a good thing to do.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      According to some estimates, the top 1% of the world's programmers are more efficient than the other 99% combined.

      I wouldn't be at all surpised if that statement were true, but I also wouldn't be surprised if the top 5%-1% had a combined efficincy greater than the top 1%. The bottom end of the scale has negative efficiency.
Re: Building a Perl based business
by brian_d_foy (Abbot) on Feb 02, 2006 at 06:02 UTC

    If you're calling yourself a "Perl programmer", you're already limiting your career path. Chad Fowler tells you all about this in his recent Perlcast interview where he says that you should make yourself useful in a certain problem area regardless of the tools. Be a programmer who knows Perl along with everything else you know, but also know other things. Don't get tied up just being a programmer either.

    Have you looked at Bricolage, RT, or Movable Type? Those are all Perl products. Don't fool yourself into thinking that retail scales better than consulting. More revenue doesn't mean more profit or more return for your investment.

    brian d foy <>
    Subscribe to The Perl Review
Re: Building a Perl based business
by rhesa (Vicar) on Feb 02, 2006 at 06:11 UTC
    The big question I'd like to ask you is what kind of market you envision for your shrink-wrapped product.

    You have a couple of options:

    • Retail: needs a flashy GUI more than anything; not Perl's strongest point. Other than that, for retail it doesn't matter what language you write it in. Just realise that it's very, very hard to get on the shelves. And even harder to get a decent margin. Expect big up-front costs, and lots of risk, and a big advertisement budget. Republishing is an alternative strategy in this market, but expect to be sucked dry. If you make it in, and have something popular, you can make a decent living by counting on the volume of the market. You'll likely need to go global.
    • Small business: also a big market in terms of volume. Won't pay unless it's dead simple to install and maintain, or it's customised to their specific needs, or it's a commodity (like Windows or Office).
    • Enterprise: lots of cash, lots of requirements. I don't think this is a market where you can sell anything off-the-shelf.

    In my experience, the consumer market isn't worth the pain. Support alone could kill you. I haven't directly done anything with big enterprises, but I suspect it's not feasible to get a foot in the door without expensive consultants and an impressive portfolio of buzzwords.

    In the end, I think the small business segment is the most exciting: there are plenty opportunities for small shops selling intranets, web sites and so on. You'll be customizing your base product for each client, which technically makes you a consultant, but there's no reason why you shouldn't base this on a common framework that you develop for your particular niche. It gives you at least three income streams:

    1. you sell your application framework
    2. you bill your customizations by the hour
    3. you sell a support contract
    This is a path that you could grow into a big shop, of course, but then your sales force will become the dominant part of the company.

    I don't think there's anything wrong with developing web sites. You can deploy those skills with equal ease into selling intranets, and I think those are just software like any other, but with a lot of management benefits over desktop applications. If you view the web browser as your GUI toolkit, perl comes out very, very strong.

      1. you sell your application framework

      Could you please expand on how to implement this point? That is, do you write up a license agreement, and simply license your framework to each customer while maintaining full copyright (including keeping copyright on customizations any given client requested)?

Re: Building a Perl based business
by robharper (Pilgrim) on Feb 02, 2006 at 15:42 UTC

    I always feel employed/consulting is not a scalable business proposition.

    You're right to a large extent, but this touches on something that I always wonder about: why is the (western) world so obsessed with growth and scaling? Everyone seems to be looking for "fire & forget" businesses that they can set up then sit back while the product yields money. It's probably just the way I am wired, but I would rather earn my money by providing a service and get the benefits of becoming more efficient at that service, rather than selling "product".

    Sorry, I'm probably off-topic here, and I'm certainly not answering your question, but I needed to get that off my chest.

      I think we're all concerned with mortality, robharper. Not just our own, but the continued applicability of our skillsets. Perhaps we do concentrate too much on 'fire and forget', but in the cold, cruel, "real" world, nothing is ever f&f, so building with that as a goal at least gives you a chance.

      I'll leave you with a thought to mull over: by the time you're fifty, like I'll be in three months, just about everything (technical) that you've learned, except the wisdom you've gained the hard way, will be completely obsolete, and change will be happening at such a pace that keeping your skill sets applicable will be daunting. If you _haven't_ got something that provides a sustaining chunk of money by that time, you're going to be in big trouble. In rare cases, like Y2K or COBOL consulting, you can make tasty gravy with no-longer-current skills, but those are rare cases.

      OTOH, business skills are a sustainable skillset with continuing market value. Whether you use them for your own profit, or use them in service to a larger organization, they're a lot more transportable than programming or engineering skills. In my own company, the bills are paid by products we've already built as we work on next year's. In my day job, it's mostly my team leadership that makes a difference. In both cases, skill in leveraging other people is the key to success, far more than the elegant web apps I personally create.

      I personally would like to retire in a few more years, long before I'm 65. 401K's aside, having a business with enough sustained revenue and growth to sell is really the only way to do that. I may be too old by that time to really push the Ferrari I'm going to buy, but I sure as heck am going to enjoy it. :D

      Don Wilde
      "There's more than one level to any answer."

      I like to think of this as I'm in this s**t for life. Build a service, build a product based out of a service, fine tune my services to sell my product better. And so on! (Horrible example, please excuse)


        Probably the years of selling software as a product are gone. Actualy, few have really made money with that. Most in the last 40 years lived selling services and administrating legacy systems.

        Even Microsoft Iīm sure they are concerned about how to sell Windows as a service, not as a product (they are developing a MSOffice version to be sold as service already, OpenOffice/Google is going this way too). Oracle database is gone, Pg/MySQL is out there, thats why they are buying companies that sell more services than software, like ERP ones, Peopleware, and developing service based applications. Think of Google: does they seel anything at all?

        Source-code seeing or decompile and pirates are problem for everybody. And even if they were not, by the time you release a new version of something you have been developing for years, there are plenty os competitors in the same niche.

        Companies like Basecamp, Google, Yahoo and many other Web 2.0 enabled simply donīt care about the language - and so donīt the user. In all the companies, the software is only the way to guve the final user the real revenue - information faster and better, collaboration, etc.

        Diego de Lima
Re: Building a Perl based business
by samizdat (Vicar) on Feb 02, 2006 at 15:22 UTC
    I believe the key to having a career path that 'scales', i.e., survives both outsourcing and old age, is indeed to incorporate business in your skill set. Whether you do it by creating a SaaS "website" or by managing other programmers, having a business (i.e. product deployment, sales, and p&l) mentality is really important. While I'm a good programmer, I'm probably not in the 1% spoken of elsewhere. I've chosen to take the hard lumps involved in learning to make teams work efficiently to build products which enable companies to become more profitable. IBM has a phrase "Business Process Transformational Services" that Paul Horn (Director of IBM Research) spoke of, and that's the arena where we've been working. There's a huge difference between SaaS and 'a website', and Perl (or Ruby or PHP or even Java) can be the engine that differentiates you from the rest. What matters is the creation of a business model and service in that web system that serves a real need better than the existing tools. I spent two years (with my programmers and about $300K) on an abortive content-organizing and publishing system that nobody wanted. Fortuanately, our previous product, an online web-hiring system, _has_ grown into a successful niche builder, so I have been able to recover from my business non-sensical wild goose chase.

    Don Wilde
    "There's more than one level to any answer."
Re: Building a Perl based business
by TedPride (Priest) on Feb 02, 2006 at 11:57 UTC
    The problem is that Perl applications just aren't easy to standardize and package. Either you include all necessary modules with your application, in which case module updates are a pain, or you rely on the user to have all necessary modules installed already, in which case module updates may break your application (since there's no guarantee the user won't install a newer version with different features).

    I personally think Perl is best suited to quick and dirty custom programming. For instance, I wrote a script yesterday to merge the results from a four-part poll, remove extreme results, and tabulate votes per person and votes per item. The script took maybe an hour to write, but writing the same script in any other language would have taken significantly longer, and processing the data by hand would have taken ages. Perl to the rescue!

      The module CPAN::DistroBuilder does exactly what you said about packing the modules version that you need. PAR also could help in this issue, as well.

      Alceu Rodrigues de Freitas Junior
      "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill
      That's not really true. It's trivial to take an application and bundle it with all of the required modules, even if they require compilation. As for module updates being a pain, untrue, at least compared to updating the program itself. You're going to have to ship updates for it, why not ship updates for the modules? Not too hard. And lets not forget just how much time you're saving by utilizing all these modules.
      This new article on seems helpful re standardizing and packaging of Windows distributions; I'm not sure it addresses your concerns about module updates though.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://527221]
Approved by McDarren
Front-paged by McDarren
[MidLifeXis]: On the back end, however, that doesn't mean that i have to use that value to indicate "undefined", no matter how much he thinks I should.
[stonecolddevin]: hey MidLifeXis, all
[MidLifeXis]: o/
[GotToBTru]: greets

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (7)
As of 2017-01-20 19:20 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (176 votes). Check out past polls.