Robert 'phaylon' Sedlacek

I had the opportunity to help out the Perl::Staff at this years CeBIT. There was lots of interest in Perl, and we had lots of talks with people about what they are using Perl for, and how to bring the community and the companies using Perl closer together. This is quite a long post so I’ll put it behind the jump.

(This article is written in English, since it probably applies to a larger audience than only the German Perl community.)

For quite a long time I have thought that large parts of the German Perl user base were “unhealthily” discoupled from the (mostly) international core community. By core I mean CPAN, the Perl IRC network, mailing lists, and wherever else all the cool, new and edgy stuff happens. I also for a long time had no idea on how to fix this (and probably still haven’t). So I foremost have to thank the Perl::Staff for having me there, Renée for getting me there in the first place, and the CeBIT as a whole for giving me many new insights into the community/industry gap.

What we were doing

You probably already read elsewhere about where the priorities where in promoting Perl at this years CeBIT. We wanted to show that Perl exists, that it is still alive, and that there are new things being developed all the time. We also wanted to learn about companies’ thoughts about Perl itself, the community, and the usage of Perl in the industry.

The Perl::Staff team itself was a very diverse mixture of people, which I think played out very advantageous for the whole effort. Many grounds were covered and I personally felt surrounded by lots of experience and know-how, this of course reflected upon the discussions, which often were quite in-depth and all-in-all very open minded.

Fortunately the average fitness level in relation to such events was higher than mine. I only managed to “work the floors” 7 hours for 3 days. Big kudos to all the others that managed to stay longer, and a big thanks to anyone in the community who does something like this voluntarily, since it is harder than one might imagine.

For me, it was the first event of this kind. I’ve only managed to get myself to a single YAPC, and the last time I worked at a convention stand was many years ago and with company backing. It was also my first CeBIT, so I wasn’t sure what to expect. Lucky for me, there wasn’t much time to be worried. When I arrived there were already plenty of people wanting to talk Perl.

I’d also like to thank whoever gave us that little info-shelf on (I believe) Thursday. I’m sure it saved us quite a few miles of walking if you’d sum it up!

The Open Source corner

I thought the organization and placement of the different booths and areas in regard to Corporate and Open Source topics was very well done. A big part of what we wanted to achieve was to bring the companies using Perl and the community closer together, so the floor plan worked out perfectly. Since my background is to a big part middle and large-scale development (front- and back-end), I enjoyed to talk to many CEOs and IT managers. And I assume the careful interweaving of Corporate and Open Source areas had a solid part in making that possible.

“Have You Heard Of Perl?”

There were much more people that knew (and liked!) Perl than I expected. There was some talk about maintainability in regard to other languages, but everybody agreed that while there are platforms that prioritize an easy learning curve and such as more important than expressiveness, it all depends on the situation and the developers using the tools. Note that having other priorities isn’t a bad thing. Quite the opposite, actually; how could we evolve without accepting different viewpoints as valid?

Many, many German companies have used or are still using Perl. Also the ones making heavy use of Perl were quite a bit more than I expected. The whole event felt more like a reconnection between two worlds that have been separated for years, rather than being about telling people that Perl exists.

So, many people have heard of Perl. But only a small part knew about Modern Perl, Moose, Catalyst, DBIx::Class or any of the other new developments. What seems to be missing is a way to keep companies, institutions and teams informed about the larger developments in the Perl community in general, and the individual changes and progress of our most high-profile libraries. At the moment, I see no need for a killer-application. We have lots of killer-libraries that do an amazing job at Getting Things Done while staying flexible enough to solve exotic problems.

There’s lots of talk happening in the social media about Perl right now. Lots of blogging, tweeting and so on. This is an awesome development, and has freshed up the whole idea of being part of the Perl community, throwing ideas out there to see what sticks, and solving problems as a community.

But to those that aren’t a part of the core community, this information is either not interesting, or it doesn’t even reach them in the first place. Even I don’t have the time to read all the Changes files for modules that I use regularly, and me being up-to-date is a large part of me being able to afford food. The new social media boom in the Perl community makes this a lot easier for me, since even if I missed a new feature in the Moose change log, I might read someone’s blog post about it later on.

Social media is great for reaching exactly the people that are interested, and to get information to people that might be interested but don’t know it yet. But for it to be viable to keep a group of people informed that work as a unity, like a development team or company management, it is just spread out too thinly for many pieces of information. Most development teams don’t have someone whose job it is to stay updated and bring important developments, news and so on to the attention of the team as a whole. This also means that in order for a team to learn and utilize a new feature in let’s say Catalyst, they are dependent on at least one developer picking up on that information somewhere in the social sphere, the Changes file, the mailing list, or somewhere else inside the established channels of the Perl community.

I think the point I’m trying to make is that we need to reach out not only to the people by using social media (blogs, Twitter, reddit), but also to the more traditional forms of media that don’t have such a wide-spread coverage, but are more easily accessible to groups (newspapers, and probably the traditional forms of online news coverage as well).

Many of us (me included) are used to think in smaller scales. We focus too much on what software does, and too little on what it makes possible. We do this because when library developers talk to each other, they focus on different things than what application developers talk about. Having something like a centralized place where the different projects could inform the community as a whole about new and exciting developments could be a huge win. We already have the ability of the developers and the users to give us a wide picture of how they are using software, and what they are doing with the things that were implemented. We don’t yet have a place where these projects can speak as a group about why they made decisions, what they want to make possible, what the large-scale concepts and contexts are, or simply be able to reach out. This would also be a great place to draw people closer to the community or individual projects.

It would also be a nice overview for people to see what Perl can actually do. At the CeBIT, I talked a lot with people about developing complex systems in Moose, about the scalability of Catalyst and how its flexibility allows you to solve all your large-scale business needs with ease while staying maintainable, performing extremely well, and still being flexible enough to cope with all issues that you didn’t think of yet. I got the feeling that many people have no problem with evaluating different options. They don’t have a problem with TIMTOWTDI. But they want at least a nudge in a general direction so they see what they are looking for is possible, is provided, and has solutions that they can freely choose from.

We need to find a way to keep casual Perl users informed about what is happening in Perl. Information is everything.

Where Perl is used in Germany

As expected, system administration, data processing and infrastructure/workflow solutions are still seen as Perl’s strong points by many institutions and companies.

I was rather surprised by the fact that many CEOs and managers had a real interest in and many good things to say about Perl, Open Source, and especially the community-driven efforts. I think that providing more high-level resources and articles about the use of Perl in companies and institutions might turn out as a win. We don’t have as many or as shiny killer applications as other platforms, but we certainly have the tools, the flexibility and the know-how for providing solutions to business needs and industry problems from small to enterprise-scale.

There was also a huge amount of people doing C and C++ together with Perl. I think if we’d had an easy to use and flexible FFI that can cover the most common needs it could really take off. I had an idea bout using the Moose type system to create a transforming membrane-layer between C/C++ and Perl, but my knowledge about low-level languages is unfortunately less than basic. There was also more talk about embedding Perl into other projects than I expected.

I was able to make lots of contacts with different people who were interested in giving feedback and staying in contact with the Perl community. The general agreement also seemed to be that Perl and its corporate user base as well would greatly profit from a better awareness of Perl’s existence, scalability and spread.

“So, about Perl 6…”

Perl 6, Rakudo and Parrot were mentioned quite often. Most of the people I talked with already knew what Perl 6 was (almost all of them also knew that Perl 5 won’t go away), so the question I got asked mostly was “When will Perl 6 come out?” Being pointed to Rakudo Star being on its way got a couple of people surprised, but also excited.

I also got many chances to mention Parrot to people. I think Parrot and the flexibility it will provide are often underestimated. And many non-Perl people only knew that Parrot was an upcoming dynamic virtual machine, but knew little or nothing about its goals or features.

Other dynamic languages

If your statistical sample consists of reddit, digg or slashdot, Perl, Python, Ruby and all the other members of the family of dynamic languages are at war. Of course, we’re also fighting the static languages, but that’s a whole different kind of silly.

My experience at CeBIT was quite the opposite. I didn’t get a chance to talk to many Ruby people. I assume that while the Ruby community is growing, it’s still in its early days around these parts of the world. I did, however, get to talk to many people using Python. Some having switched from Perl, some using both side by side, and some that never tried Perl before. (And some coming to Perl from Python.) And even many of those that switched away didn’t doubt that Perl still was a valid choice.

The decision to either use an existing community-supported library or build your own solution in-house is a difficult one. Those companies going with the latter option might base their choice of platform on the availability and trainability of developers. And currently, the public opinion favors Python as an option to ensure that you don’t run out of manpower in that scenario.

So, the question “How easy is it to learn Perl?” was asked more than once at CeBIT. Being able to point people at learn.perl.org was a huge help in showing people that learning Perl can is easy. We often emphasize that we use tools like Perl::Critic to ensure best-practices, and that this and having team-guidelines goes a long way in making software maintainable. But to people who aren’t used to this it may seem like a big effort just to write readable code. Yes, they think it wastes time to do it this way. We know it doesn’t. We know that Perl’s testing infrastructure and culture are progressed enough that you can drop a simple file using a simple module into your test folder, and you can use the full Perl testing tool chain to ensure that the policies you decided are best for your team are followed. Combine this information with commit hooks in the repository and you have a way to ensure coding standards are upheld by your team. And this is only a single example.

In the Perl ecosystem there are many, many small libraries that don’t seem to do much. But we often forget that the Perl community around CPAN has a very strong tendency of getting along. Combining different library functionalities to achieve our goals is something we do each and every day, These libraries might not seem very interesting at first, some might even wonder what the fuzz is all about. But they might be the single simple last wheel that is needed to allow much more complex solutions to be solved easily. The wheel was in itself a rather boring invention. The exciting thing was what one could do with it.

To get back on track: In the bigger picture, friendship and respect seem to be found more often between different languages and platforms. There was lots of excitement about Perl being a stable and reliable community effort, and maybe we could all gain a lot if we (in this context, “we” means the community-driven languages like Perl, Python and Ruby) worked together to tell our success stories, and how these community efforts can help and grow with the industry.

PR Ideas

There were some ideas floating around the Perl stand about what other kind of information one could present at an event like this. The stuff we had this time was already really awesome. It was simple, elegant, concise, funny, and brought the point across very well. It also did a great job at covering a big part of what one could tell people about Perl. Some ideas that came up (not by me) were having a map of the Perl Monger groups (which some people didn’t know about yet), or a simply poster listing all Perl modules names on CPAN. 20.000 seems a lot to us, since we know what traffic and work is going through CPAN each day. But for someone on the outside it is often hard to visualize the quantity of know-how that is archived in there.

Other things I could think of were expanding on this years postcard-sized PR material. Like diagrams showing the CPAN infrastructure, the tool chains, or the different solutions for common problems (like testing) could very well fit on a single post-card. I could also imagine people being interested in brochures about all the different ways of doing testing in Perl, about using Moose for doing object orientation and what MooseX modules the community favors most, about what Catalyst allows you to do and what extensions exist to cater to a wide range of needs.

The cards we had that listed the Perl events got people really interested as well. I think quite a few people were surprised by how active the Perl community is. I could imagine a brochure being only concerned about “Social Perl” covering things like the Perl Mongers, the conferences, the CPAN Testers project, the mailing lists, how to become a CPAN author and so on being a good idea. Especially at business-oriented conferences, since the information we gave out might very well be carried into many offices next week.

To Wrap Up

This was a very exciting event, it was much harder than I expected. We had a huge success, and Perl is still a strong player in the field. I certainly hope to be able to help out again soon. Although next time I’ll start jogging a couple weeks before the event.