Re: ANN: One Step to GNUstep - pre-release version 0.9

[Gregory Casamento]

Much of what David is saying here meshes with things I originally said
a very long time ago when I first became maintainer.

If you look at my posting "Plans for Change"
(http://heronsperch.blogspot.com/2006/12/plans-for-change.html) on my
blog I said this in point #4:

"4) Start appealing more to the Mac OS X/Cocoa crowd. While some
people disagree with me, I believe that this group IS the group we
need to be playing towards. In the past some have advocated that
GNUstep be an 'OPENSTEP-like' or a 'Cocoa-like' environment. While I
don't believe that GNUstep should necessarily follow all of the design
decisions Apple has made, I believe that it should implement all of
the classes which are useful and which are being commonly used in
spite of whether or not people personally agree with having that class
in GNUstep or not. A good, and recent, example of this is NSToolbar.
It's not about us, remember, it's about them... the users and
developers USING GNUstep. We are here to make life easier for our
users not to make GNUstep into the epitome of "perfect design" by
excluding classes we personally don't like. This is not productive
and, not to mention, highly subjective."

Other projects, such as Cocotron, have benefited greatly from our lack
of organization around *this very point*.  And in particular from our
relative lack of support for Windows at the time, this has since been
addressed... but we still have a long way to go on other fronts.
Cocotron has, in fact, had a cross compiler which has feature parity
with ObjC 2.0 a bit longer than we have since the maintainer of that
project created one for it.  It's a shame that we're just now catching
up on this front in GCC and that Cocotron got a fair amont of
mindshare because of this.

This also emphasizes one other thing I've been saying repeatedly and
that is that small differences (i.e. lack of certain features)
presents a huge issue when it comes to getting new users and
developers. The features added to ObjC 2.0 in LLVM/clang are not
"small features", since lack of these features represent a serious
impediment to new developers who would like to either write new
applications or port existing applications from Mac OS X.

Losing this potential new blood is something that cannot be allowed to
continue on this project.

GC

On Mon, Jun 13, 2011 at 4:49 AM, David Chisnall <theraven@sucs.org> wrote:
>
> On 13 Jun 2011, at 00:54, Nicola Pero wrote:
>
>> Then there is the point that, if all that matters is the technical "feature 
>> parity" with Apple, then buy an Apple; why bother with GNUstep.
>
> If that's your view, then why bother with GNUstep at all?  Why not work on an 
> Objective-C framework that doesn't aim for Cocoa compatibility.
>
>> and for many people in the project using a GNU/FSF compiler is important, 
>> more important than having some small additional feature.
>
> I'd hardly call full support for the language that GNUstep uses a 'small 
> feature', nor would I put the ability to reuse the front end for IDE 
> integration or the static analyser in the same category.  We've fixed well 
> over a hundred GNUstep bugs so far that have been found by the static 
> analyser alone.
>
>> If you consider the track record of Apple dealing with
>> open source projects, you'll clearly see the dangers.  Apple likes their 
>> version of "open source", where you can see the code,
>> send bug fixes and contribute improvements (so that they save money on 
>> development costs) but to actually use the result
>> you'll have to buy an Apple product;
>
> Let's see, Apple's open source record...
>
> Well, they took the FreeBSD useland, libc, and chunks of the kernel and... 
> released improvements upstream.  The bastards!
>
> They published Launchd under an open source license (APSL) and, when the 
> FreeBSD Foundation said that this license was too restrictive, Apple's evil 
> response was... to relicense it under the Apache 2.0 License.  Freedom haters!
>
> Then they forked KHTML and, when the KHTML team started complaining about 
> their patch dumps being difficult to support... they started developing 
> WebKit in an open subversion repository and soliciting outside contributions 
> and ports to other platforms.  Deliciously evil!
>
> Or are you talking about Apple-originated projects, like CalDAV server and 
> libdispatch, which Apple callously and ruthlessly exploited the open source 
> community by giving us large amounts of production-quality code under various 
> open source licenses?
>
> In your release notes for GCC 4.6, I saw that you thanked some Apple 
> developers for their assistance in porting features from their branch.  Did 
> you mention that you viewed them as instruments of 'rapacity and amorality' 
> at the time?
>
>> the Apple Objective-C runtime is a great example.
>
> Do you mean the one that they inherited from NeXT under a proprietary license 
> and released under APSL 2 (a FSF-approved license), or the one that they 
> wrote from scratch and released under APSL 2?  If you want to use it on 
> another platform then you are free to do so, but the design's pretty horrible 
> so I don't think anyone does want to...
>
>> With clang they're pushing even further,
>> since clang on Linux is basically now the freeware trialware version of 
>> Apple XCode;
>
> This doesn't even make sense.  Clang has almost exactly the same feature set 
> on OS X and on Linux (__thread only works on Linux, but aside from that 
> they're equivalent).
>
> XCode adds a lot of features on top, just as it did when it used GCC as the 
> compiler.  For example, XCode uses clang for syntax highlighting, and those 
> open source hating bastards at Apple have provided a C API with guaranteed 
> forward compatibility to allow other IDEs to do the same.
>
> XCode provides a nice UI for viewing static analyser results, while Linux 
> users with the 'trialware' version have to view the same results in a web 
> browser.  Well, actually clang emits the results in plist format, so it would 
> be fairly trivial for GNUstep code to make use of it...
>
>> of course to get the real thing you have to
>> buy an Apple product because the license allows them to have "open source" 
>> developers (ie, unpaid developers outside of Apple)
>> look at the compiler code, debug and improve it, but the actual final product
>
> That's how Free Software is supposed to work!  People who mutually benefit 
> from the existence of a project collaborate to work on it.
>
>> (XCode where the compiler is deeply integrated
>> into the real IDE) can only be obtained by purchasing an Apple product.  And 
>> if something ever goes wrong with this model,
>> they can still announce that they're merging clang/LLVM into XCode and 
>> you'll never see a single line of source code of it again.
>
> And then we'll have to rely on the other contributors, like Google (one of 
> the biggest contributors to LLVM, as they are not moving a lot of their back 
> end code over to LLVM / Clang - they also employ more of the GCC team than 
> any other company at the moment).
>
> Open source works best when it's backed by self interest.  Apple benefits 
> from having a decent compiler with a reusable back end and a front end that 
> can be used for analysis as well as compilation.  If they developed it in 
> house then it would be more expensive than if they got outside contributors 
> to do some of the work.  Replace Apple with Google, Adobe, or any of the 
> other company or individual that contributes to LLVM / clang in the previous 
> sentence.
>
>> with clang/LLVM they don't have to, so at the next change of strategy, the 
>> whole thing could suddenly disappear into Apple and all you'll get from them 
>> will be your next binary-only, Apple Mac OS X-only, shipment of XCode.
>
> And we'll be no worse off than we are with GCC, where they've stopped adding 
> new features.  Apple would keep developing their private fork, non-Apple 
> contributors would continue to work on the main branch.  Take a look at the 
> top 10 LLVM contributors and you'll see a lot of non-Apple people.
>
>> Anyhow, the point of the rant is that I do prefer GCC to clang purely due to 
>> the different licensing.  And I do prefer the GNU runtime
>> to your runtime for exactly the same reasons.  And I expect that some (not 
>> all) of the people who try GNUstep may feel the same way
>> and may be trying GNUstep precisely because they don't like the Apple 
>> licenses, environments and corporate practices.  They
>> would be looking for a better alternative; an environment with higher moral 
>> standards and stronger rules to stop big corporations
>> from abusing the small guys.  In that case, giving them a GNU GPLv3 compiler 
>> (such as GCC 4.6.0) seems an excellent idea.
>
> These people are, of course, free to use whichever platform they want.  
> GNUstep has had a lot of new developers coming from iOS and OS X over the 
> past few years.  Read any news article about GNUstep, and you'll find OS X 
> developers complaining because they tried porting their Cocoa code, and it 
> didn't even compile because the compiler was missing features.  That kind of 
> first impression does the project no good at all.
>
> Like it or not, our main market at the moment is iOS / OS X developers.  Once 
> they're comfortable with GNUstep, you can pull them deeper into the Free 
> Software ecosystem, but forcing them to use tools that are less powerful than 
> the ones that they are used to because you consider the license to be too 
> permissive is not the way to make that happen.
>
>> Making everything depend on clang and your own runtime seems clearly a bad 
>> idea to me; certainly
>> not one that we want to recommend or present as an example.
>
> You are always free to improve GCC to bring it up to feature parity, but you 
> and the rest of the GCC team largely ignored Objective-C - including one 
> release that shipped with broken Objective-C because 'Objective-C is not a 
> release blocker' - for a decade and only started working on it again once 
> clang provided better Objective-C support on Linux / *BSD than GCC.  Given 
> this track record, I'm not sure I can take your comments about the 
> possibility of Apple abandoning support entirely seriously.
>
> David
>
> -- Sent from my Apple II
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>



-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)