Rename Perl 5? Marketing: UR DOIN IT WRONG

Earlier this month Ovid once again raised the question: Should we rename Perl?”

As usual, the question sparked a flurry of opinions on the matter. Most of the discussion occurred in the comments of Ovid’s original post.

I’m not here to chime in on that question. Whether the name should change or should not, what it should change to, when it would happen, these questions are all closed. RJBS has said there will be no change right now and that’s that. He is driving the Perl 5 bus right now. If he says the name is not changing then that’s good enough for me. Discussion closed.

No, I’m not here to discuss that matter. I’m here to point something out:

Damn, team. That was some dismal marketing I just witnessed.

Just what exactly is the problem you’re looking to solve here? Where are the metrics to support that? Whom are you looking to convince? How will the solution be rolled out? Who’s going to do the work? What’s it going to cost? How will you know when the work is done? How will you know whether it’s working?

None of the people participating in the conversation would ever consider releasing a small patch to a CPAN module without first having a complete set of tests for it. Yet the same people seem to have no problem changing something as fundamental as the name of the language without performing some sort of market research and testing.

Despite the reputation its earned, marketing is not a crap shoot. A successful marketing or branding campaign requires just as much forethought and carefully considered execution as a good piece of software. You don’t just throw it together, put it out there and hope it does what the target audience needs. It could be impossible to recover from the damage caused by rash branding decisions.

I would welcome nothing more than more discussions about whether Perl 5 should be renamed. But I would like them to be as well researched and considered as any other change which would be made to the language itself.

Improving Perl’s New Programmer Outreach

I don’t think I’ve ever seen so much demand for programmers or programming training. In an economy that’s still recovering from the recession, the remarkably low unemployment rate among programmers plus the relatively high rate of pay is drawing ever more people to the industry.

You hear it over and over again: “I want to learn to program but need help to start.” If you search on the web you can find an abundance of “learn to program” opportunities. Most of the offline/meatspace ones use Java, Ruby or Python as the language of choice. I found none that use Perl, which I see as an opportunity the Perl community should pursue.

The availability of more beginning programming training provided in Perl would be beneficial both to the trainees and to the Perl language and community. As languages go, Perl quite easy to learn (or at least no harder than the popular alternatives). The basic programming concepts are fairly straightforward in syntax, sigils can help a neophyte to keep her data structures straight, and CPAN can enable a beginner to produce remarkably functional code in a limited amount of time. This leads to higher student confidence, since (as we’ve all experienced), creating something that works makes you feel good and want to keep learning more.

Perl, for its part, could benefit by using this training as positive propaganda to help dispel the negative brand image it’s developed and been unable to shake for all these years. Pundits and wags on Stack Overflow, reddit and elsewhere enjoy repeating the chestnuts that Perl is dead or is good only for scripting and parsing text, not for “web scale” projects. An influx of new programmers—trained on Perl and in the best practices recommended and used by modern Perl developers—would help to dispel these misconceptions, even if afterward they went on to use other languages.

As an example of an organization I think really does training right, I direct you to the San Francisco Ruby community. SF Ruby puts on a training session at least once a month. At least one of these, admirably, is focused on teaching women to program. In addition to training sessions, SF Ruby also organizes several hack nights each month, providing ample opportunities for newbies to mingle with more experienced programmers and get personalized assistance.

Now, in comparison, I’m going to pick on my local Perl Mongers group. Before I start, please be clear that I use here only because it’s convenient and—as you’ll see in a moment—provides a dramatic comparison. The SF Perl Mongers are a great group of people. This is not intended as a slight against them or the organization. I simply wish to show that the Perl community could increase its outreach to new programmers.

I’ve compiled data on the number of training and hacking sessions organized by SF Ruby and in 2012. All data is drawn from the Meetup calendars for each organization. A ‘training’ event is defined as anything focused on helping people learn the language and includes beginners’ hack nights, study groups, API office hours and more formal training sessions. A ‘hacking’ event, simply enough, is anything with the word ‘hack’ in the title.

Month SF Ruby SF Perl Mongers
  Training Hacking Training Hacking
January 1 5 0 0
February 3 9 0 0
March 1 6 0 0
April 3 7 0 1
May 2 6 0 0
June 4 5 0 0
July 8 4 0 0
August 7 6 0 0
September 4 5 0 0
October 2 5 0 0
November 2 5 0 0
December 3 3 0 0
TOTAL 40 66 0 1

The numbers, as you can see, are staggeringly different. That said, there is also a huge difference in the size of each of these communities on SF Perl Mongers has a membership of 380 people. SF Ruby has 5588. This naturally affords SF Ruby more resources to provide these events but does not, I believe, excuse for providing almost none.

SF Ruby deserves everyone’s attention and commendation for all of their work in training and outreach. It’s a model which Perl should look to emulate. While the resources of my local Perl community may not allow it to scale to the level of the 44 training and 66 hacking events put on by SF Ruby in the last year (nor do I think they should attempt to do so), I would hope those resources could allow for at least one training session every month or so and a newbie-friendly hack session every few weeks[*].

If Perl wants to show people that it’s alive and well it needs to be more active in public ways like this. Outreach to help introduce novices (especially minorities) to programming would go a long way toward dispelling the out-of-date image the tech community has of the Perl language.

[*]: Full disclosure: I am guilty of not offering to help in this effort. This is an oversight I hope to correct. This post is the first step in that process. Back to reading.

Increasing the Role of OSCON in Community Education

I recently returned from OSCON. It was, as usual, brilliant. My talk—a part of Business Leadership Day—was well-received, which is always validating. As I perused this year’s schedule I was pleasantly surprised by the number of community-related[1] talks. Nine! Nine talks about community!

My first thought was, “Attention to community! My, but isn’t this an encouraging trend!” This is, of course, an assumption. One data point does not a trend make.

But twelve of them might.

I delved into the OSCON schedules as far back as I could easily access them: 2001. The 2000 and 1999 schedules are undoubtedly available somewhere but seeking them out became a game of diminishing returns so I’ve set them aside.

My results can be found in this Google Spreadsheet, but in summary:

As you can see, the first several years tracked contain no community-related sessions whatsoever. Things pick up a little with a single session in 2005 but then take a large leap to five sessions in 2006. 2007 was lackluster, with only two sessions. But then! 2008! Eleven! Wow… Could it be that Open Source is starting to publicly recognize the value of strengthening its communities? Oh, wait…no, no it’s not. Or at least not consistently, judging by 2009-2011. The community-related sessions in these three years together totalled those in 2008 alone. And then we get to 2012. I exclaim again: Nine sessions! It’s no 2008 but it’s still fairly impressive.

That said, there is definitely not a trend here. But wouldn’t it be nice if there were?

One of the greatest strengths of Open Source is the communities which form to create and support the technologies. While the technologies themselves are undoubtedly very important the communities which build them have been given short shrift. Only 2.875% of all of the talks in this year’s OSCON [2] were at all related with community issues. Considering the undeniable importance of people and community to the success of any Open Source project it would be great to see this percentage start to creep up over the next few years.

Nota Bene: None of this is meant to diminish the work of the people at the Community Leadership Summit, which meets each year immediately before OSCON. It’s a valuable asset to Open Source, but typically it’s attended by those who already understand the importance of community. It necessary to reach a broader audience.

What I would like to see is a gradual increase in community-related sessions at OSCON itself (which by design receives a far higher attendance than CLS) to help raise awareness. Lately there has been a lot of attention given to the importance of things like Codes of Conduct for conferences. I would like to see that attention to the human side of Open Source to get more traction beyond the confines of conference administration, reaching into the communities themselves. OSCON is where Open Source comes to play and to learn, to see and be seen. When a large chunk of the community is lodged within your doors it seems the perfect opportunity to teach those people the meaning of the human side of the community of which they’re a part.

You’re never going to have strong, diverse communities if you don’t start educating everyone what a strong, diverse community is. I wholeheartedly applaud OSCON’s efforts to do so in 2012 and I hope that it continues to carry the flag and leads the charge with more even attention to community matters in future schedules.

[1] By “community-related” I mean talks about building and strengthening communities, not those simply about personnel or project management. [back to reading]

[2] This percentage will, in fact, be smaller. It does not include the sessions from the Education track, which don’t appear on the 2012 OSCON schedule menu. [back to reading]

Open Source: Why Can’t We Just Make It Easy On New Contributors?

As an Open Source advocate I’m frequently asked to which projects I contribute. My answer is typically, “None right now.” Why is that? There are a few reasons but they mostly boil down to:

  • As someone who does not code often (or enjoy it immensely) I do not feel welcome.
  • It’s an opaque process.

For now I’ll set aside the first reason to focus on the second: the process is opaque.

From my point of view, there is absolutely no excuse for this. Wikis, CMSs and cheap hosting all make it abundantly simple to offer plentiful guidance to new contributors, yet somehow that guidance is rarely provided. New contributors must delve and divine and guess and pester in order to figure out where to start. It’s almost as though the community does this intentionally as a sort of rite of passage for new members. “If you can figure this out then you’re smart enough to become One Of Us.” This is incredibly arrogant and exclusionist.

Why can’t we just make it easy on people? Why can’t we spend a few hours writing some documentation and tutorials up front, guiding newbies along the community-accepted path of contribution? Long time contributors may find the concept of spoon-feeding new members offensive but doing so will not only bring in more people to the fold it will also raise the quality of the contributions from the get-go.

To demonstrate how a project can make it easier for new contributors I’m going to use the Perl project. This is not because it’s such a bad example of how to do things (it’s pretty good, really) but because I’m fond of Perl and want to make some suggestions on how to make it even better. Also, I know that the Perl community is generally friendly and open to ideas on improving community involvement. That said, most of the suggestions are more generally applicable to all Open Source projects.

First of all, kudos to Perl for having a dedicated Get Involved link very prominently displayed there at the top of every page of! This visibility is a testament to the importance of contributions and contributors to the Perl community. Involvement is key for them and they put it front and center, right where it deserves to be.

However after that things get less obvious. The site is clean and well-designed, which is a pleasant change from many project pages, but this page is essentially just a list of bullet points with no context or meaning. For instance, what would I as a new contributor be expected to do with the Bugs, testing and reviews section? Is this for reporting bugs (yes) or fixing them (not so much) or…? What is meant by “testing?” Since I pay attention to happenings in the Perl community I know that this means automatically reporting test results to the imminently cool and useful CPAN Testers when I install new CPAN modules, but what if I were entirely new to the Perl world? I may think that “testing” implies a lot more hands-on work, perhaps testing new commits to the core language. It’s not obvious and it really should be.

The tagline of this page is Whatever your skill set or level you can get involved… While I believe this must be true, speaking as a mostly-non-coder this page does not make it obvious how I could get involved with the Perl project. Are there simple bugs I could fix (and if so, how)? Maybe documentation that needs writing/editing? How about project management? Ticket review? Marketing? Event organization? Donations? Not only are these subjects a good way to capture the less technical users and supporters of your project, they’re also a brilliant way for the new coding contributors to get a feel for the project and up to speed on the processes it uses.

Here’s a quick and dirty first draft of a version of this page which would be more useful to new contributors:

Whatever your skill set or level you can get involved…


Some say CPAN is the strength and heart of Perl, but they’re wrong. The people are the heart of Perl.

Getting Started

Ready to dive in? Here’s how to do it!

  • Contributor FAQ Every project has those questions which come up repeatedly. Collect them and their answers to help remove the barrier to entry.
  • An overview of the processes used for Perl. Link to another page. Key for everyone to know the steps in the process, not only so they’ll know what to expect but also so they’ll know better what language to use when asking for help.
  • Where to go for help. While this should be an element of every bullet point here, it also should be aggregated on a single page for ease of use. Broken down by subject. Include names whenever possible (mentors would be awesome and heroic). New contributors are more likely to ask for help if it’s obvious there’s a real person at the other end.
  • Where to find the documentation. Link to another page. List every form of docs that exist. Keeping all this in one place drastically reduces frustration for new contributors.
  • Where to find the code. Link to another page. Not just where to find it, but how to get a copy and, if you wish to commit, how you’d go about doing that (including expected code style).
  • Review and rate – the CPAN modules you use.
  • Send automatic reports to CPAN testers every time you install a new module.
  • Review trouble tickets. Link to a page describing the process, requirements and expectations for reviewing project trouble tickets. Ideally will include a link to a list of tickets in need of review.
  • Write or edit documentation. Link to a page describing the process, requirements and expectations for writing or editing project documentation. Ideally will include a link to a list of documentation tickets.
  • Translate documentation. Link to a page describing the process, requirements and expectations for translating project documentation. Ideally will include a link to a list of translation tickets.
  • Organize or Volunteer at an event. Calendar/list of events (locations and dates), assistance required and whom to contact for more information.
  • Donate. Link to a donation page and/or page detailing whom to contact to give a donation.
  • Have another idea how you could help? Contact us! Link to the correct contact information.
  • Best Practices for coding for CPAN.
  • How to report a bug for a CPAN module.
  • How to contribute a fix for a CPAN module.
  • How to contribute a new CPAN module.
  • Contacting CPAN module maintainers and what to do if they don’t respond.


Want to learn more about Perl6? Have a look over here! Anticipate the question rather than forcing it to be asked or searched for.

Again, this is just a quick pass at a possible Contributors page, but as a non-contributor it’s much more inviting than the current, sparse version. I can easily look at this and see my options and the methods for performing them.

Granted, there is a lot of organization and writing which would need to be done for a page like this to work. Believe me, I know it’s not easy getting all these ducks in a row. That said, I strongly believe that any project which goes through the steps necessary to make it much easier for new contributors to join will find its quality and reputation improving by leaps and bounds. It’s an effort very much worth making.