GCC - 'We make free software affordable'

As for GCC, I think the pain points are twofold: the documentation for the middle-end is somewhat scattered. I honestly think enough information for figuring things out is present, it's just not always obvious where to look. There are lots of other passes to look at too, which can be extremely helpful. Assumptions of the interface, or side-effects, are not always stated, which can be surprising at times. The other pain point is contributing upstream: you're going to get dinged on formatting, documentation (usually just "did you do it"; the review is generally not as thorough as say, GDB's documentation review), compilation time, etc. etc.

Also, GCC's hash tables (htab_t) are a pain to use correctly.

Of course, my experience is somewhat slanted towards the middle-end; the set of pain points is somewhat different if you are working in the front-end or the back-end. And my set of pain points from the middle-end might be different if I had worked on different optimization passes. (My passes cared very little about things like aliasing, for instance.)

It's surprising to me that you mention memory management as a pain point, though I can see how the variety can be bewildering. The only distinction that really matters is between GC'd and non-GC'd memory. obstacks and alloc pools are only ways of providing specialized malloc interfaces. A useful rule of thumb is that if your data is only needed for one pass of the compiler, then you can allocate it any way you like; if the data is longer-lived than that, it needs to go in GC'd memory. I can elaborate if you'd like, but that's the basic idea.

FWIW, I agree that the whole GC system is somewhat baroque. The GC was a decent solution to an engineering problem and the whole mechanism nicely solved memory management problems and provided the basis for precompiled headers, but it causes problems in other ways nowadays and trying to get rid of it would be a huge effort.

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.

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.

a) Apple's kernel is open source: having used GPL would not have made any difference here b) The other BSDs have openly stated that Apple contributed back and thanked them for it.

Not only that, there are a lot of open source technologies that Apple has contributed to or is the main company behind it. In fact to find an example you didn't need to go any further than LLVM (discussed in this article). Apple is the company most strongly behind LLVM: they could continue in house without contributing any of the source, but they don't (and why should they? What advantage would it give them?).

Finally and I think the most important thing, is to ask: had those technologies been GPLed, would the companies have contributed back (as you seem to expect), dumped it all on their website, or simply have refused to use that code?

(edited for grammar)