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

Dear all,

we are new posters to the list, but we have been following the discussion 
closely. Here are our 2(euro)cents about OrocosII.

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. The 
proposed consortium structure doesn't seem compatible with this model and 
still resembles too much conventional (strictly hierarchical) EU projects. 
(The exception being the travel grants for non-partners).

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.

1- "The importance of having users"
This issue is essential in an OSS project. How can users be involved? There is 
indeed a large community of potential users that could find interesting the 
problems addressed by the project, but they need to start using the code in 
order to "diagnosting problems, suggesting fixes, and help improve the code 
far more quickly than you could unaided".

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."

The starting point should be clear so that people can start contributing since 
the beginning of the project. Having a starting point can also help people 
understand which is the current goal of the project more clearly and maybe 
believe that it is going to "evolve into something really neat in the 
foreseeable future."

What software is already available and can be immediately contributed to the 
project as its intial base?

3- "Release early, release often", even if "crude, buggy, and undocumented"
This requirement doesn't seem to be met by a rigid project structure. A 
project goal must be to have early and continuous community involvement. (Of 
course, for complex software projects, the goal is to have as many eyeballs 
as possible. "Given enough eyeballs, all bugs are shallow".)

4- Coordination structure (see section "Necessary Preconditions" of Raymomd's 
essay)

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.)

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.

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?  (In trying to catch up with the project, sometimes we have had to 
dig into the code to understand the purpose of a class).

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.


We will be travelling today and next week (ICAR and elsewhere), with 
intermittent access to the net.

Stefano Caselli & Monica Reggiani

--  
Dip. di Ingegneria dell'Informazione, Universita' degli Studi di Parma  
Parco Area delle Scienze, 181A  I-43100 Parma Italy
Phone:+39 - (0521) - 90.61.14  Fax:  +39 - (0521) - 90.57.23 
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html