Lots of good things have happened, including the establishing of the TPF marketing committee, volunteer stands at non-Perl conferences, and more focus on the brilliant parts of what the community and it’s software can offer. It’s been great watching all the goodness unfold, and being part of some of it.

But in the meantime, something else has been bugging me.

All the time, there’s been a focus on tools and people. When it comes to solving actual and real life problems, not much has surfaced. Instead there’s an unspoken focus in the Perl community about making tools that help people make tools.

What we do at the moment is marketing tools-for-making-tools. We tout the obvious superiorities of Moose, Catalyst, POE and all the other goodies in Task::Kensho, but when it comes to solving actual and real problems that “normal” people care about (you know, the people that don’t care about the details in computers), we blissfully ignore it while silently hoping for some big company to choose Perl for their next public project – so we eventually can get a new website to link to.

I propose we do something about this. Let’s pick a few real and significant problems, and see if we can make an impact on those while using and showing off Perl software, the Perl community and all that is good about it at the same time.

To kick this off, let’s ask a few basic questions.

• What are “real” problems? – Read the news! You’ll find people complaining about education issues, lack of clean water, political turmoil, misuse of power, corruption, closed “power clubs,” democratic deficit in government, etc. etc.
• Also, consider the prevalence of a problem. Local < Regional < National < Societal < Cultural < Global < Biological. – There’s nothing wrong with a little ambition!
• And finally, is it a particular or a systemic problem? Is it short-term (critical) or long-term (chronic)? Can you find similar problems in other areas?

Picking a good problem to play with is very much up to you. Pick something you care about that you know is difficult, and pick something that lots of other people care about too but that can’t be solved trivially. Maybe you want to make a quick risk assessment matrix to figure out if your issue is “real” enough? (and even if not, it’s probably useful to remember that $risk = $likelyhood_of_failure * $impact_of_failure; anyway.)

Next, you have to make figure out a way to improve on the situation. Keep in mind that $influence = $visibility * $impact; – meaning whatever you do, you have to both think about execution and telling people about what you’re doing. Make a plan, and tell people about it! The rest is “just” hard work.

With that said, if you’re going to make Perl part of any solution, it might be useful to have an idea what role Perl can have in the process. Here’s one possible (and quite generic) value chain:

1. Perl
2. ➜ CPAN
3. ➜ $USEFUL_FRAMEWORK (A tool for making tools) # This is where we code today
4. ➜ $TOOL_THAT_INCREASES_AWARENESS  # This is where I think we should code more
   
5. ➜ Discussions and awareness building, eventually in media
6. ➜ Discussions among politicians
7. ➜ Some kind of funding in order to improve issue
8. ➜ Someone tries to actually do something
9. ➜ Success/FAIL/Meh.

Also, keep in mind that Perl is useful in places where data, information or knowledge is the main currency or “item of value.” Perl tools might not help directly with “physical” matters, but I’d say it’s much better suited for improving communication and knowledge-related issues.

So, you ask: How about an example?

I’m so glad you asked!

My attempt at this is called Kaizendo.org, and it’s purpose is to enable people to create textbooks that can be customized to the individual needs of the reader.

To make this happen, we’re creating a Catalyst-based tool for discussing and improving texts that have aspects – texts that have alternative representations of themselves, each telling the same story but in different ways. If a pupil is struggling with dyslexia, then choose an aspect where the story is told with simpler, shorter words. If a pupil is bored because the rest of the class is slower at reading, then choose an aspect where the story has more details and depth, so the pupil can keep the same pace as the class while getting more interesting content out of it.

What would I like to influence with this?

• Make textbooks more interesting for kids, so they can effectively (and motivationally) compete with professionalized entertainment like games, social networks, television and other kinds of procrastination. (How? By making it possible to write aspects that appeal to different fields of interests, and improve these based on reader feedback.)
• Give teachers the opportunity to use their textbooks more actively in the way they teach their classes. Textbooks are today for homework, why not make the homework more relevant for what’s going on in the classroom? (How? By making it possible to write aspects that support different styles of teaching)
• Make the textbooks a conversational item, so pupils, teachers parents and other enthusiasts can not only figure out the best ways of telling a story, but also learn and improve their own level of knowledge by allowing them to discuss and improve the contents of the textbook. (How? By allowing anyone who cares about the textbook content to give contextual comments to the text itself, discussing these, and finally make it easy for the authors to update the text based on those discussions.)
• And quite a few other things.

The project is up and running now, and we’ve started writing the prototype, we have a mailing list and wiki, and I’ll even be giving a talk about Kaizendo at YAPC::EU in Pisa. But we’re still far away from our goal, and we need plenty of help.

So, if you like what I’ve written here but don’t want to start your own Big Project That Matters, then do consider joining our project. In the meantime, tell me what you think!

• On-demand printing, in use today
  
• The “Espresso” book printer

I posted this on my use.perl journal yesterday:

This year, Nordic Perl Workshop is co-located with another open source conference, Go Open. This is what we’re working on right now:

• The conference theme is “Your future with Perl”. Talks have been subitted, now we’ll try to stich together an interesting schedule.
• We’re aiming for one Perl6/Rakudo/Parrot track and one track showing modern use of Perl, hopefully with a flavour of Enlightened Perl mixed in.
• NPW will share venue with Go Open, giving everyone an opportunity to see how a Perl conference can be, and giving the Perl community a place to show off it’s best sides. The Go Open theme: “Openness is profitable”.
• The day after the conference, we’ll open the doors for our Perl6/Rakudo/Parrot/Enlightened Perl hackathon at Redpill-Linpro’s nice office (the same place we had the Perl QA hackathon last april).
• Gabor Szabo will come and hold his newly improved 4-day Test Automation course right after the hackathon (at the same venue too). There’s room for 12 people there, contact Gabor if you’d like to come.

And to boot, there’ll be another Perl QA hackathon in Birmingham just the week before. LOTS of good reasons to visit northern europe around easter, in other words.

Still, is there anything we could do to make it better? I’m specifically thinking about the opportunity we have due to sharing venue with Go Open… Any ideas on how we could “market” the livelyness and good parts of the Perl community? Who would be the natural people to do this? Would you like to do something?

Please share your thoughts!

- Salve (Oslo.pm and NPW guy)

Any ideas?

• When looking for Open Source or Free software to use, remember to first look for good projects, then for good products. With FLOSS I have the option of becoming a contributor – even if it seems unlikely I will right now, I may become one sometime in the future. I know this because my requirements for the software will most likely change as I get comfortable with it – and when this happens, I’ll be glad that I chose a project that will support me as I get to explore it’s details, or support the people I hire so they can improve on the product on my behalf.
• Consider the license! If I in some way intend to add value to the product in order to sell it, go for products with a BSD-like license. Otherwise stick to licenses that force other people’s (and my own!) contributions to stay free for all and anyone to scrutinize and improve. The GNU General Public License is the most used one in this regard.
• Get a feeling of the type and amount of activity. Look for mailing lists, web bulletin boards, bug trackers and newsgroups, and try to lurk around for a while to get an impression. In a FLOSS project it’s evolution of the code that matters most. Not the code itself, not the people working on it, not marketing or managerial matters. See if the project has good code, people, marketing and management – but if one of these seem to hurt the project’s prospects, find out how the project lead(s) solve the problem so that the project can continue thriving. Also take into consideration the type of project you’re looking for. Are you trying to solve an open problem (the kind which never is “done”), then you should expect the activity to be bustling. With projects trying to solve closed problems, you shouldn’t be too disparaged by low amounts of chatter on the forums.
• Look for inclusive but code-centric leadership. What do the contributors do to attract talented people? How is the tone and atmosphere in the different fora? How much of the discussion is solution-, system-, feature-, wishlist- or people-oriented? Is the project open and welcoming to novices and new contributors? How often do discussions reach a satisfactory conclusion?

A project should at presumably make use of the following infrastructure and characteristics in order to support good communication:

• One or more open forums (with searchable archives) where you can join the discussion, ask for support etc.
• A standard way of retrieving the latest bleeding edge version from a revision control system (e.g. SVN or CVS) so you can check for yourself what’s going on in the project.
• A bug- and issue tracker that is in active use.
• A website describing the product, with documentation, download links and other collaborations tools (a wiki for example).
• Responsive project participants, and a good and friendly tone wherever the software is being dicussed.

If the project seems promising but lacks some of the infrastructure, then try to find out if the contributors are working on aquiring the missing tools.

http://www.cervisa.com/innkeeping
http://opensource.mit.edu/papers/westomahony.pdf

Which other good articles on this exist?