Rugged Individualism, Community, and Templating Systems


Christie Koehler published an insightful comparison of codes of conduct and censorship in technical communities. Christie's experience as an organizer of the excellent Open Source Bridge conference—especially the Open Source Bridge Code of Conduct is instructive. In particular:

... we are entitled as a community to exclude a few in order to welcome the many that have been marginalized time and time again.

... but also perhaps more important:

We wanted a document that emphasized the idea of open source citizenship.

When you use, patch, document, recommend, create, test, or otherwise participate in the development of free and open source software, your actions take place within a community. As well documented in many places, the social actions of the community are important to the current and long-term health of the community...

... and so are your technical actions.

Consider this: I have at various times in my career written a templating system, an object model, and a test framework. I no longer use nor maintain those projects, and you will not find them in anything other than the Internet's vast elephant graveyard (if they even exist there).

These projects are long gone in part because other projects are (now) obviously better and I have exceedingly good taste in predicting the future, but (more seriously) because the value of those projects to the community was far less than the value of competing projects.

I have the right to publish a new templating system to the CPAN, but without a staggeringly compelling reason to do so (such as that it uses a different technical approach or that it provides the most useful subset of features of an existing system with far fewer requirements or much better resource usage), the community is probably better off if I refrain from doing so.

See also Plack and its ascent from "Hey, that's an interesting idea. What did Python call it again?" to "Of course we use Plack, just like all good-hearted people!" in just over a year. (Plack is even more interesting in that it builds on a standard, PSGI, which allows a project such as Mojolicious to build its own Plack-alike which supports and interoperates through PSGI while following the Mojolicious technical decision of reducing dependencies.)

In the same way that codes of conduct and community values and standards of behavior encourage good citizenship, open doors to all participants, and cooperation over conflict, perhaps our communities can find ways to promote technical collaboration and cooperation. Rather than promoting the creators of projects as übercoders, perhaps we can recognize maintainers, documenters, releasers, speakers, bug-reporters, and users. Rather than individual fame and glory, perhaps we can celebrate re-use and adoption and collaboration. Rather than dozens of semi-compatible object systems on the CPAN, perhaps we can coalesce to a standard MOP in the Perl 5 core upon which multiple object systems can interoperate.

There's room for invention and reinvention and customization to meet unique deployment or development concerns. May we always meet those needs! Yet may we also consider more often the good of the community above our own desires.


I think we would be better off if we could encourage more people to take over maintenance of modules and/or if we could encourage more people to share the maintenance of modules. Less modules but of higher quality and more stable maintenance would be better than having more modules.

DVCS certainly helps. I'm much more likely to help contribute bugfixes and typo fixes and documentation improvements to projects on Github or with public repositories, but your point is very well taken -- PAUSE is often a bottleneck, not due to technical factors but due to social factors which reduce the likelihood of granting co-maintainership.

Certainly need people to adopt old modules. I'm trying to do this where I can. More people I think need to know that there are route's to get a module if the old author can't be reached. I think some people don't realize that they can take these over. Even if the old author is not around anymore.

Is there a "list" of modules needing new maintainers somewhere?

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on August 5, 2011 11:39 AM.

A Blooming Garden of Codenames was the previous entry in this blog.

Everything is a Compiler is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?