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
<geoffrey.biggs@aist.go.jp> wrote:
On 20 July 2012 04:49, Jonathan Bohren <
jonathan.bohren@gmail.com> 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.
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
--
Michael Carroll
http://mjcarroll.net |
carroll.michael@gmail.com | 513.407.1337