Re: Kickstarter was not successful... but it did help things...

[Ivan Vučica]

On Thu Dec 19 2013 at 9:17:57 PM, Dr. H. Nikolaus Schaller <hns@goldelico.com> wrote:

> The key problem IMHO is that GNUstep is missing leadership. Someone thinking
> about AND defining the overall direction of the project *)
>
> So if not one person is standing up an saying "go there", we need some other
> means. E.g. a democratic one. Like an opinion poll and majority votes. Or we
> do a vote to empower a trustworthy person to define the overall directions for
> e.g. one year.

Linus happens to have the luxury of having hundreds or thousands of people wanting really hard to get their work inside of Linux. He has the luxury of being able to filter through the contributions and STILL being able to advance the project forward.

He has the luxury of having hundreds of those developers being actually paid every day to work on Linux, on small pieces that bother their employer (a specific driver), or both them and their employer (filesystems).

There are companies out there who build great products around Objective-C as a language, occasionally mentioning GNUstep and Cocotron as inspiration, then slowly moving away without making great contributions. There are other companies who have been actively using GNUstep and actively helping the libraries they need.

Who will step up and recognize a business need for a Core Data implementation on GNUstep... then say "Oh, I will give all this magnficent IntellectualProperty(tm) away!" With Linux, they're forced, so Linus has the luxury of sifting through a LOT of excellent work by excellent hackers, as well as by a lot of paid developers producing software for commercial needs, as well as code by excellent hackers that happen to be paid to do commercial work as well. He has that luxury.

Can a project leader come and order someone: "No, you will NOT work on Core Data, we need good integration with Ruby!" or "I'd really like you to work on Core Animation"? No. But Linus is a big enough name, a canonical enough name, a 'conflict-resolving' hot-point (let's ignore conflict-facilitating bit for the sake of the argument). He gets enough contributions.

Gregory can't come and simply order (e.g.) Fred to work on a UIKit implementation. He can gently nudge in that direction, if Fred feels like working on it already.

The developers did, for example, quite well collaborate on certain things during our stay in Cambridge (for example, I nudged Niels to take a look at libdbusmenu and see how DbusKit can be extended to integrate with a global menu system such as the one in Canonical's Unity; Johannes asked that someone takes a look at issues with getting X11 window transparency which he needed for project-formerly-known-as-Viking-whose-name-I-cannot-remember-right-now-and-I-aplogize). 

But that's something really hard to do remotely, in a controlled fashion. That's something really hard to do when everyone has 'real lives', interests, friends, pubs to visit, restaurants to consume, etc., and there's only a small number of people even working on the project.

Note that those were small things, small grievances we had. To go further down the road to "OS X and iOS friendliness", if we want to distribute an effort, we need to divide things into smaller chunks that people can resolve over weekends, list them, and see who picks up what. Small things people can do quickly.

That may be a way to steer more people in a single direction. Define it, chop it up, offer small tasks for consumption. And if more people manage to work on this as part of their day job, school projects, etc., maybe we can move along.