Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Choosing modules - community matters or just technical merits?

by zby (Vicar)
on Jan 31, 2008 at 22:36 UTC ( #665468=perlmeditation: print w/ replies, xml ) Need Help??

How do you choose modules for your projects? Do you check the health of the communities around them or you just check the technical merits of it? On one hand the community is only indirectly important - all you need is a good module. And if it is technically good module then sure it must have been produced by a healthy community? But on the other hand you can only judge the current technical state of a module while the future of it is usually as important and future is largely dependent on the community supporting it.

So what do you do? Do you check the mailing list archives looking for treatment of submitted patches and bug reports, how newbies are welcomed and how conflicts are resolved?

Update: And yes I do ask this because I was recently bitten by that community side of things. I will not tell what project it was - I don't want to scare some more cool headed people who might join it and improve the situation a bit.

Comment on Choosing modules - community matters or just technical merits?
Re: Choosing modules - community matters or just technical merits?
by perrin (Chancellor) on Jan 31, 2008 at 22:42 UTC
    Community is hugely important. If I have two or more options that both seem technically adequate, I will always take the one with the more helpful mailing list. Rudeness or big egos on the mailing list will definitely make me think twice before using a module.

    Think about it: you will probably be using this module for a while, and are likely to want help with it at some point. Helpful (or at least friendly and easy to work with) authors are a major plus.

Re: Choosing modules - community matters or just technical merits?
by stvn (Monsignor) on Feb 01, 2008 at 02:36 UTC

    I find that with larger modules and/or "frameworks" the community is more important. Especially since when project reaches a certain point, it goes beyond the scope/brain of a single author and becomes truly a community effort. At that point, the strength of the community is usually directly tied to the success of the project. Personally I think a little in-fighting and occasional butting of heads is a good thing, it shows that the project is active and its developers/users are passionate, but beware of poisonous people they can bring it down.

    As for help, mailing lists are a good place to look, but Perl also has a pretty large IRC component as well, which should be taken into account. For instance the Pugs project took place largely on IRC, and occasionally spilled into the Perl 6 mailing lists. Of course IRC tends to sometimes be a little more abusive then mailing lists, but it can be a great way to get questions answered quickly.

    With smaller modules, or niche modules, there may not be a community because honestly the subject of the module is not that interesting. For these I usually judge these modules on a few criteria:

    • Module author reputation

      This is not always easy to determine, but if an authors work is well regarded among those I respect, its a point in favor.

    • Quality of tests and documentation

      Some people write bad tests and good docs, others write good tests and bad docs, some (in rare cases) write both. IMO you can always glean "documentation" from good tests, so I favor them. An absence of both is pretty much a giant warning flag for me, so I tend to avoid those modules unless ...

    • Quality of code

      If I don't trust the authors work already or if their tests and/or docs are not excellent, but the module still seems useful, I do some source diving. I am looking for well structured clean code, solid design and algorithms and very few "# XXX - not sure why this is needed, but it works ;)" type comments. This is also important since if I am at this stage, I have resigned myself to the possibility I might need to either heavily patch, take-over, fork, or re-write this module myself depending on the openness of the author.

    Anyway, thats my 2 cents.

    -stvn
      Hi,

      To help in the judgment of the quality (or Kwalitee) of a modulo, you can use cpants.org, and cpantester.

      With the first, you can check the Kwalitee of a module, or better of the author. (The Kwalitte is a metric base in this like: has_tests; buildtool_not_executable; has_version; no_pod_errors; use_strict; etc).
      And with the later the success of the test for specific versions and platforms.
Re: Choosing modules - community matters or just technical merits?
by talexb (Canon) on Feb 01, 2008 at 12:21 UTC

    This is timely -- last night at the Perlmongers meeting we had a presentation on Rose::HTML::Form, and six months ago we had one on Rose::DB::Object.

    After the first Rose presentation I was intrigued, and looked at the IRC channel #rdbo -- there were, I think, three people there, and I put Rose back on the shelf. The presenter last night commented that John, the author, was amazingly helpful on the mailing list, and that the documentation was 'fantastic' -- so maybe I need to have another look at Rose.

    Certainly Toolkit::Template Template::Toolkit was a bit of a leap when I started using it -- but the documentation was very good, and there were enough people using it here on Perlmonks that I could get by. I tried DBIx::Class about a year ago and couldn't understand it -- the users on the IRC channel (and in particular mst) tried hard to help me, but I couldn't get it in the time I had allotted.

    I think it's always a good idea to be tinkering with something new -- last night's meeting has suggested not only Rose but also SQL::Abstract. And I may take another swing at DBIx::Class, especially if I can compare it with Rose.

    Update: Correct the name of Template::Toolkit. Thanks alexm. (Dyslexia sneaks up on you sometimes.)

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      The support for Rose::DB::Object is fantastic. Very helpful author and plenty of other contributors on the mailing list.

      There may be some kind of generation gap with IRC. To me, it seems like a horrible way to get answers to tricky technical questions: no useful archive, tons of noise, and a general time sink. However, other people obviously like it.

      I'd recommend skipping SQL::Abstract and using the query builder from Rose::DB::Object instead. It's generic and can be used to build more sophisticated SQL than SQL::Abstract.

          The support for Rose::DB::Object is fantastic. Very helpful author and plenty of other contributors on the mailing list.

        That's what I heard .. and the speaker last night did mention he'd started to see some postings on jobs.perl.org asking for Rose .. that's always promising.

          There may be some kind of generation gap with IRC. To me, it seems like a horrible way to get answers to tricky technical questions: no useful archive, tons of noise, and a general time sink. However, other people obviously like it.

        Going to an IRC channel for technical support is a bit of a leap of faith. I visit #perl irregularly, but enough that I know and avoid the idiots, and also know who the knowledgeable folks are. Not unlike seeing Congress or Parliament in action, I suppose -- there's a lot of talking going on, but surprisingly, some of it is significant and meaningful. It's even a bit like fishing .. some days, you get lucky, and some days, the fish just aren't biting. Not that I have the patience for fishing. Sailing, yes. Fishing, no.

          I'd recommend skipping SQL::Abstract and using the query builder from Rose::DB::Object instead. It's generic and can be used to build more sophisticated SQL than SQL::Abstract.

        Coming from you, I'll buy that. Looks like there's no yum package, so I'm running CPAN to install it. Thanks for the feedback.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Choosing modules - community matters or just technical merits?
by sundialsvc4 (Abbot) on Feb 01, 2008 at 16:48 UTC

    A community collection like CPAN is definitely a “mixed bag,” and no doubt a fair number of the vegetables in that bag are rotten, but most of them are quite good. There are a handful of routines that have been around a long time, have strong outside web-sites demonstrating active support, have a large number of request tickets posted against them but none of them are still “open,” and so on. The hallmarks of kwalitee are there to be found.

    Before starting on a project, I always find it useful to spend some “kwalitee tyme” looking carefully through CPAN to see what is out there. In particular, I want to see the approach that various authors have used, knowing that they felt that the work was useful enough that they wanted to make it public. Sometimes that code is a real eye-opener.

    What I don't try to do is to use the CPAN code as a “hope-it-works black-box.” I'm happy to use it as a short-cut to what I am doing, and even as a strong influencer of my design ideas, but not as a replacement for my own thinking. (I think you understand what I am trying to say here. I am on cup-of-coffee number-one.)

Re: Choosing modules - community matters or just technical merits?
by redhotpenguin (Deacon) on Feb 02, 2008 at 05:49 UTC

    Community is big. I've seen one major Perl ORM and one major framework get temporarily shut down because of people problems. In one case, a CPAN administrator stepped in to mediate the problem. When the ORM project was shut down temporarily, my first thought was "What will I use if this never comes back?".

    I think everyone has had their ego involved with their code at some point or another in their career. I know I have, but I try to make conscious efforts to become detached from it. This is a problem with coding teams, egos clash, and the code goes to shit. That ORM I mentioned hasn't really recovered from the meltdown. I try to keep an open mind, but I'll let you draw your own conclusions.

    Be careful of a community with too many zealots and not enough level headed individuals. Enthusiasm is great, but when it turns predatory, or I might even say cannibalistic in the event the predation is towards other Perl modules, people end up looking like idiots and the Perl community as a whole suffers. We're all members of the Perl community.

      I'm the supposed "associate of the troublemaker" here.

      He's referring to Class::DBI and DBIx::Class - except that I always was and still am on good terms with Tony Bowden (the maintainer of Class::DBI) and in fact he supported the creation of DBIx::Class, which was announced -before- the blow-up on the class-dbi mailing list (sadly by about two days, so lots of people managed to get the wrong impression) after a week's worth of offlist discussion between myself and Tony.

      Sure, draw your own conclusions. But draw them from what actually happened, please - I was as unhappy about the demise of the list as anybody else and in fact the dbix-class list took Class::DBI questions during its first few weeks until the replacement cdbi-talk list could be set up. Anybody who doesn't believe me about this is welcome to go ask Tony :)

      -- mst

        hi mst

        Thanks for clearing that up, I did have an impression that was different than what actually happened. I had some second thoughts and updated my post to remove the troublemaker statement, I didn't notice that you had posted a reply until today. I can get a bit grumpy at times :)

        For what it is worth, I'm a heavy DBIx::Class user, I've found it to be quite good.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://665468]
Approved by Errto
Front-paged by lidden
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2014-09-21 12:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (168 votes), past polls