[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.
Carbon,
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.
WebCore,
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.
Why?
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.
DBKit,
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.
Re
Phil
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), (continued)
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/23
- Re[2]: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Manuel Guesdon, 2003/10/23
- Re: Re[2]: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/23
- Re: Re[2]: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Pascal J . Bourguignon, 2003/10/23
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philippe C.D. Robert, 2003/10/24
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for qualitycontrol), Jeff Teunissen, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control),
Philip Mötteli <=
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Jason Clouse, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Pete French, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Pete French, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Pete French, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philippe C . D . Robert, 2003/10/26
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/26