Word association is an interesting game. Basically, I say a word and you the first thing which pops into your mind:
Well, that's how you hope this might go. For many outside the Perl community, you might hear "dead" instead of "rocks". By allowing the blogosphere to define the Perl brand, we've put ourselves on the defensive, reacting to what others say rather than taking the brand management into our own hands. In short, "branding" Perl would be to identify a concept with Perl in the public's mind. I would like the average person to think "ubiquitous and cost-effective" when they think of Perl, but that might not be the right approach.
As part of our marketing efforts, one marketer pointed out that we're not just looking at marketing Perl or the community, we're trying to market a concept. Without a clear understanding of the brand[1] we're representing, marketing efforts can be unfocused. A particular individual who's asked not to be named did some research and came back with a branding proposal from a PR firm which specializes in creating a brand image. We pretty much shot down the proposal. Aside from spelling and grammatical errors (!), it spent a lot of time explaining how the branding would be defined in terms of how the Perl community thinks it should be defined.
I did not find a single item in the proposal which related to connecting the brand to what consumers want. If we rushed off to brand Perl as the "data munger's dream" but everyone wants "dependable and fast", we've pushed ourselves into a niche. What's worse, we might be perceived as useless for anything outside of our brand association.
In short, if you want to hire anyone to do branding, make sure they can connect what you can deliver with what people want.
Back to the drawing board for us.
1. It's worth noting that a brand doesn't pigeonhole you if done correctly. Many general purpose programming languages (Java, for example) have done a great job at branding without people thinking they're one-trick ponies.
Sad to hear that the branding exercise turned out so poorly (though not entirely surprising). I suspect that any attempt to work with a marketing agency that is not focused on marketing technology is going to result in something similar.
There's also lots to be said about the "pinko marketing" approach, for brands that have such a huge user community: i.e., marketing from the bottom-up vs. top-down.
I jotted down some thinking on the "branding Perl" question in a recent blog post: "Getting to the root of Perl's perception problems." As a consultant, and a technologist, I still believe that the approach outlined there is part of the answer for moving forward on these question.
Specifically, not just thinking about the One True Message(tm) for Perl, but -- more importantly -- thinking about the myriad truths that apply in different situations, and for different audiences. Also, with some reflection on the topic, I also believe that the Perl community could achieve some successful pro-active (not defensive) promotion by seeding some "open-source marketing kernels" and letting the community do the rest. Think of how the TIMTOWTDI spread effortlessly, and pro-actively.
Ideally, rather than over-branding, the kernel would be simple, flexible, and adaptable and would have ways for the community to continue to evolve it by contributing back. What if we could pro-actively develop Perl's brand in a way that is similar to how the actual language is developed -- therein lies the key.
Phillip.
Re:Additional thoughts on "branding" Perl
Ovid on 2009-09-28T19:00:57
I really like the post you linked to and some of the responses. I can agree with the message. Back when I sold cars, I learned a couple of interesting things. First, selling Japanese cars was hard because I didn't give a damn about cars. Customers came in armed with invoice price lists, Consumer Reports, news articles, etc. They really were focused on value. When I switched to selling American cars, many people came in to "buy American" and while the cars were demonstrably a lesser value -- 3 versus 5 year warranties, poorer gas mileage, higher defect rather -- many customers were buying a brand and value for money was a secondary consideration (more than once people told me "I ain't gonna buy none of that Jap shit"). I found selling American cars was much easier.
I also discovered that customers who paid the most for their cars were the happiest. They were sold on value, not on price. That's why a lot of commercial products are more widely deployed than free, open-source products. Though my first-hand experience with Bricolage showed that the added value of the commercial products was negligible (negative in some cases), people still perceived that commercial products must have a higher value. This is one issue that Perl is not likely to overcome directly.
And the "creative power" message from raiph sounded great, but if coupled with TIMTOWTDI, I wonder if it would backfire. TIMTOWTDI clearly helps individual programmers, but it can backfire tremendously in large-scale environments when 20 products are doing identical things in 20 different ways. This is one of the obstacles we're struggling with at the BBC right now. If we did not have a reputation for TIMTOWTDI, I think "creative power" would be fantastic. Right now, I'm hesitant, but still like it. Might be a fantastic tag line.
Re:Additional thoughts on "branding" Perl
phillipadsmith on 2009-09-28T22:15:22
I must admit, I also like the "Creative power" messaging also. For me it's reminiscent of "Making Easy Things Easy and Hard Things Possible" -- which has always resonated for me when thinking about Perl's strengths.
But that "creative power" message is probably aimed squarely at developers, and not business executives. And that's where I was going in the post referenced above: There could be -- and probably should be -- different messaging to each potential audience. For developers, Perl is "creative power." For executives, Perl is "ubiquitous and cost-effective." For learners, "Perl makes easy things easy, and hard things possible." And so on...
I get a sense though that many Perl folks feel that the most important audience is the one you reference: big IT buyers. People at companies that manage large IT budgets and want to buy something secure and reliable. For them, commercial software may appear to have more value at first. However, once they get past that thinking and start to look at the free software options, that's where Perl is experiencing its biggest challenge. Specifically, the relative lack of shiny example projects (or the lack of profile that existing projects get in the Perl community).
I'm not certain that the myth of TIMTOWTDI is even that relevant anymore. When I look at "Modern Perl," or idle in certain modern Perl Web Framework IRC channels, it becomes pretty clear that there are some consistently and strongly advised approaches to most challenges. Add to that PBP, Perl::Critic, and Perltidy, and you've got a fairly well-defined set of design patterns to apply to almost any problem.
Perhaps it's time to shift the focus from the Perl we've had in the past (the TIMTOWTDI Perl), to the Perl we have now: creative power that is readable, scalable, maintainable, test-driven, etc.
