The Whitespace in the Perl community
One night over pastrami sandwiches, David Farrell and I came up with the idea of the whitespace in the Perl community. Between all the code, projects, user groups, and events we already enjoy, there’s much more that people who want to make names for themselves can do. The trick is picking what to do.
David started this website and wants to give people a place to publish their stories about Perl. He can promote it, readers can discover it once instead of finding new blogs, and authors don’t have to maintain their own site. Perl.com used to be such a site, and while it’s still around, it’s not active.
You probably know my own projects. I and a few others started Perl mongers when there were no Perl user groups. After The Perl Journal finally gave up, I started The Perl Review to take its place (and the print magazine lasted just as long). I’ve done many other things as well.
Both David and I looked for things that other people weren’t doing, and we both asked around to see who’s toes we might step on and to build support for our new thing.
We wanted to list things which other people might do if they were looking to make a name for themselves in the community. That’s different than mere participation. They need to make something that’s virtually synonymous with their names. That’s how they can build their résumés. Every project needs a spiritual center and chief motivator to keep things going.
I still remember Graham Barr demonstrating CPAN Search (subsumed into MetaCPAN in June 2018) for me at a long ago Perl conference. It was groundbreaking; we didn’t have anything like that yet. Younger Perl programmers probably have never been without it and didn’t realize how big a leap it was from browsing directories.
Before JJ Allen set up perldoc.perl.org, Carlos Ramirez had Perldoc.com (since defunct). Before those sites, there were isolated ways to get the Perl docs in HTML, but Carlos somehow leapt ahead of all of them to create an integrated solution. Fortunately, JJ Allen took the idea further when Carlos disappeared.
Not every successful project is a completely new idea. Sometimes it’s an older idea done better. Gabor Szabo started Perl Weekly to curate the internet activity of the Perl community. He discovers what’s worth reading so the rest of the community doesn’t need to spend too much time away from kitten videos and coding. Other people have tried the same thing, but Gabor’s advantage is his perseverance.
We did come up with a list of opportunities, but we’re not going to present it here. We thought of things that we’d like to do, but in my experience that’s not that helpful. Not only that, but the most successful ideas seem to be something that nobody had ever considered, including us. The next big ideas will be things that most people never imagined.
Instead, we talked about the process to come up with those ideas, which is the advice either of us tend to give out anyway. Along with that, we put together some advice on how you might make it work.
Whitespace is any opportunity to add value. In that sense, there are two categories of whitespace:
The first is discovered through innovation; truly original ideas whose time has come. No one is doing it because no one has thought of it. These “gladwellian” opportunities can be highly valuable and often come from deep insight. They’re also exceedingly rare, such as the creation of CPAN. Every language has their own version of CPAN now.
The second kind is less appealing. These are the opportunities that exist because no one wants to do them. Typically the work required to exploit the opportunity will involve repetitive and manual tasks, such as maintaining documentation or shepherding modules that you didn’t write and don’t use. In Perl we hack through inconveniences all the time. Inconvenience is an annoyance or an afterthought. We
split on it, trim it and move on. But those inconveniences are opportunities, where (usually) no one is working. These kinds of opportunities can be just as valuable to the community and even so, are easy to find. Just look for the jobs that would benefit the community that no one is doing, and start doing them.
If you want big results, you can do either the boring or the hard work that no one else is doing.
Just do it
We had a much easier time back in the day because we didn’t think anyone was in charge and there were fewer toes to step on. Now there are various organizations, such as The Perl Foundation. People often ask me how to get TPF approval, but they don’t need it. They don’t need a grant, or a subhost on a particular domain, or many of the other things any organization might control.
This isn’t to say that you should ignore those who can help you; just don’t let them stop or delay you. Remember that they are all volunteers and are probably already giving the time that they have available.
Your first step is to ensure that you’re doing something you’re going to want to do. It’s one thing to come up with an idea, but it’s another to want to work on it for months (or longer), most likely on your own until the community gets behind you.
To do this, you should talk to as many people as you can. Start with private or limited conversations with people you trust. Some people may tell you to just put it out there, but do a little research first. Don’t get discouraged by irrelevant details from people who weren’t going to use it and weren’t going to help.
Specifically, don’t design a database schema right away. I’ve long had a rule that lets me figure out which conference fever projects will fail within the month; they are the ones who start picking the technologies right away.
Figure out how you want it to work, and keep a particular audience in mind. Instead of pleasing everyone, which drags out your design and creates much more work, start simply so you can get something out there quickly.
Sticking to it
Most ideas fail because their originators think that the idea is enough. People will see the merits instantly and volunteers will step in to do all the work. Fall into that trap and you may find yourself unmotivated and overworked because you are doing everything. For awhile, embrace the idea that you’re doing most of the work and look at help as gravy instead of the meat.
Be ready to give it up
Our last bit of advice seems contradictory to the rest. After you develop your great idea, be prepared to lose it. The idea may change from underneath you, or more motivated and enthusiastic volunteers may take it in another direction. Trying to stick to the original plan might drive everyone away.
Also be prepared to hand off major responsibilities to other people and to trust what they do with it even if it’s not the same thing that you would have done.
Some ideas we had
You didn’t think we weren’t going to suggest anything, did you? We had a few ideas of things that we’d like to do but don’t have the time to do ourselves.
Perl is under-represented on Reddit, Twitter, and Facebook. There’s no person we can point to as the energy behind these efforts. Some of the same names that you see everywhere are present, but no one has planted their flag here. If you’re social media savvy, you could be the person to tend to Perl wherever you spend your time. The different sites have different purposes, each of which could highlight Perl in a different way and for a different purpose. You can create content or highlight the work of others.
CPAN Testers is a fantastic service, but have you ever wanted to re-create a bug report from CPAN Testers? Unless you have access to the specific operating system and Perl version, you may not be able to. Even once you get hold of a virtual machine, it may take several hours to install the Perl modules and C library dependencies required. We should have a collection of virtual machine images within easy reach that any Perl programmer can startup to launch, pre-loaded with every major Perl version and most stuff installed.
There could be a a “PDL Perl” distribution that would have all of the main Perl Data Language libraries installed and the same for our major web frameworks and our OO frameworks. A Perl developer could then quickly spin up an instance of OpenBSD and run their Perl code against every installed Perl version using perlbrew. This might happen with something like Virtual Box or Vagrant.
This doesn’t be something you distribute. Free service hosting services like Digital Ocean allow users to share snapshots of virtual machines, but the end user would still have to pay a few cents to lease the virtual machine for a couple of hours. What this requires is someone to regularly maintain and refresh the snapshots, installing the latest Perl versions and keeping everything up to date. Similarly, someone could create and maintain a Perl Learning Environment.
Our advice is simple. Find something that you want to spend time working on, get advice before you start, and plan on doing most of the work yourself. Once you get going, settle in for the long term. You don’t need anyone’s permission for any of this.
This article was originally posted on PerlTricks.com.
Something wrong with this article? Help us out by opening an issue or pull request on GitHub