Re: GNUstep moving forward

[Sheldon Gill]

Gregory John Casamento wrote:
> > > GNUstep has been relatively stagnant over the last several months  
> > > and it has
> > > become a cause for concern for me.
> >
> > I am observing the same thing and realised few reasons (ordered how  
> > they comeunder my fingers on keyboard):
> >
> > External issues:
> > 1. GNUstep desperately lacks an attractor for developers 
>
> Although we have Gorm and ProjectCenter, I believe we do need more to make
> GNUstep attractive to devs.   Some debugging (think MallocDebug) tools and
> other things might be nice in this regard.
>
> Also, a fully working ProjectCenter would be good as well.

I sort of agree with this. I feel it's more a symptom than a cause. We need 
better documentation and better support tools. To some degree these become self 
generating when the project is moving well with momentum.

> > 2. GNUstep lacks attractor for users (this adds to the impact on 1.)
>
> We need more apps to make this happen.

If you build it, they will come.
Better dev environment means better dev, a precursor to the apps.

> > Internal issues:
> > 4. GNUstep has no project management, nor resources management, nor  
> > task management
> > 5. GNUstep has no single achievable goal, neither short therm nor  
> > long term
>
>
> Both of these can be taken care of by the creation of a roadmap to show what
> the project is and will be doing in the future.

I disagree. Completely. A roadmap is not project management. It's not resource 
management. It's not even task management. It's an idea of where things are 
going, not an implementable plan of how to get there.

I do agree entirely that project management is a key issue. Probably THE issue. 
The size and complexity have grown beyond simple, organic organisation.

> > You have already mentioned some solutions that I have removed from  
> > this email, as they are already being discussed. Your suggestions  
> > address mainly points 2,3 and somehow point 1. But there is still  
> > problem 4 and 5.
> >
> > GNUstep developers and friends are pulling the rope on the same end,  
> > but to thousands of different directions :-) This reminds me a story  
> > for children by Czech writer Josef Capek in a book Of Dog and Cat.  
> > Dog (the dog) and Cat (the cat) wanted to bake a cake. They were  
> > putting in a pot everything they liked and they thought that would be  
> > good to have in the cake... "I like this, so I add it there" "Ok,  
> > that would be fine. I'll at that, because I like that and it is  
> > good" ... The cake was mixture only of "all good things", however at  
> > the end it was uneatable. We are baking similar cake too...
> >
> > Lack of larger picture, roadmap and kind of management affects  
> > development. Also lack of requirements specifications is making  
> > development of GNUstep much difficult and slow. Potential developers  
> > do not know what should be implemented, not speaking about how it  
> > should be developed.
> >
> > From management point of view, first step that should be done in  
> > GNUstep is detailed roadmap with very good task breakdown and  
> > expressend depencencies. For this I would suggest to either revive  
> > the 'Tasks' on savannah or use Wiki. With savannah one would have  
> > better task tracking, however on the wiki there would be better  
> > public visibility and accessibility, even it would be in a plain- 
> > text. I would vote for the wiki option.

I'd vote for savannah unless we have a better solution. The one I'd really like 
to see is one written around oOGO/gsweb...

> > Tasks should be laid in a tree-like structure with good breakdown.  
> > 'CORBA' is an example of very bad task. Yes, one should start with  
> > taks like 'Windows support', but then it should be broken into  
> > 'Installation', 'Pasteboard', 'UI', 'Distributed Objects', etc. It is  
> > still not enough, because neither current nor new developer would  
> > know, what should be implemented for 'pasteboard'. Therefore one who  
> > knows should write: 'implement handling of type XY this or that way'.
> >
> > Now back to the project, people, resources and time. Many, if not  
> > all, core gnustep developers complain that they do not have time. Ok,  
> > me neither. But I ask: "WHO IS GOING TO IMPLEMENT MISSING GNUSTEP  
> > PARTS, IF THE ONLY KNOW-HOW HOLDER IS YOU?". Answer is: noone.  
> > Solution: GET THE KNOW HOW OUT OF YOUR HEAD AND SHARE IT!. Please, if  
> > every core developer was able to find just a little bit of time to  
> > write unordered bulleted list of his observations or knowledge about  
> > GNUstep that would be really helpful. And most importantly, write  
> > what is missing. GNUstep developers do not even know what they do not  
> > know, not to say that they do not know what they do not know and they  
> > need to know.

This sort of thing would be very useful. If you take a look at NSTimeZone there 
is a lengthy comments section at the start which talks about the module and 
what it does. I wrote that original lengthy spiel. I should contribute such 
discussions to other modules.

I'd say, though, that a better solution is to identify those with the knowledge 
and interest/dedication for a particular module. Give a degree of ownership of 
different sections to particular developers. Let particular developers be 
acknowledged and recognised leads for specific tasks.

One big advantage of this approach is mentored development. Someone interested 
in a particular area can coordinate with the Owner and get good direction, 
feedback and possibly direct help.


Regards,
Sheldon