Hacker News new | past | comments | ask | show | jobs | submit login

I think the dislike of LLVM stems mostly from the company behind it. As you may know, Apple contributed a fair amount of code to GCC, but they also kept a lot of code for themselves. (They did, of course, make it available per GPL, but did not try to submit it upstream.) There have also been problems in the way Apple contributed code; see the mailing list archives for details.

I think there's also some dislike of the project itself, or perhaps the people behind it. But that's another discussion.

> The problem are always an excessive centralisation of stewardship... which is kind of ironic coming from the guy who most strongly supported free software.

I don't think it's so much centralization of stewardship for technical decisions, but stewardship of the rights to the code; i.e. you need to sign copyright papers before committing non-trivial patches. And I can assure you that the FSF sees doing so as strongly supporting the cause of free software. There are obvious counterexamples (the Linux kernel's more lax Signed-off-by policy comes to mind), but there are reasons why this centralization is done.

I know this centralization causes problems. Getting assignment papers submitted if you are at a university is a pain; your employer may not be keen on signing them either. It'd be nice to see the process streamlined, or even banished entirely, but I doubt that's going to happen.

> I think it's got only itself to blame, and a certain type of elitist arrogance.

I'm curious where you think this "elitist arrogance" comes from or even what sort of behaviors you're referring to. Can you elaborate?




Wasn't one of the problem with Apple and GCC that Apple had to hack the GCC to integrate it with the rest of its tools (which obviously the GCC people couldn't care less about)?

When it comes to the topic of stewardship the situation is less clear cut from my point of view. I think there's a (very human) feeling of "I've created this toy so I get to decide". In part it's a good attitude: if you managed to develop it this far there are good chances you'll be able to develop it further. But sometimes it makes people a bit blind when something better comes along.

In that sense using technological reasons, or the cause of free software, seem to be more of a way to (maybe not on purpose) push away whoever wants to change the way things are run. But that's purely a gut feeling.

Incidentally that's what I tried to convey with "elitist arrogance". This kind of "we know best" and "who are you? what are your credentials?" attitudes. Though I am not surprised it only made thinks more confused to a reader. Sorry about that. :)


I don't know the full story about Apple and GCC; I haven't read all of the mailing list traffic during the relevant period, nor was I around to hear about offline conversations. Certainly I can see Apple modifying bits of GCC to make it more suitable for IDE integration and upstream not caring about that. Apple did have ways of getting such changes in, though; it's possible they didn't care enough to push them upstream.

As for "elitist arrogance", I think what you are getting at is that you see the FSF's policies as erecting a moat and a wall around GCC and telling the rabble to stay out while the nobility quietly hack away at their desks. If I have understood you correctly, then I see the argument, but I do not agree with it. As long as GCC is an FSF project, that's just the way things are going to be. I don't think the FSF has set out with the intent to be "elitist"; it's unfortunate if that's the way the policy is perceived. Feel free to correct me; it's possible that I've misunderstood you.

The FSF does not, on the whole, dictate the technical direction of the project. So the goodness or badness of technical changes and any "elitism" associated with acceptance or rejection of such changes is another issue.

Perhaps things will change if GCC ever disassociated itself from the FSF: another egcs-style fork or something more dramatic. There have been small rumblings of such a change, but I think such an event is quite unlikely.


Please understand that I don't think the FSF ever set out with the intent of being "elitist", and I appreciate what they are trying to do. Although I often do not agree with the methods, I am happy they exist.

I like your example of the moat. I think though that nobility is not very much defined in your metaphor. After some thought I think there is a strong sense of community maybe, where those who've worked there the longest are those who become the "nobility". And people do not want a "foreigner" to come and change their ways, even though he may back his ideas with facts and good arguments.

In a way, a method that made sense once, is used for such a long time that at some point it becomes more of an "ideology", like a nationalistic feeling.


I think it's a lot less drama-inducing to consider any Apple contribution to open-source as a fork of the original project. The KHTML people were just as annoyed that Apple were bad open-source citizens, but there's nothing in any FLOSS license that requires you to play nice with the existing maintainers of any project if you don't want to.


> They did, of course, make [GCC code] available per GPL

If you're talking about the NeXT ObjC frontend, that wasn't a matter of course. It actually took legal threats to get them to meet that obligation.


I wasn't thinking about the ObjC frontend; the ObjC frontend, AIUI, was contributed by NeXT before NeXT became a part of Apple.

If you go grab the GCC tarball Apple provides, it has many, many changes from the GCC 4.2 sourcebase. Lots of those changes have not been submitted back upstream. The code is available, granted, but it's not available in a way that's helpful to anybody but Apple.


So? They complied with the GPL. Why is it that people also expect companies to push code changes back upstream, maintain said parts of code upstream and properly document said patches?

If upstream wants patches so badly they can download the tar-ball provided by Apple, diff the two source trees and document, and submit those patches to the upstream. It is not the companies responsibility to do so. The GPL only states that it MUST make the source code and its changes available.




Consider applying for YC's first-ever Fall batch! Applications are open till Aug 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: