On Mar 3, 2005, at 7:28 AM, Ilmari Heikkinen wrote:
> Throwing some thoughts into air:
>
> An archive of production-quality libraries, kept up-to-date, with the 
> archive tools included in the stdlib. A sort of "extended stdlib." 
> RPA? It has a sort of standardised good practices thing in it too ( 
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118064 ).
>
> It's a marketing problem aswell. If people don't know about it, they 
> won't use it.
>
> So the solution is three-fold:
> 1. agree on the "extended stdlib" tools and appoint a maintainer for 
> them
> 2. advertise the tools until everyone knows about them (and uses them)
> 3. provide advocacy on the good libraries in the form of news hype and 
> tutorials.
>
> The point is that the tool needs to be in the stdlib, its package 
> database needs to be maintained, and it needs positive exposure.

I don't think it's a given that just because a certain library gets 
knighted as part of an "extended stdlib" that it will automatically be 
well-maintained and well-documented. In fact, there are more than a few 
libs in the _actual_ stdlib that have fairly crummy documentation even 
today.

Sometimes I wonder if this could be helped with a little healthy 
competition. If you've got a little lib that competes with other little 
libs doing the same thing, you might be more eager to write docs and 
fix bugs. But if the community pre-emptively approves of code that sort 
of works but isn't documented at all, you're going to have less 
incentive to write docs for it.

It's sort of like running a race where everybody gets a medal; you're 
not going to run as hard. Maybe that sounds like a sort of Randian 
perspective on competition, but I think it's worth thinking about in 
the case of Ruby--especially given the way that certain libs were, 
IMNSHO, brought into the standard library too quickly.

Francis Hwang
http://fhwang.net/