As you might have noticed there’s been some talk about whether people should be free to release Open Source software the way they want to, or if we should try to bully them into compliance. Since the original author has now started to drop ad-hominems and directly attacking people who disagree with him, I will follow Gabor’s example and not link there. I’m also not gonna go into the topic of “People should be allowed to bully others. If you don’t like it, go away.” That one is left as an exercise to the reader.
I’m of the opinion that a free CPAN is what got us this far, what kept Perl alive, and what will allow it to stay alive in the future. Be it code, documentation, tests, RT tickets, or casual help on IRC. The sum of all the people doing this for free is what makes this community great.
I’ll try to demonstrate below why I think we need to further to work as a community, and the freedom and ease with which people participate. I also hope to demonstrate how cursing, belittling and being condescending to people who do something that isn’t of immediate use to you will not help.
But first off, to all people sharing any of their resources with the community, be it just code, documentation, tests, marketing, user support, or even just by keeping up with the community and using the modern tools, furthering their use and progression: Thank You! Perl needs you, and I couldn’t write Perl for a living if you all had just decided to keep it to yourselves. The Perl community is not a hive-mind, and we’re made up by many different minds.
]]> But let’s get back to the issue at hand.This discussion comes up a couple of times every year. It usually comes up because some poor developer thought “Hey, this code might be useful to someone else” and releases it without documentation. He has already invested time in the project, and wants others to be able to build on that. Then someone finds the module, sees no documentation, and goes on a ballistic rant like one you’d put on a pizza delivery website if they gave you cow-manure as topping instead of extra cheese.
Here are some points the proponents of a restricted CPAN make:
I’m the customer using your product. There is an implicit support contract between you and me.
if you’re not gonna write any documentation, I can’t use it. Why are you releasing useless software in the first place?
People complain about not finding documentation. The lack of support is killing Perl.
Why should I waste my time trying to figure out how the module works, if the author could just spend the time writing the documentation?
I have deadlines to meet, and things to get done. Your stuff doesn’t help me.
Let me go into a bit of detail on why I think these assumptions are flawed:
Actually, no one does. Most Perl modules even come with a notice that they are provided without support or warranty. If I release a module, it’s not a product. I’m not selling it to you. I wrote it and figured it might be useful to others, so I put it into a public space and slapped a license on it allowing people to use it. That’s what’s commonly known as “gift.”
Giving someone a gift in no way makes you obligated to give this someone even more gifts. If you buy me a beer, you don’t owe me a sandwich. If you give me a cake, I can’t complain it doesn’t have the right sprinkles.
I know that in todays consumer-driven environment we like to have someone to blame. But to blame someone they have to have done something wrong. If you can’t blame people for not giving you anything at all, you can’t blame them for giving you less than what you would’ve wanted.
But these people have invested their time and resources into building something. And instead of keeping it to themselves, not bothering with anyone else, they chose to share it, so others might have less work to do with it out there. Sounds like a nice gesture? Sounds like something the community will be thankful for? I assume some of these people will learn their lesson and leave the Perl community when they are told to “Get off our CPAN” instead of being thanked, helped and supported in their continuing involvement in the community.
There’s lots of things in Perl that are useless to me. The Win23 modules? I don’t use Windows. Basic tutorials? I haven’t needed them back then and I don’t need them now. The Perl 5 porters are currently even looking if they can continue to support z/OS. I can’t see that ever being of any use to me.
But I still think it’s good that it’s happening, and I’m glad there are people who are devoting their time and resources to provide us with these things. And it’s the same with code without documentation.
Code with documentation does the job and is easily accessible. Code without documentation does the job but isn’t easily accessible. No code at all is of no use to anyone. Lots of people are not comfortable reading and evaluating a module completely based on code. I have to do that every day, so I’m used to it. I can make use of a module even if it doesn’t have documentation. I can write bug reports. I can help write documentation. I can help keep the documentation up-to-date and make noise if something is unclear or unintentionally misleading.
If some people can’t because of other constraints, that’s perfectly alright. We all have to work within our constraints. But if we start policing module releases based on a single persons constraints, we’re in trouble.
Should Catalyst and Moose have not been released instead of the community working together to make them better? Should we remove Dist::Zilla because the documentation could need more work? All documentation needs more work, all the time. Just like all software needs more work.
There are lots of things that can be done with code lacking documentation:
Simple libraries might be usable without documentation. At least for private projects.
Someone else could come along and, instead of investing time to write code and docs, invests time to write the docs for an existing module that has none.
Someone could build a better module, using an undocumented one as basis for how to get started. In this case the undocumented module is basically a proof-of-concept.
Someone could fork the module if it’s good, but the opinions of the original author and the new one differ.
If someone uploads undocumented bindings for a library “Foo,” the Perl community now has contact to a developer who knows about “Foo.”
And these are just the most obvious advantages. If the undocumented code has a dependency, the following advantages are true as well:
The code is a searchable, live and mirrored example of a use case for the dependency. This means other users as well as the original author of the dependency can look at another example of how it is used.
The code is testing the dependency, thanks to CPANTesters even on a wide variety of platforms and perl versions. This is even nicer if the module is used in a way not yet tested in the dependencies distribution.
The point is: Even if the code doesn’t provide an immediate solution to a single user, that doesn’t mean it has no value to anyone or the community as a whole. If I share work, it is because I don’t see any reason to keep it to myself. This to me is one of the basic pillars of Open Source. Being personally attacked is not.
People aren’t using Perl for lots of reasons: TIMTOWTDI, not-shiny-enough OO syntax, because it’s old, because it has sigils, because it’s not compiled, and many more.
Lots of people spent lots of time getting documentation, testing, and best practices established in the community. They went more than the extra mile, were supportive, built better tools, and tried to communicated the reasons and advantages.
Had these people just been attacked, belittled, and had we tried to rid the Perl community of all these folks, there would be no Modern Perl movement.
It is rather amusing (FSVO amusing), that the biggest complaint I ever heard about the Perl community was rude people. I was asked more than once why people should consider contributing if all they end up with is getting hate. I find that thanks to the efforts of many people over the years, and up to this day, this has been turned this around.
This long transformation of a loosely coupled group of people into a social community of developers is what made Modern Perl possible. Perl is growing again. Maybe not yet in all statistics, but with regards to interoperability, library depth, tool-chain, testing, core development, and community spirit, there is a lot moving forward. And every tiny contribution is another step.
If there is a single mode of operation Perl does not need right now, it is hate. Since this has come up again and again, I’ll just point you here and here. In my opinion, if anything is killing Perl right now, it is anti-community behavior, and trying to make other contributors work seem worthless.
This is an easy one. If there is no code at all, you have to write it yourself. If there is a module that does it, but it doesn’t satisfy you, you can either help out, or write it yourself. It is all the same in Open Source, no matter if it’s about features or documentation.
Too many people seem to think of Open Source as “selling a product with a 0€ price-tag.” This could not be further from the truth. There are lots of resources on the web about this, so I won’t go into it. But just because you didn’t pay for something doesn’t mean the something is worth nothing. It also doesn’t mean the time of the developer of the module is worth nothing. Which means just because you got the first 10 hours he spent writing the code for free, doesn’t entitle you in any way to another 5 of his hours for documentation or support.
I often hear that this is not about entitlement, but I can’t but feel that it indeed is. Because this all implies that some people would rather spend their time writing something from scratch, (hopefully) documenting and testing it, instead of contributing to an existing module that is not yet sufficient for their use. If you are angry about the fact that those are the only choices you have, you are angry because you think you should be entitled to “it doesn’t exist, I have to write it” versus “It is there, tested and documented.”
Perl needs a free CPAN, and a community working together (socially), instead of isolating what is not deemed worthy by some.
]]>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.
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!
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.
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.
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.
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.
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.
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.
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.
]]>