[openbeos-cdt] Re: CDT regrouping: why and how?

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: openbeos-cdt@xxxxxxxxxxxxx
  • Date: Fri, 13 Nov 2009 11:23:56 +0100


On 2009-11-06 at 10:47:50 [+0100], Eddy Groen <eddyspeeder@xxxxxxxxx> wrote:
> Question: what should be our first few steps to really make sure the CDT 
> does take off?

Your first tasks is to understand what works and what doesn't work in a 
volunteer driven open source project. To me it seems you are approaching 
this somewhat like someone running a company with people working on what 
they are told to work on for money.

The CDT can be successful. Over the years, we have had many elaborate 
discussions about future UI functionality, features and design. Within 
those discussions, some insanely useful ideas have been expressed. If the 
CDT has discussions like this here on this mailing list, it will just be 
that: Yet more nice dicussions with useful ideas, just on it's own 
dedicated mailing list. Since it's basically the same thing, not anything 
more will come of it than before.

What needs to happen is that the CDT takes it one step further. After 
discussions have happened, someone needs to put the cool ideas into a 
specification. Depending on the complexity of the item being discussed, 
this could either mean a simple Trac enhencement ticket, or an elaborate 
wiki page, preferrably also on Trac. What communication means the CDT 
choses to produce specifications is irrelevant, as long as the end result 
are developer visible, ready to be picked, thought-through (!) and 
elaborately explained, specifications at a central location.

The CDT will gain credibility with the developers *only* by producing 
quality specifications, ready to be picked for implementation. Ready to be 
pointed at when someone comes along looking for something to do. You need 
to realize that by doing what I outlined above, some people have already 
been successful in being influential in the CDT domain. For example, 
Waldemar Kornewald produced specifications (although in retrospect, they 
have been way to brief), and Humdinger produced some nice pages for CDT 
domain change suggestions. This is something that would work, provided the 
CDT understands this and is actually able to do this, rather than everyone 
just expressing what they think should/must be done, like I am doing here. 

What will definitely not work, is if the CDT is "assigned" responsibility 
and decision making power. There is no such thing in the Haiku project, but 
people joining us frequently fail to understand this. Everyone who has ever 
gained any influence in the project has done so by doing work, or providing 
pieces of work ready to be used by others. The door is wide open for a CDT 
to achieve the same, but it won't be because someone "influential" says the 
CDT is now tasked with such and such.

Find something you want to improve. Come up with an initial idea. Discuss 
it by any means necessary. But then, do the extra work of putting it into a 
specification that shows how something works and explains the 
thoughts/reasons behind it. Put it somewhere visible and start pointing 
people at it. This is your route to success. Even a single person can do 
(and has done) this and gained influence accordingly. You don't even need a 
team hierarchy, as long as a single one of you can motivate himselves to 
digest information and put it on a Wiki page.

Best regards,

Other related posts: