Re: GNUstep moving forward

[Stefan Urbanek]

Hi,

(a bit longer reply or rather alternative. If you like, go directly  
at the end with suggested next steps)

On 22.10.2005, at 12:46, 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
2. GNUstep lacks attractor for users (this adds to the impact on 1.)
3. adoption (first contact, first setup, first installation) of  
GNUstep is very difficult

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

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.

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.

Sharing your knowledge about GNUstep is investment in time. Shared  
knowledge will decrease obscurity and therefore decrease entry  
barrier for potential developers.

From the management point of view, as open-source project has two  
major kinds of developers: voulentary ones and company developers.  
Voulentary developers do what they like to do. Company developers  
develop manily to satisfy company needs ignoring for them irrelevant  
parts. Very roughly speaking, of course. We all know, that main  
problem is lack of interested developers and time. Therefore the  
person with a role manager or leader in this case should allocate  
more resources for single task to decrease risk of non-implementation.

Please, do not underestimate the importance of good project and  
knowledge management in development process. If a project is open- 
source, it does not mean, that it should be only programming driven  
as it is widely thought...

Suggested next steps:

- create roadmap with breakdown do implementable and understandable  
tasks
- collect current knowledge
- learn what we do not know
- learn what we do not know and we need to know
- define project roles (and use person redundancy)
and last, but not least:
- observe and copy behaviour of successful players (*)


Regards,

Stefan Urbanek

(*) there are many inferior projects that have great success compared  
to their alternatives. If it is not in the "idea behind", then whay  
it is? Go, find out and apply to GNUstep. Reasons are various,  
including: community suppport, poject management, knowledge  
management, publicity and visibility ("if it is visible, it should be  
good, no?"), friendliness, openness, flashiness, coolness, colourfulness
--
http://stefan.agentfarms.net

First they ignore you, then they laugh at you, then they fight you,  
then you win.
- Mahatma Gandhi