discuss-gnustep
[Top][All Lists]
Advanced

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

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


From: Markus Hitter
Subject: Re: Kickstarter was not successful... but it did help things...
Date: Fri, 20 Dec 2013 00:06:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Looks like this kickstarter thing has discovered quite a few open wounds ...


Am 19.12.2013 19:26, schrieb Doc O'Leary:> In article
<mailman.9608.1387390854.10748.discuss-gnustep@gnu.org>,
> My experience with projects, paid and unpaid, is that crapping out 
> code is wasted effort unless the "words" have set people in the right
> direction.

My experience with open source is, whenever you come with more than a
bugfix, you apparently present something like an embarrassment. The word
apparently received by the already existing community is: "he doesn't
like what we have and he wants to change things which work just fine for
us".

>From the psychological standpoint that's even understandable and the
solution I took so far is, to do a friendly fork. Communicate this fork,
attach a website which shows cases where your fork is superior, bring it
into a shape people can test it. After a few months they usually
recognize sky isn't falling, but the new thing is a good one. Eventually
help bringing it into the main distribution.

Happens not always, sometimes forks happen to exist for a very long
time. No problem either, with something like Git ( + git-svn) it's
extremely easy to follow upstream as well as advancing with the fork.

If you see lack for some specific field, open a web site, discuss the
problems and how to solve them, link to your fork. 99% of all people
find web pages by search engines today and engines pretty merciless rank
your site higher than the original one if people search for stuff you
offer to solve.

Example:
http://www.reprap.org/wiki/SimulAVR
https://github.com/Traumflug/simulavr.git


Am 19.12.2013 20:27, schrieb Doc O'Leary:> In article
<mailman.9679.1387478362.10748.discuss-gnustep@gnu.org>,
> Case in point is my root "rant" to this discussion that got dropped:
>  what *is* the current message of GNUstep?

In the scenario above it's _you_ who defines the message, so this
problem is solved, too.


Am 19.12.2013 21:10, schrieb Gregory Casamento:
> I must confess, however, that I don't fully understand the need to 
> run GNUstep apps on Mac since it is almost akin to trying to download
> and use WINE on Windows.

Actually, Wine people put _a_lot_ of efforts into running Wine on
Windows. "Doesn't work on Windows" is a mandatory reason for patch
rejection. AFAIK, they do this for evaluation, for comparison, for ease
of development.


Am 19.12.2013 22:17, schrieb Dr. H. Nikolaus Schaller:
> So there is no overall direction.

Matches my observation. Looks like GNUstep should split into
sub-projects anyways. Uhm, didn't this happen already? Etoile and
Darling are distinct, aren't they?

Maybe it sounds disappointing to the elder of us, but the decade of big
unified projects is over. These days everybody works in his own box. The
last three years I've seen ten times more rewrites from scratch than big
projects achieving noticeable goals. People don't even try to understand
existing projects, instead they write their own code.


Am 19.12.2013 22:34, schrieb Gregory Casamento:
> Dr. Schaller
>> The kickstarter can also be seen as the attempt of Gregory to 
>> become elected into that leadership role by user's votes.
> 
> Really, is this what you think?  Wow...

What's wrong with this view? To all I can see this attempt was
appreciated, already existing leadership or not.


Am 19.12.2013 22:41, schrieb Ivan Vučica:
> 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.

As you wrote correctly already, this is because a kernel can't be
packaged as an add-on. Technical neccessity or not, if you want people
to use your driver, you have to get it into the kernel.

> Can a project leader come and order someone: "No, you will NOT work 
> on Core Data, we need good integration with Ruby!"

He can't, but he can say: "this work won't go into the main repo.". Uhm,
harsh example of mine, of course.

And here enters packaging the game: if 80% of your users use packages,
your word becomes weight. Using a package isn't mandatory, but it's ten
times easier than compiling from scratch, so people strongly prefer
packages. Not as much weight as Linus' words, but devinitely more than
nothing.

A bit contradictionary to what I wrote above? Perhaps. The intro
scenario is good for really distinct stuff and also as a temporary
solution to solve specific needs.


Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.reprap-diy.com/
http://www.jump-ing.de/



reply via email to

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