[Top][All Lists]

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

Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality contr

From: Philip Mötteli
Subject: Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control)
Date: Sat, 25 Oct 2003 21:32:57 +0200

Am 23.10.2003 um 21:07 schrieb Philippe C.D. Robert:
On Thursday, October 23, 2003, at 03:33  Uhr, Philip Mötteli wrote:
I do not agree because you will not find many Mac OS X apps which only rely on Cocoa and this GNUstep cannot be used for porting. I am thinking of CoreFoundation,

CoreFoundation is almost ported. Apart from that, it's very little used from Cocoa developpers.


That's a problem. But that's the reason, why I said Cocoa programs. Carbon is actually only used for old classic Mac programs. I don't think that a new project would start by using Carbon. Would be suicide.


Is almost ported too.

the security stuff,

I don't think this is a huge problem.

Apple Scripts

Mostly legacy apps again (apart from Apple themselves).

and so on...

Well there's not a lot.

This is one point where I do not agree. I seriously doubt that having a Windows port would have big impacts on the GS project. Windows programmers are definitely not waiting for GS and most of the current GS users are more "Unix oriented" anyway. Even if it was possible to port let's say excellent Cocoa apps to Windows using GS they would probably not succeed on Windows, because AppKit/Mac OS X paradigms do not match the Windows experience

Windows experience??? My experience on Windows is, that every second app is a different experience. And now with Java being used it's even every app, that has a different experiience. Apart from that make the calculation, that our profs at the Uni always showed:

You sell your app to x% of the user base of a platform. If on Apple, this makes 100 sold units, this makes on Windows 1'000 sold units. Now if you subtract 10 people who complain about the missing great Windows experience, this makes still 990 license more sold. I don't think any company would complain 990% more revenue, without more effort to pay, would you?

and thus won't be accepted by Windows users - OPENSTEP Enterprise is the proof for this I'd say.

I'm sorry again, but my experience is exactly, that OpenStep didn't fail on Windows. It saved NeXT. So it definitely can't be a failure. This corresponds also with my personal experiences.

But if we go directly to for the distribution, we will never have the manpower to achieve it.

Does it really take that many more men to reach this goal?

Well, two tries and both failed because of manpower. Makes 100% failure. Is that enough?

And don't you think that there are programmers eg. on the Linux side who would join if this was the goal?

I don't think so. You convince programmers for OpenStep, but not yet for the environment.

Well I believe there is at least a chance for this, especially because there are programmers in the Linux world who cannot afford to buy a Mac but would love to - so GNUstep could be the alternative.

Exactly, for OpenStep, but not the environment/distribution/desktop.

Well, they did not succeed selling enough versions of OPENSTEP Mach or OPENSTEP Enterprises, also they did not attract enough programmers/companies to use their APIs, so they failed in this respect, no?!

What is enough? Dominate M$? They became profitable. In my eyes, this is already very good in such a market.

In fact even OPENSTEP Mach 4.x is in many aspects already a step backwards wrt NEXTSTEP.

It became much slower,

This is not a sign of going backwards in my eyes. More the opposite. I give you an example: Your assembly program runs very fast, but is not portable at all. Very probably you have a lot of functional reduncdancy in it, because Assembly is not trimmed for reuse, like e. g. ObjC. No you want to port your program to other platforms. This means, you gonna clean up your program and replace Assembly where possible with ObjC. It will run slower, but from a SE point of view, it has improved.

some UI got crippled because of the fact that OpenStep had to run on Windows as well

That's a pitty.

plus they adopted more and more the Windows philosophy where 1 app can do a lot, whereas in NEXTSTEP you had many little tools who worked together. PB + Edit is a brilliant example for this, have a look how this changed over the years from release to release!

Well, they reused the same object. I mean Edit was basically one huge object. This allowd them to make a specialized subclass of it for PB. And Edit had its own specialized subclass. Or differently said: The version of Edit you think about offered only very restricted support for programming. In the actual PBX we have much more editing functions for programmers, than TextEdit offers. That's probably the reason, why this trend continues, though they have no Windows versions any more.

Thus I see mainly 2 groups of people on this list, those who are mainly interested in an "OPENSTEP Enterprise and/or WO" clone (running on *nix, Windows and also other systems) based on GNUstep and those who are interested in creating an environment (on top of *nix) which brings back the spirit of NEXTSTEP, but this time on top of the GNUstep frameworks. Both are valid positions, they just do not fit well together in some aspect.

I agree with that. I just think that one group has a bolder goal, which could only be achieved, by achieving the other groups goal.

But maybe the goal of this other group prevents faster progress wrt the bolder goals?

:-) We could have a look, how many check ins were made because of a "distribution"-project and how many because of a "ordinary" program project.

I'd rather see the GNUstep continue what NeXT stopped when they switched from NEXTSTEP to OPENSTEP.
What did they stop?

The experience of NEXTSTEP, or better phrased, some parts of the philosophy which made this NEXTSTEP experience so brilliant.

Exactly my opinion: NeXTstep was so brilliant, because all these already phenomenal libraries all worked so smoothly together. That's still my main reason, why I'm with GS/Cocoa.

This includes APIs like the IndexerKit,

IndexingKit disappeared, because it was a buggy hack. They wanted to get rid of it as soon as possible. I knew that from somebody directly involved with it at NeXT.


Was replaced by EOF. Of course! I would never want to exchange EOF against DBKit.

3DKit plus QuickRenderMan

3DKit was available until Apple bought NeXT and didn't buy the Renderman license with it. It's true though, that they didn't do a lot of maintenance for it. But that was due to the missing demand.

and so on which were killed by moving to OpenStep.

Nothing was killed because of OpenStep. That has nothing to do with it, as I just explained.

But still we can ask ourselves what we want, no? If it turns out that GNUstep will never become an enduser environment why should anyone then spend time to write GUI based apps, for example (be it as a hobby or as a professional enterprise)?

Well it's still a great development environment. At least the libraries. And as long as we have a certain compatibility to others, we can slowly but constantly continue until we have enough building blocks, to implement the complete environment. But, if we just go for the boald goal right from the beginning, than people like you (and many others) are becoming frustrated (as you said in your initial posting).

Well, these people are frustrated, it seems! So one reason for this might be the current strategy, no? Besides, a good development environment is not a reason for writing apps. There must be a chance to actually use or deploy these apps so that they will be used by real users...

:-) What did I say (and others)? Bigger user base (Windows) more user, even if you just sell it to a very small percentage.

All this has IMHO nothing to do with being a hobbyist or an enterprise.

I especially don't think so. The moment, we can concince companies, all your goals will be achieved in no time at all.

I heavily doubt that...

Well, look at M$? Even with a heavily inferior environment to all their competitors.


reply via email to

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