Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

  (email not shown publicly)
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Monday August 01, 2005
01:46 PM

class dbi community explosion

[ #26020 ]

Well, I suppose it was just a matter of time before I said something about this. I love Class::DBI, I use it all the time, it makes me happy, and it had a very good mailing list community. For a while, Tony had been taking flak for not having released a new Class::DBI. He got more and more defensive about it, so the peanut gallery got more and more demanding.

Eventually, Matt Trout mentioned he was going to release a new experimental POOP system called DBIx::Class (or something like that). It looked potentially interesting, and Tony was friendly to the posts, taking part in the conversation. Eventually, though, an argument about multiple inheritance and mixins showed up and turned nasty. There was some banning, some childishness, and eventually the list closed down. Everyone knows the story by now, or can find it elsewhere.

I think the core question raised by the whole affair is "What is the correct relationship between a CPAN module author and the module users?" Tony's expressed opinion was something like, "I do what I choose to do and you get to enjoy the fruits of my labor." I think this is fair, but I don't think it's the normal case, so users get irked.

Some of the people on the list seem to feel like Tony had a number of implicit responsibilities like, "fix the bugs I care about soon" and "release at short regular intervals, no matter what."

In the end, I think the problem was that Tony really did want to provide a great product, but he didn't want to provide what his consumers thought they wanted. He wanted to work on 1.0, while 0.96 was pretty bug free, but the users wanted a 0.97 with a few tiny changes. That seems like a recipe for resentment, and that's pretty much what happened.

What a lot of projects do in this situation is not fork, but branch. Someone maintains Linux 2.4 while Linux 2.5 or 2.6 moves forward. It would have been simple for Tony to make someone the pumpking of maintcdbi while he worked on bleadcdbi. I don't know what his reasoning was for not doing that, although it may have just been, "I don't want Class::DBI 0.96 to change in ways I don't like, especially if it becomes less stable."

That's what I would've liked to see, largely because one of my dists, Class-DBI-MSSQL, can't work quite properly without a patch to Class::DBI, because of how defaults and NULLs work in MSSQL. Of course, this gets back to the question, "What is Tony's responsibility to me?"

I wish I had a good answer for that. Clearly the most true answer is, "None," but I don't think it's the answer that's the answer I want most people to accept. Then again, I have an ulterior motive, don't I?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Wouldn't it be great if existing modules could be modified by some kind of standardized plug-in architecture, so that the original module could be used without the plug-in or, at the user's option, could be used with a plug-in that would contain the desired enhancement/modification/perceived bugfix? I guess that would prevent forking, in a sense.

    Caution: I barely know what I'm talking about :-)

  • The problem as I see it (which is subjective), is that those patches exist. We do not expect Tony to write them for use from scratch. But it looks to me, that he just plainly refused to even take a look at those patches that were submitted.

    Of course that'll irk people up, especially those who wrote and submitted the patches, proud of their work, and being treated like some talentless freshman junior programmer.
    • Actually applying patches to a large project like CDBI is still nontrivial, especially if they are based on older code than under development.

      Also I haven't seen Tony dismiss any out of hand, he just has higher expectations than most when it comes to patches and fixes - not just good code, but tests and a good reason to change stuff.

      Patches have got in, and he has been working on making the infrastructure of the code easier and more consistent to extend.

      Unfortunately a large number of patches that most peop

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
  • "What is the correct relationship between a CPAN module author and the module users?"

    Easy. While we the amount of maintenance and support provided (or lack thereof) is debatable, how about starting with something like:

    • The module author should not threaten to sue users over stupid things.