in reply to No, "We" Don't Have to Do Anything

(I know chromatic's not really talking about me..., or at least I hope he's not :)

I thought about not using "we", but I decided to take on some of the blame. I was one of the original people in the room when we decided to do Perl 6. I was the guy who was supposed to work on promoting Perl 6 to the wider community.

I left the project when I realized that there wasn't a plan, people didn't want a plan, and we were basically marketing hype hoping that someone would come up with an implementation. We called it "the community's rewrite".

Since then, I've contributed in much more quiet, behind the scenes ways not directly related to the development. I'd still like to get a Perl 6 article into The Perl Review, but people haven't had interesting things to say about it (that we haven't heard before).

I'm not complaining about the Perl 6 process or how much we've accomplished. I'm ready to support whatever Perl 6 turns out to be. I'm not telling anyone what they should do to implement Perl 6 or what features should be in it. I'm ready to publish about it, write books about it, promote it, and so on. I'll gladly cheerlead whatever Perl 6 is. I'm ready to do my part (the same part I was going to do officially), but outside of the proper project.

My problem is people pretending that the process is working well and that people asking what's going on are complainers we should ignore. If you're producing something for other people to use, you should pay attention to your user base. Otherwise, use Python :)

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Replies are listed 'Best First'.
Re^2: No, "We" Don't Have to Do Anything
by Anonymous Monk on Feb 23, 2006 at 15:23 UTC
    There are some FOSS projects that have well defined leaders ... namely the Linux kernel (still feudal in many ways), Python (Guido), and Ruby (Matz), and in general benevolent dictatorship can be a good steering force. Larry did a good job being insert-Diety-here too. Perl 6 appears to still be in commitee, which, for good or bad. The real software engineering question is this: can projects designed en masse like Perl 6 arrive at a workable consensus?

    The current examples going through my mind now are industry standard things like Bluetooth, CIM, and W3C's WSDL/SOAP/etc ... quite the antithesis of our favorite software products in terms of simplicity and transparency.

    Not making a comment either way, just thinking... these things took a long time to evolve and still haven't stabilized, while in general projects with a strong guiding lead (not dictator) have a better chance of communicating vision and bringing contributers in.

    For the percieved "people are complaining" problem chromatic is complaining about to stop, you need good external organization and a way for those people to contribute, rather than just trying to make heads-or-tails of a mailing list, which they'll subscribe to, get confused, and eventually leave. And better defined leadership, timetables (however long), and better laid-out goals help too.

    Finally, don't alienate your critics. They're telling you something. First and foremost, they want your product.

Re^2: No, "We" Don't Have to Do Anything
by Cap'n Steve (Friar) on Feb 23, 2006 at 06:10 UTC
    "If you're producing something for other people to use, you should pay attention to your user base."

    I think that's actually a major weakness of open source software in general. I've never been involved in Perl development (waaaay out of my league), but I've seen several other projects where the developers seem to have gone a bit power-mad, ignoring suggestions and even bug reports that have somehow offended them.

      There’s a balance to be struck. If you say yes to everything, you end up making unusable incoherent bloatware. Design is difficult, and committees do it horribly, because it is mostly about leaving out everything that isn’t appropriate. As Linus Torvalds says, his biggest job is saying no to new features.

      But I don’t dispute that few projects find the right balance.

      Makeshifts last the longest.