Will Class::DBI fork?

by brian d foy

A long time ago in a galaxy far, far away, Michael Schwern created a Perl module for objects to represent database queries. You didn't need SQL or other fancy things. Through various magics, it figured it all out behind-the-scenes and it worked. He called it Class::DBI, and it was good.

Later, Tony Bowden took over the lead maintenance role, set up a mailing list and wiki, and that was good too. One of the hallmarks of a good open source project is that you can pass on the reins to someone else, not only because people want to work on it but because a lot of people want to use it (those always don't go together ;)

This week, there was a bit of a dust-up on the Class::DBI mailing list. You can still find the archives, but Tony killed the list. (Fear not, there is a new one already, even if it is just temporary).

Sebastian Riedel and Tony apparently had some off-list as well as on-list scuffles. Tony kicked Sebastian off the list and Sebastian came right back onto the list. Rinse, repeat. Finally Tony threatens legal action.

Update: Wednesday morning In a show of his willingness to compromise, Sebastian voluntarily removed his post from use.Perl. I'm optimistic that this can defuse most of the situation.

Sebastian created used an his account on Use.perl (Correction: Sebastian tells me he had the account for a while, but hadn't used it to post to the journal before) and posted to post his side of the story along with some private email between him and Tony in "What the hell is going on in Tony Bowden's head?". However crass that may be, he did it. He also disabled didn't enable comments so and people couldn't reply to his post (Correction: Sebastian tells me that this was uninentional. Indeed, whether comments are turned on or off is a preferences setting and not something you have to decide for each entry). From other posts and some private personal email with other people, I've gathered there were some disagreements about the feature set that would make it into the next release and how those would work. That seems to be the sort of thing that causes these sorts of problems: two people convinced they are right and unable to work together because of it.

Schwern replied in his own Use.perl journal that Sebastian fudged the story a little bit by linking to a seemingly innocent part of the email exchange. Schwern provided the links that show a lot of inflammatory language from Sebastian.

It gets worse though. Since Sebastian posted to Use.perl and Tony doesn't like what Sebastian says, Tony threatens Use.perl (a VA project Correction: Chris Nador owns Use.perl, but VA sponsors the site infrastructure) with legal action. Tony, a formerly respected member of the Perl community, now seems to think he has to burn down the village to save it.

No matter who's right, these things don't help either side. Indeed, as sigzero points out, this is just more fodder for people who think Perlers are a bunch ill-tempered miscreants. Where a rational person might just take the weekend off and let things blow over (or at least not inflame the situation), both sides seem to want to fight it out. They've forgotten that they both want a really cool module to get better, and maybe that means they don't have to kill each other to make it happen.

Who cares about these petty problems? A lot of people are using Class::DBI and they want to keep using it. It's not going to disappear. Even if Tony decided to delete every version on CPAN, the BackPAN still has all of the current and previous versions. Someone will just take his place.

The mostly sane workers and users really just want to get on with business, I've heard rumblings of a fork in Class::DBI. The only way around this might be to just bypass the personality problem by removing the personalities. I think that would tragic, even if it ends up being unavoidable. Can Class::DBI do that without bifurcating?

Do you think Class::DBI should fork?


7 Comments

teejay
2005-08-01 06:29:02
will C::DBI fork? Yes and No
No, C::DBI won't fork in the short to medium term. Tony is still actively working on it and both he and others use it too much to throw it away or let significant bugs cause a problem. He has said we will still be releasing 1.0 and 0.999 is available from his site.


At the same time there are other projects that either wrap or replace C::DBI, the DBIx::Class module is planned to be a legacy free alternative that is more suited to the direction and ideas of the Catalysterati, and there are also wrappers in the shape of Class::DBI::Sweet and Class::PINT (which is due to have another release shortly).


There are also a huge number of plugins and subclasses, and Tony has stated many times he would like to make plugins and extensions easier, more consistent to write.


As a heavy CDBI user I am not overly concerned, even if Tony refused to write another line, development could continue based on the publicly released code so far, even if under a different name. That isn't likely to happen though.

claco
2005-08-01 09:21:30
Fork It.
I've been pretty neutral up to this point. I use CDBI in Handel, and Tony has always been nice and helpful to me in email over the years.


However, this copyright stuff has sent me over the edge of diistraction. Right or wrong, this kind of crap is overcoming everything CDBI, and to some extent perl. It's time to cut the rope and fork it and move on. I'm looking forward to seeing what comes out of DBIx::Class, but we need more CDBI action on the table....after all, that's what started this mess, and it's not the first time it has come up.

itub
2005-08-01 09:34:50
I think it should fork
I agree that "The only way around this might be to just bypass the personality problem by removing the personalities."


I think many users will be reluctant to use a module that, even if it is great and very useful (I use it a lot!), it is maintained by a seemingly mentally unstable author that threatens to sue people for anything, from trying to subscribe to his mailing list, to quoting what he said, to posting the contents a wiki (a great portion of which was contributed by the users themselves).

Alkon
2005-08-02 13:32:22
No person - no problem
The only way around this might be to just bypass the personality problem by removing the personalities.


You obviously mean "No person - no problem" - what a nice idea.


This is a very bad-smelling approach to solving problems - sort of totalitarian one.

claco
2005-08-02 13:42:57
Does the Acme fork count?
http://search.cpan.org/dist/Acme-Class-DBI-NoThreats-0.96/
brian_d_foy
2005-08-02 14:13:12
No person - no problem
I don't mean "No person - no problem". I mean "No asshole - no problem".


You only think it's a bad-smelling approach, and I bet you use it everyday to decide you you are going to hang out with, make friends with, and so on.

Alkon
2005-08-02 15:47:34
No person - no problem
I don't mean "No person - no problem". I mean "No asshole - no problem".



I don't believe that "formerly respected" community member has turned into "asshole" overnight. Rather someone presents it as such. Especially that there is clearly a different view of the situation stated (that you link to as well).


You only think it's a bad-smelling approach, and I bet you use it everyday to decide you you are going to hang out with, make friends with, and so on.



Making new friends - may be, but it is definitely not the way to treat old friends, even former ones.


Moreover, "no person - no problem" problem-solving not only smells bad, but actually never solves problem...