From: Eivind Eklund Date: 2007-11-28T02:10:41+09:00 Subject: Re: So, here's a challenge! On Nov 27, 2007 4:14 PM, M. Edward (Ed) Borasky wrote: > Jari Williamsson wrote: > > Why are there so few projects on Rubyforge that leave their alpha/beta > > stages to Production/Stable? Why are there so few libs with really good > > documentation? Why is there not even good documentation on how to create > > a Gem or maintaining it with Hoe? Why are there so few documentation > > packages that use anything other than the old frame-based default > > template? And so on. > > Well ... there are a finite number of developers but a potentially > infinite number of good ideas for projects. Given that, projects tend to > self-organize around "leaders" and tend towards a distribution where > there are a few large successful projects like Rails, RSpec and Ruby > itself, and a few small successful projects like the One-Click > Installer, RubyGems, Rake, Hoe, ZenTest and Heckle. The rest of the > infinite number of good ideas are one-person projects that probably > don't go anywhere. True. To the degree this is a problem - and in a lot of cases, it is - it is a combined culture and tools problem. The tools we have empatise people people working alone, rather than letting other people into your code. For instance, RubyGems shuffle the gems production process towards the original developer, and shuffle the use of the code away from hacking. Using the default include method it isn't even possible to use code checked directly out of version control. RubyForge defaults to using centralized version control systems having access only for the initiating developer, making it impossible for somebody else to pick up if the developer falls off the face of the earth. The install/build tools people use (e.g, Rake) and packaging tools doesn't enforce the structure of the source files/directory layout, so we don't get easy hackability of code that's developed, so it is harder than necessary for somebody to take over an old project. Same with the fact that we use a number of different underlying frameworks, such as Test::Unit vs RSpec. Same with the fact that we use different version control systems. Same with the lack of a generally trusted group that can "take over support for projects", at least to the level where it is possible for the group to assign a new maintainer if the old maintainer disappear. The only person that is generally trusted is matz, and he's not into that kind of thing. All of this stuff is resolvable. It does require quite a bit of effort, though, and probably taking one thing at a time. We had a project that tried to handle a lot of it (RPA - www.rubyarchive.org) - unfortunately, it died due to a number of unfortunate events (including me not finding enough time/personal capacity to contribute more than ideas). The Wiki there should still include the design for a system that handle much of this; though, if I was to direct effort to fixing all this today, I would probably start with picking low-hanging fruit. Like maknig RubyForge default to asking for "Who is going to be backup maintainer?" on creating a project, and providing a small team to function as "default backup maintainer" (which just give other people somewhere to take over if the original maintainer stop having time for the project). Eivind.