I want to echo Andreas's point here. I think one of the most critical things the project needs to fine-tune is the experience for brand new would-be gnustep developers. If you think back to any creative project you've ever done, at the end, there's an incredible amount of effort you've put in, and you have this robust, finished product you are proud of. But when you think back to the beginning of the project, you were probably filled with uncertainty: "is this going to be worth my time and effort?"
Jony Ive had an incredibly insightful line about the creative process in his eulogy for Steve Jobs: "...And just as Steve loved ideas, and loved making stuff, he treated the process of creativity with a rare and wonderful reference. You see, I think he better than anyone understood that while ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts, so easily missed, so easily compromised, so easily just squished." I think that really encapsulates the problem we need to solve for in attracting new developers to GNUstep. These are people with an idea. Maybe it's a brand new app. Maybe it's porting their (or someone else's) macOS app to Linux or Windows. And they think to themselves, "hey, I wonder if I can do this with GNUstep". And then they give it a shot. It's in that moment that we lose or gain a new developer. Tiny details could be the difference between them saying "eh... never mind" or gaining a life-long advocate for the project. It truly is unfortunate that we can't get Debian to package the clang/libobjc2 versions of the libraries in their repos because I think no amount of documentation or flashing neon signs on the web site will stop some new devs from getting caught in the trap Andreas describes. They're going to see the libraries sitting in the Debian repos and say, "oh--look how easy it is to install gnustep". We need to really fine-tune the "what happens next" step. The dev is probably going to go to the web site and try to figure out why his code isn't compiling. How well do we surface the answer to his question? How easy do we make it for him to pivot away from the Debian packages to something that will work for his project? On Tue, 2025-05-20 at 16:04 +0100, Andreas Fink via Discussion list for the GNUstep programming environment wrote: > > > > > I'm still confused. What are you talking about? You asked a > > question and then went down this discussion. A few things: > > > > 1) clang+libobjc2 support ARC > > 2) I have gotten modern applications built and running on GNUstep > > using it > > a) Eggplant > > b) Algoriddim > > c) OpenOutliner (in process) > > > > Sure. You and me can make it work. > > Now change the focus to a new developer who has written some stuff on > MacOS who now wants to port it to Debian for example. He finds > GNUStep and now thinks its a good start to use it to bring it to > Linux that way. > > So he installs gnustep from the repository and compiles his code and > it miserably fails with out of memory all the time. He then learns > that ARC is required so he changes his Makefile to use the flag to > enable ARC. Then the compiler will bark that its not supported with > the gcc runtime. > > At this point we have lost a motivated potential GNUStep > User/Developer. Now he has to recompile everything. When he now done > that and his superduper App needs to be shipped, he needs to ship the > whole GNUStep environment as well because the built-in doesnt support > ARC. > > Thats what I do since several years. I build my own packages because > there is no other way. > > However this only works for a single App. If you want to have > multiple apps and some have old runtime and some use new you end up > in a big mess where you need libraries in two copies with two > runtimes etc. > > The goal is to attract developers. You can't do that by keeping the > old runtime as default in distributions. Its just going to turn away > new developers. > > Thats my point > >
