Marketing the Entire Box (including the wrapper)

For a long while now I've been wondering about some observations I've made of Perl, Ruby, Python and PHP in marketing terms. I'm going to discuss them here in detail, and I hope it will gain us some insight into better marketing understanding or at least not bore anyone.

I've understood through the years that projects with beautiful websites have a better chance of getting picked up by users (even when the project itself is purely command-line) and definitely gives much more credit to the encompassing layer (like the programming language itself).

I've also noticed that a rather large portion of Ruby-related projects have very beautiful websites. You might have noticed this yourself as well. I tried to understand how this situation occurred and had a few discussions at $work with people whose opinion I appreciate, one being a Python and PHP programmer (or, as I like to see him, a programmer who knows PHP) and the other being a Ruby, RoR and overall Javascript whiz.

At first, my thoughts were that most Ruby programmers major in Rails, so they're into web, while the major web frameworks in Perl (Jifty, Catalyst, Mojo, Mojolicious, Mojolicious::Lite, Dancer, CGI::Application, etc.) only flowered in recent years, which could lend the thought that most Perl programmers aren't web-oriented or web-aware. I mean this obviously as "aware" in higher extent than most users. As mst eloquently expressed, we're still into IRC (me included, of course).

Quickly that theory was squashed when I entered the Django website. For a web framework, it is horrible. Especially for a web framework that speaks of cleanliness. The website design is horrendous. Same goes for the HAML website. PHP as a very successful web-oriented language shows interesting results. Most PHP programs/scripts come in various index sites (much like oldschool PERL scripts), few PHP frameworks have websites and fewer have beautiful websites. Most of them are awful. Frontpage awful.

So apparently, dealing with web doesn't mean you create beautiful websites. Yeah, I guess anyone could say that, but to put it in better words: knowing web doesn't mean you do web. So what is the reason it is almost given that a Ruby project (as small as it might be) will have a website, and it will be beautiful?

A thought that formed rapidly through the conversations was that Ruby programmers see the marketing as relating to not just the product, but its wrapper. That is, that many Ruby programmers understand at a very core level (more than most programmers - at least me) that the website which shows the project is the actual wrapper of the project and is just as important, if not more so. When I thought of a "nice wrapper", I just thought of a detailed POD and --help output. Obviously, this isn't the case for many Ruby programmers. Those Ruby programmers think "I cannot ship this application without wrapping it nicely, it is just incomplete."

I began to see the major difference between many Perl programmers and many Ruby programmers. I haven't ever written a website for a project I worked on. Evidently, perhaps many of them don't merit a website of their own, but perhaps some of them do! One of the prime examples for this, IMHO, is LessCSS which has a beautiful website for a rather simple filter, which could definitely be accomplished just as well in other languages such as Perl. I thought how simple it would be to write a version in Perl, stepped up to CPAN and here is CSS::LESSp and Apache2::Filter::LESS::CSS. I have to say that CPAN is indeed comfortable for me, but as a design, it isn't very attractive or compelling. CPAN is an index site, not a front page wrapper for your project.

When I see the LessCSS website, I'm seeing beauty which attracts me not only to LessCSS (which I don't really have any use for right now), but also (and this is key) to Ruby itself.

Returning to my quest, I had already sat down with our resident Ruby/Rails expert and a cup of tea and flux-seeds crackers. What I still wondered about was how can a Rails programmer know Ruby, Rails, Javascript (usually) and web design all at once and on such a high level for each to produce such beautiful websites. It's definitely not common, or is it?

We've laid the foundation that many programmers use prepared (sorry, there is no "pre-prepared" in English) templates and layouts, or hire an actual professional web designer. Hiring a web designer is not a cheap cost. Why are these people spending good sums of money on professional web designers to create (usually static) websites for such small programs? I couldn't understand it.

Then he mentioned some conventions he went to. When someone shows her peers and future employers projects she has done, the first impression is on the looks of things, not the sound or ability of them. If it's beautiful, she got to first base. If it works much better, but it doesn't even have a face, it stands much less chance of even getting a shot. This is what I was missing.

Marketing my project is not just marketing a code that does a task, it's marketing me!

Dancer doesn't just market a small web framework, it markets Perl and Plack (the encompassing technologies), but also the developer(s) of Dancer. Same goes for Catalyst, same goes for Moose and KiokuDB and Module::Starter and Test::More and on and on and on.

A response I'm expecting is "well, obviously!" and my answer would be the same, I do know it, however Understanding it is much more important than knowing it. To understand it means to write a website for whatever project I have done which I think can elevate me, and which I think can elevate Perl, or some other encompassing technology (like Moose or Dancer).

This morning I imagined having a space for project websites. Actual beautiful static website for each Perl project. I don't have the time to set up an infrastructure for hosting and all that. However, I did purchase PerlProjects.net and I will be giving NS hosting for free to anyone who wants to set up a website at <YourProject>.PerlProjects.net, no matter how small. Also, I want to set up a main site at PerlProjects.net which will be an index of... Perl Projects.

I do believe that having individual beautiful websites for projects (even the small or relatively exclusive ones) will help market Perl better, and any technology (of Perl or not) you're using in your project. This will help boost interest and consequently the number of programmers who know Perl will go up and of course job offerings will follow. If we can present an image of "Perl projects come in beautiful wrappers", we can present an image of "Perl is beautiful", and that is what we should strive for - at least in marketing terms.

If you feel like helping with PerlProjects.net (design, design, design) or want your own subdomain and free NS hosting, let me know!

6 Comments

Very cool. I like the initiative.

I think the Ruby gang are a bit stronger on the design side - that is part of their culture. They have Macs, we have linux, they have nice designs, we have working code. (I'm being glib. :] )

How about starting an effort to beautify CPAN itself? Usually, the 'goto' for perl modules and stuff you can use is CPAN. For people who aren't familiar with CPAN, other sites (Google? PM?) eventually leads them to it.

perl.org (and hence perldoc) received a recent design overhaul. I'm thinking CPAN could use some of that too. All the documentation we ever need (well, most cases) for perl modules is already available, its just that we need to present it in a prettier and more appealing way. Maybe even allow Registered modules to have their own domain name?

Improve on what we have instead of starting a new location to store projects?

Historically the Ruby community did not have anything even remotely resembling CPAN. If someone wrote a great library there was no good way to share it apart from building their own web site.

In the Perl world, simply uploading a tarball to CPAN automatically gives you an inoffensive-looking web page with links to: nicely formatted documentation pages, downloads, bug tracker, test results, reviews, changelogs, cross references. Having these things presented in a consistent way across all CPAN distributions is surely easier on the user than having every project do its own thing.

I'm not saying that we can't or shouldn't improve on what we have, but a bias towards functional before pretty doesn't seem a bad thing to me.

Thank you for this initiative!

First sight impression is often underestimated, if we like this fact or not.
I now appreciate CPAN very much as I have learned how to use it efficiently. But it was not love at first sight.

Leave a comment

About Sawyer X

user-pic Gots to do the bloggingz