GNUstep in the year 2009: A look back and a look forward...
All,
Looking back on my last two years as lead, I can see that it is much harder than I originally thought it would be.
I know that I haven't always been perfect, but I'm learning. :) Also, aside from all of that... I've suffered a few very personal losses in the past year and a half that have distracted me a bit from GNUstep, but it's always remained close to my heart.
GNUstep has made some significant progress in this past year in terms of stability, completeness, and usability on UNIX-based platforms and, particularly, on the Windows platform.
I believe that the coming year holds some promise for GNUstep since I have been seeing more interest regarding porting apps for Mac OS X to GNUstep. There have also been a number of new "native" GNUstep apps from GAP and from Etoile.
I think the things we need to focus on, as a project, over the next few months are (this time in priority order):
1) Stability/Polish.
a) We're pretty stable, but there are a few places in GNUstep where we lack "polish." :) We need to make certain that a lot of the little annoyances that we are used to dealing with are taken care of as they make a huge impression when someone first sees an application which uses GNUstep in action. I leave it to other threads/discussions to hash these out, but I will mention one: Menu/Window Focus issues. :)
2) Better compatibility with Cocoa/API completeness:
a) Determine which classes GNUstep is lacking when compared against a given version of Cocoa (TBD).
b) Implement classes and methods identified in step a.
c) Better nib support for writing. Reading appears to work very well, writing nibs has a few issues which I have identified and will document as bugs.
d) perhaps more...
3) Theming
4) ObjC 2.0 (this is a nice to have...) :)
I also think that it's very important for us to stick to the goals which were set out in the blog posting I made here:
http://heronsperch.blogspot.com/2006/12/plans-for-change.html
Some of the things in the list from my blog have been achieved with great thanks to those involved in doing so (in no particular order):
* Nicola for doing such a great job on gnustep-make, and FHS support and all of his other contributions,
* Fred for his awesome work on gnustep-gui and for helping to make Windows more usable,
* Richard for his tireless work on gnustep-base,
* Riccardo for work on various applications in GNUstep and GNUstep GAP which have helped to identify issues in GNUstep itself,
* Wolfgang Lux who has been a consistently excellent addition to the team since he started contributing
* everyone else who has worked on GNUstep over the past few years.
By giving thanks to these people above, I am, by no means, minimizing the contribution of anyone not mentioned above. :)
Other goals on the list from the blog haven't been achieved yet, but I believe that all of those points are central to GNUstep's success.
With some effort, I believe that we can make 2009 a really good year for GNUstep.
Thank you, GJC
Looking back on my last two years as lead, I can see that it is much harder than I originally thought it would be.
I know that I haven't always been perfect, but I'm learning. :) Also, aside from all of that... I've suffered a few very personal losses in the past year and a half that have distracted me a bit from GNUstep, but it's always remained close to my heart.
GNUstep has made some significant progress in this past year in terms of stability, completeness, and usability on UNIX-based platforms and, particularly, on the Windows platform.
I believe that the coming year holds some promise for GNUstep since I have been seeing more interest regarding porting apps for Mac OS X to GNUstep. There have also been a number of new "native" GNUstep apps from GAP and from Etoile.
I think the things we need to focus on, as a project, over the next few months are (this time in priority order):
1) Stability/Polish.
a) We're pretty stable, but there are a few places in GNUstep where we lack "polish." :) We need to make certain that a lot of the little annoyances that we are used to dealing with are taken care of as they make a huge impression when someone first sees an application which uses GNUstep in action. I leave it to other threads/discussions to hash these out, but I will mention one: Menu/Window Focus issues. :)
2) Better compatibility with Cocoa/API completeness:
a) Determine which classes GNUstep is lacking when compared against a given version of Cocoa (TBD).
b) Implement classes and methods identified in step a.
c) Better nib support for writing. Reading appears to work very well, writing nibs has a few issues which I have identified and will document as bugs.
d) perhaps more...
3) Theming
4) ObjC 2.0 (this is a nice to have...) :)
I also think that it's very important for us to stick to the goals which were set out in the blog posting I made here:
http://heronsperch.blogspot.com/2006/12/plans-for-change.html
Some of the things in the list from my blog have been achieved with great thanks to those involved in doing so (in no particular order):
* Nicola for doing such a great job on gnustep-make, and FHS support and all of his other contributions,
* Fred for his awesome work on gnustep-gui and for helping to make Windows more usable,
* Richard for his tireless work on gnustep-base,
* Riccardo for work on various applications in GNUstep and GNUstep GAP which have helped to identify issues in GNUstep itself,
* Wolfgang Lux who has been a consistently excellent addition to the team since he started contributing
* everyone else who has worked on GNUstep over the past few years.
By giving thanks to these people above, I am, by no means, minimizing the contribution of anyone not mentioned above. :)
Other goals on the list from the blog haven't been achieved yet, but I believe that all of those points are central to GNUstep's success.
With some effort, I believe that we can make 2009 a really good year for GNUstep.
Thank you, GJC
Comments
That said, my personal opinion is that the current priorities are in exactly the wrong order.
I think theming should be your #1 priority. First impressions are everything in a desktop environment, and given a glance at the current state of GNUStep, I don't know anyone who would take it seriously or recognize it as a Cocoa-esque environment.
After that, I think Cocoa completeness should be top priority, and stability will come with maturity.
Without a good looking environment, there is no user base. Without a decent sized user base, there is no attraction for cocoa devs. Without working towards API completeness, there is no attraction for devs.
At this point I fear projects like Cocotron, Cappuccino, and SproutCore (I know the latter two are vastly different but bear with me) will soon surpass GNUStep and make it moot.
Cocotron has made great strides. Why?
Also, this probably sounds more critical than it should; I haven't kept up on GNUStep in some time (which may say something in itself), so I have no idea how far along the project is. This may speak to another point that is missing entirely - PR.
Thank you for the comment. I think you might be correct about theming.
I believe it should go a little higher up on the list now that I look back at it.
The fact is that we are working on that very hard at this point. The priority list, in my view is not sequential. That is to say, we are working on all of these things at once.
As for GNUstep vs Cocotron... GNUstep is more complete than Cocotron in many ways. GNUstep is more stable and better tested. There are more commercial apps using GNUstep than use Cocotron.
From what I've seen, the only Theme that Cocotron supports is a Windows like one and, honestly, it's not that much better looking than our current default theme... it just happens to blend better with Windows.
What Cocotron has going for it is it's toolchain and cross compiler which allows developers to easily compile applications from Xcode without having to touch the other platform. This is something that we've also been looking into doing in GNUstep.
Cocotron's goal and GNUstep's goal overlap somewhat, but they are not the same. GNUstep aims to be a complete development environment, a crossplatform porting tool, and a way to build native applications across many architectures. Cocotron intends only to be a crossplatform porting tool.
Speaking of API completeness, Cocotron's API completeness is nowhere near GNUstep's. This is evident when you read the article about the small commercial app they helped to port a few months ago. The classes they spent time building were already in GNUstep and had been tested for many years. So the company that did the port to Windows... would have spent about two weeks instead of two months had they used GNUstep rather than Cocotron. It is also evident when you consider that there are some nibs that I have personally tested on both that load properly on GNUstep, but not on Cocotron.
Also... I'm not sure what about the "current state" of GNUstep would give someone pause.
What's so bad about it's current state? Last time I checked, I can take a Cocoa app and build it using pbxbuild and have it working with no changes (or very minimal ones). If you're talking simply about how it looks, then I believe we have that in hand.
The fact is... I use it every single day as my development environment. And I try to use as many of the native GNUstep apps as possible in my daily work so that I can find problems with them as I do. It works fine for me.
In my time on this project I've seen people who both love and hate the look. I've also seen people who both love and hate the way Mac OS X looks.
All of that being said.... theming shall become one of our top prorities.
Thanks, GC
I don't know if you've seen BEOS' GNU reincarnation HAiKU but I think there might be something there, and GNUstep and Haiku gould do well to bounce off each other cause its a cold GNU world if you're not linux...
As far as HURD goes, if you look at my blog you will find that I do test and run GNUstep on HURD from time to time, since it is a very interesting blend, the total "GNU" replacement of OpenSTEP, including the Mach MK. There are issues, but it proves the concept is possibe.
I too agree with many of your points, maybe not fully on their priority, but what counts is to get several of them nailed down, as well as others like... more applications, smaller footprint for handheld and mobile solutions... and SimpleWebKit.
I too would love to see HURD and GNUstep work well together. GNUstep on HURD isn't very stable. I'm not sure if it's a HURD or GNUstep issue at this point, but I do know it's something that should be worked on and corrected.
I've noticed that a lot of people (speaking to gongfermor here) want "Cocoa completeness" the problem with this is that we can never really be "Cocoa complete". We can only get to a point where we can guarantee compatibility up to a given version of Cocoa, such as 10.4 and so on.
Alternative versions of the runtime from David Chisnall and enhancements to GNUstep are giving us features we need to support 10.5, so it's coming.
Later, GC
Thanks.
Ping
eissa06
MAGNAVOX MDR513H/F7 HDD and DVD Recorder with Digital Tuner
shean06
Vacation spots
One can only hope that more will learn from.
Used trucks for sale
Ascentia Sky
way of writing the post. Now it become easy for me to understand and implement the concept. Thanks for sharing the post,this is a great websites!
The Commerze
New Launch
Casa Cambio
Centropod @ Changi