gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep moving forward


From: Gregory John Casamento
Subject: Re: GNUstep moving forward
Date: Sun, 23 Oct 2005 07:35:30 -0700 (PDT)

Stefan,

--- Stefan Urbanek <address@hidden> wrote:

> 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 

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.

> 2. GNUstep lacks attractor for users (this adds to the impact on 1.)

We need more apps to make this happen.

> 3. adoption (first contact, first setup, first installation) of  
> GNUstep is very difficult

It would be nice if we could simplify things for users to make it easier to
install.

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

> 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

Later, GJC

Gregory John Casamento 
-- CEO/President Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]