Re: The GNUstep Roadmap

[Alexander Malmberg]

First, I'll limit myself to core/ here, since I feel that's the most
important, and most relevant part wrt this discussion. The other parts
of "GNUstep" (and other projects around it) are fairly independent of
each
other and don't interfere with each other except through conflicting
demands
on core/.

Anyway, I suspect that the lack of direction in core/ is responsible for
many
of these issues. In particular:


1. Projects that depend on core/ (both external and in GNUstep) are
having a
hard time dealing with GNUstep core/.

Ill-defined scope (eg. development vs. desktop) means that they don't
know what to expect from core/ and what they need to implement
themselves.
Ill-defined direction means that they can't trust core/ to continue
to provide what they need.

The key thing here isn't to make core/ compatible with all other
projects.
The key thing is to make it clear to the other projects what core/ is
compatible with. Unlike lack of knowledge, lack of compatibility can be
handled (eg. by only using compatible parts of core/, or by not using
it, or
by forking it).


2. Without a clear direction for core/, core/ itself becomes
uninteresting.
Ie. work is done on core/ only as is required to further other projects,
and
not to improve core/ per se.

I think it is important to make this distinction. While I have an
interest in
using core/ in different projects, I also have an independent and strong
interest in core/ itself.


> Things we must have to succeed:
> -------------------------------
> 1) Stability.   It is necessary for us to go through all of the classes, both
> in GUI and in BASE to ferret out any bugs which are there.
> 2) Completeness in the API.   All of the classes which a "half done" should 
> be> finished or removed until such a time as they *are* completed.

Yes, these are very important.

[snip points that don't directly affect core/]
> Things which are a waste of time and detract from the success of GNUstep:
> -------------------------------------------------------------------------
[snip whining about whining ;-) ]

> Also remember that an open source project is not like a company.   "Ordering"
> someone to do something usually has very little effect on what they do or do
> not do.

Project leadership isn't about ordering people around, though. Project
leadership is about leading the _project_.


Anyway, to try to be a bit constructive, I'd like to give a
definition/policy
proposal based on what I think core/ should be/is. However, it's late
here,
so it'll have to wait.

For now, I'll just note that no policy is any good without some kind of
'leadership' to enforce it and make the judgment calls involved (in
fact,
it could be argued that policy is mostly descriptive).

- Alexander Malmberg