Reflections on Parrot as Project, Product and Process

Last week I helped organize a gathering of Parrot developers, old and new, in Portland, OR. We shaped the discussion more around the people of the Parrot project rather than the technology or the code. Since my return to New York City my time available for Parrot has been tied up with diagnosing problems impeding Parrot's build on small resource machines. So I haven't had time to write up my reactions to the gathering. Nor have I had time to read the blog posts by Christoph Otto (cotto) or those by Andrew Whitworth (whiteknight). So that I don't delay my write-up further, I'm going to post these thoughts and only then read those other Parrot developers' blogs.

What Motivates Us to Contribute to Parrot?

My strongest feeling is that right now, in order to keep moving forward, our efforts as members of the Parrot project have to become more focused on its long-term goal: the creation of a virtual machine used by high-level languages (HLL) and other open-source projects to build other, end-user information technology applications. True, when we hack on Parrot every day, we know that we are working on a virtual-machine project. But much of the time our understanding of the features that that VM will have, say, three years from now is vague. We know that it will be the VM under Rakudo Perl 6, but what else? Many project members have their own individual projects they want to build on top of Parrot, and that motivates them to contribute to Parrot itself. Many project members derive tremendous intellectual satisfaction from hacking on Parrot, but without necessarily asking whether our work contributes in a focused way to the building of a new VM. So we continue in the project as long as it continues to pique our intellectual curiosity or -- too often -- until real life problems rob us of the time and energy needed to continue.

Need for More Than Itch Scratching

Scratching the itch of individual intellectual curiosity is a fine motivation for contributing to an open-source project. But we're at the point where an additional motivation is necessary for Parrot to thrive: the creation of a technology that other people really want to use. Put more simply, albeit in the language of business, we need to focus much more on delivering an exciting product.

Speaking Personally

Let me make this more concrete by speaking personally. By this time of year in 2006 I had contributed more than a dozen distributions to CPAN and spoken at YAPCs in Ottawa, Buffalo, Toronto and Chicago. But I had run out of ideas for new CPAN distros and was simply getting bored. I needed a distraction from family health problems and decided to attend a hackathon in the Chicago suburbs organized by Andy Lester and Pete Krawczyk. The leader of the group I was going to hack with didn't show up. Jerry Gay (particle) and several other Parrot contributors were there. When I asked for something to do, Jerry remembered my talks on Perl testing and said, "Here, start writing some tests for these Parrot build tools." The rest is history -- or, at least, my history.

I was thrilled to have something to do, and even more thrilled to be, for the first time, contributing to a collective open-source project. I had a commit bit and I was hacking with the pros! I had no understanding of what a virtual machine was supposed to be. True, I felt that what I was doing would ultimately contribute to the success of Perl 6. But my main motivation was the intellectual and emotional satisfaction I got from contributing to a major OS project -- regardless of what its ultimate product was supposed to be.

That was fine for several years, but eventually I reached the point where I had done all that Parrot needed in my particular specialty area: writing tests of its Perl 5 components. Then, at a Perl Seminar New York meeting last May, I heard a presentation by , co-author of The Design and Implementation of the FreeBSD Operating System and a leading contributor to the FreeBSD project. In response to a question about differences between the BSD and GNU licenses, George said bluntly, "We want our code to be used [by other people]."

We Want Our Code to Be Used

The three most important words in George's statement were: we, our and used. Note the use of the first-person plural rather than the first-person singular: "We want (to achieve a collective goal)" rather than simply "I want (to be part of an OS project)." Note also the motivation: We want our code to be used, rather than simply "I want to scratch my intellectual itch by coding."

Let's explore the implications of "We want our code to be used."

Parrot Needs a Product

If we want our code to be used by other people, then the code has to be in a useable form and it has to meet the technological needs of its users. Parrot has some great concepts, some great contributors and, in many ways, some good development processes. But we're kidding ourselves if we think we have a great product at this point in time. If we were trying to charge money for Parrot right now, we'd be lucky to make a single sale. If we were to define a major user of Parrot as "an open-source project or company which is building an application on top of Parrot and which itself has more than two developers," then we'd be forced to say that we have only one major user -- Rakudo Perl, which could also be characterized as a great idea with great contributors but not yet a great product. As whiteknight has argued, we don't have something we can confidently pitch to other projects or organizations.

Just Asking ...

We need to start asking -- and answering -- questions like these:

  • Who are the potential users of a virtual machine?
  • What functionality would they be looking for? Which features are most important?
  • Of those features, what does Parrot already have and what still needs creation? In what order do those new features need to be created?

Parrot as Project and Process

Of course, once we start asking questions like those, we very quickly have to start asking questions about ourselves, particularly ourselves in relation to the human collective known as the Parrot project. We need to ask questions like these?

  • Once we identify what needs to be done, how do we organize our all-volunteer, worldwide group of contributors to create those features?
  • What internal division of labor -- or, better put, roles -- do we need to adopt to reach our goals?
  • Which roles can be played by individuals and which need to be played by teams?
  • All of us have to fit our work on Parrot into schedules where families, jobs and relationships necessarily take priority. When 'real life' problems arise, can we adjust our level of contributions to Parrot so that we can hang in there for the long run?
  • How do we motivate ourselves to keep pushing forward?


This is enough for one weblog post. Thank you for reading this far. At this point, I'm going to start reading the posts by other Parrot contributors cited above. I hope you do as well.