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

[Doc O'Leary]

In article <mailman.1986.1379017538.10748.discuss-gnustep@gnu.org>,
 Doug Simons <doug.simons@testplant.com> wrote:

> I think any Cocoa developer who discovers GNUstep and begins to consider 
> using it to port their app will immediately be asking questions like "Does it 
> work?", "How complete is it?", "Will it do what I need for my app?".

Yes, but some higher level organizational questions come first.  The 
vast majority of ObjC developers have come in after 2007 with iOS, 
chasing after dollar signs in the App Store.  GNUstep doesn't really 
make a case for them.  In fact, the site doesn't really lay out a path 
for anyone; it just seems to assume you know where it fits.  It should 
be more motivational, for both developers and users.

The developer questions that I see more pressing are ones like:  "How do 
I use this to get a feel for iOS development without buying a Mac?"  
"How do I use this to port my Mac app to Windows?"  "How do I use this 
to port a Mac/iOS app to Linux/Android?"  "How do I use this to leverage 
my model classes to develop the server backend?"  You get them going 
quickly by addressing the bigger concerns, and those other questions 
will answer themselves.

> They 
> will likely be highly skeptical about GNUstep and not believe that it will 
> simply work as a Cocoa replacement. Reading that GNUstep implements 80% of 
> Cocoa (or whatever) is almost completely useless information, and means that 
> it will take them considerable effort to even figure out whether it's worth 
> looking at in more depth.

That's why I say *that* is the barrier to remove.  Once they're in the 
environment, it matters *much* less what 20% is missing because the 
developer might have a good idea on how to get things going either 
without it or with a reasonable substitute.  You want to put them as 
close as possible to the finish line, not give them the idea that they 
shouldn't even start the race.

> If there is a tool that can quickly give them a 
> concrete indication of approximately how much effort might be involved, I 
> think it would go a long way toward easing their entry into GNUstep. So I 
> don't understand why you think such a tool would have them looking at GNUstep 
> like a stinky diaper. I think they will see it that way right from the start, 
> and the tool will help them get past the stinkiness and move ahead with a 
> clearer idea of the reality. But that's just my opinion. :-)

I think you're wrong, of course; we may both be wrong about it, too!  
It's just been my experience that people are loathe to start projects 
that immediately look like they'll fail.  That is especially true when 
it doesn't look like there will be much reward for the effort.

> I totally agree that making it all less daunting from the get-go is 
> important. Another critically important piece of that, IMHO, would be to 
> simplify the build process. Either make it as easy as possible to build a 
> GNUstep app from within Xcode, or if that's not feasible, make the build 
> process for Cocoa apps on Windows/Linux as close to one-click as possible. 
> For me, at least, I would want to start the process off with specific compile 
> errors showing the parts of my code that need work, rather than fighting with 
> installing, configuring, and setting up the environment for many hours.

This is why I'd like to see pathways to development/deployment 
addressed.  For example, it isn't immediately clear that it *can* run on 
a Mac alongside Xcode, but even if it can be, perhaps best practices 
would instead suggest providing GNUstep as a pre-configured Linux image 
for VirtualBox (or whatever).  It's a lot of effort that doesn't 
*directly* improve GNUstep, but if the goal is to get people 
using/funding it, the approach has to be a lot more than "well, here it 
is".

-- 
iPhone apps that matter:    http://appstore.subsume.com/
My personal UDP list: 127.0.0.1, localhost, googlegroups.com, theremailer.net,
    and probably your server, too.