Re: GNUstep improvements bounty

[Sheldon Gill]

Adrian Robert wrote:
> I agree with Fabien's opinion (below).  People are always interested to 
> work on new features -- it seems like the CoreData stuff for example is 
> already well on its way even though Tiger's just out -- but it's the 
> more thankless work like fixing bugs and filling in rarely-invoked 
> implementations that most needs to be compensated to occur at all.
>
> > > > Alex Perez has suggested using some of the funds that GNUstep has
> > > > (and/or directed donations from individuals) to fund a part-time
> > > > programmer to improve GNUstep.  Some specific projects include CoreData
> > > > and Predicates. Are other people interested in seeing these things 
> > > > added to GNUstep?
> > >
> > > I think the general idea of the improvements bounty is great.  CoreData
> > > and Predicates both seem interesting are probably good candidates to
> > > figure out how to structure such bounty project.

I think that CoreData, Predicates, KVO and a number of other things are 
actually very bad candidates. The reason is this:

Community projects tend to get lots of work done in the areas which are 
considered interesting or which are clearly visible to others. It is the things 
which don't and probably won't get done which should have the bounty as incentive.

Also, as the GNUstep funds and administration are very limited, I'd suggest it 
best that bounty tasks be small, contained and very well defined. They should 
be work on the -core libraries which provide benefit to large numbers of users.

As there are commercial interests using GNUstep, it would be great if those 
companies would offer bounties for functionality they'd like. Instead of paying 
an internal programmer, offer the sum as a bounty with a time limit. Then there 
is a chance that the work is already done before your internal programmers get 
to the task. You can actually shorten your project timeline at the same cost 
without risk.

> > I think it would be usefull to fix all bugs in AppKit / backend first
> > see : http://savannah.gnu.org/bugs/?group=gnustep
> >
> > Make stable and "bugs free" all we already have should be the first 
> > priority.

Agreed in principle.

> > Other suggestions :
> > - Icons for the default NeXTish look.
> > - a clone of HearderViewer ( and pre-compiled headers )
> > - Port of WebCore

I'd vote against all three of these. There are icons out there already to use. 
More can be done. They are quite visible and there is recognition factor in 
contributing them so I don't think icons are a good candidate at this stage.

HeaderViewer is an app. If enough people want it, it'll happen. The 
functionality can come through other means anyway.

There already has been quite some effort in porting WebCore and the concensus 
seems to be to wait for ObjC++ support in GNU gcc. Hence, WebCore will happen 
in time anyway.

Pre-compiled header support in -make is definitely a good thing. I believe 
Nicola and some others have already looked into this...


Regards,
Sheldon