Re: First draft of "OROCOS II" proposal...

On Fri, 27 Jun 2003, Monica Reggiani wrote:

> we are new posters to the list, but we have been following the discussion 
> closely. Here are our 2(euro)cents about OrocosII.
Thanks! I am very glad there are so many critical comments coming in :-)

> The project, as remarked by others, is ambitious and very broad in
> scope. Open source software helps in managing complexity and
> achieving goals, but, in our opinion, the open source development
> model should be retained as well. 

Why wouldn't we be able to do so?

> Here are a few remarks, borrowed from the essay "The Cathedral and
> the Bazaar" by E. Raymond, which show how the proposed organization
> fails to meet the OSS development model requirements.

Are you still taking Raymond's words as the one and only thruth? :-)

Were Raymond is wrong is that open source in the Cathedral model is
_very, very_ bad in _design_. It's _very, very_ good in implementation
and maintenance and support.
So, the project has a core which is responsible for design. That will
be as open as possible can. The same thing was/is true for Orocos-I,
but this experience proves that I am right: the amount of feedback on
all the design issues that have been posted on the orocos mailinglist
(not just by Leuven, Stockholm or Toulouse, but also by others such as
Ulm) has generated _negligable_ feedback...

> 1- "The importance of having users"
For the implementation parts of the projects, this is what we aim at:
linking with existing projects that _have_ users (RTAI, all sorts of
CORBA orbs, octave, Coin3D, ...).

> 2- "One cannot code from the ground up in bazaar style"
> "One can test, debug and improve in bazaar style, but it would be
> very hard to originate a project in bazaar mode. Linus didn't try
> it. Your nascent developer community needs to have something
> runnable and testable to play with."
And the step before that is even more indispensable: good design.

The controls field is now sufficiently mature that these designs are
not revolutionary: there are tons of systems that work already, and
that work fine. The project's goals are: to learn from these successes,
to decouple generic stuff from application-dependent things, to refactor
existing solutions, and to add new designs where needed.

[...]
> 3- "Release early, release often", even if "crude, buggy, and undocumented"

We got about zero feedback on the code released already in Orocos...

> This requirement doesn't seem to be met by a rigid project structure. 

Where do I suggest a rigid project structure? By limiting the core to
3 academic partners, rigidity is avoided to the largest extent
possible.

[...]
> The project needs a coordinator, and possibly sub-coordinators, a la' OSS 
> development model style (evaluating contributions, deciding what to 
> incorporate in releases, releasing software, etc.)

I will take on that job, until better people volunteer :-) We are
still far away, however, from the luxury of having the need to refuse
contributions and select from the available alternatives...

> Having a small number of accademic institutions coordinating the whole effort 
> is a good idea, provided that they indeed operate as open-source project 
> coordinators.
That's why good experience with open source projects is a prime
requirement for project partners.

> 5- An analysis of the current Orocos(-I) project could help.
> Despite the promising results achieved, the number of actors
> involved has been too limited. Maybe because code documentation and
> description about the goals of the platforms were not fully
> completed, or were lagging behind the project?  
No, because the initial effort of producing a useable code base is
very high! It would have been no problem to put a controller on top of
RTAI or RTLinux, but that would just be one of the large set of
under-designed projects...

> We believe that these deficiencies are due to the lack of a wider
> audience or comunity experimenting the platforms and, therefore,
> contributing to Orocos with questions and requirements.
I fully agree!

Herman
-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480