I think that Geoff has stated this well. Yes, there are some problems with ROS, but there are problems with any large-scale open source project. I think that the core of ROS is very well developed and maintained in general, and there are many people (WG and not) that are dedicated to evolving ROS to users needs. On the other hand, there are a large number of stacks floating around in the ROS ecosystem, and there are various levels of dedication to the code. There are people who are truly devoted to maintaining their respective stacks (Jack O'Quin comes to mind), but at the same time, there are many development efforts that are a one off or prototype. In my opinion, I want the prototype code available, so that I may use it eventually, and I don't want to "punish" the developer, by making them do feature requests, etc. After all, they aren't getting paid to give this stuff to the community. I think that much of what has been expressed is interesting. I am particularly interested in the idea of "marking" stacks, so that people can make decisions about the amount of work involved. I think that the Python has a good method of doing this with the Cheese Shop (pypi.python.org), where packages are marked with tags 1-7, representing planning to mature + inactive. They additionally have tags for other reasons, such as platform, purpose, and category. A full list can be viewed at http://pypi.python.org/pypi?%3Aaction=list_classifiers Maybe this is something that we can add to the manifest, which can be in turn added to the wiki? ~mc On Thu, Jul 19, 2012 at 8:00 PM, Geoffrey Biggs wrote: > On 20 July 2012 04:49, Jonathan Bohren wrote: > > Does anyone else feel like we need some better way to coordinate these > > things to prevent code death or such fragmentation from happening to the > ros > > community? My recent experiences have made me concerned for the future > > health of the ecosystem. > > I don't necessarily agree with this. I think the problem described is > the same problem faced by Linux in general (the operating system, not > the kernel). There are thousands of abandoned software packages > available for Linux, a large proportion of which are available through > various distributions' package managers despite being orphaned. I > think the approach to this issue can be decided based on what ROS's > goal actually is: > > Is ROS meant to be a single, cohesive software project with > distributed development teams working on various parts of it? In this > case, I think that centralised ticket management makes sense - but it > also requires someone to sit at the centre and maintain that > infrastructure. > > Is ROS meant to be an operating system style thing with lots of > independent packages developed by independent teams? In this case, > then the current approach should be maintained, and we must accept its > warts, working around them as appropriate. > > I personally think ROS is, or at least should be, the second option, > and we should look at how various distros manage these problems. For > example, Gentoo removes unmaintained packages from its repository and > relies on them being provided by overlays managed by the people who > care about those packages. Using a package from an overlay tells you > you're not getting the same level of support. Debian/Ubuntu's > multiverse and PPAs could be seen as doing something similar. > > I think that Thibault's idea is the best approach we could take right > now. Giving people the information they need to make an informed > choice of packages is more useful than trying to kickstart back into > development a package that does not necessarily need it. I often use > Wikipedia's "Last release date" information when choosing amongst > alternatives for a piece of software. > > Geoff > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > -- Michael Carroll http://mjcarroll.net | carroll.michael@gmail.com | 513.407.1337