>And because we didn't control the master source code for gcc, one of our senior compiler hackers, Jim Wilson, spent a huge fraction of his time merging our cha

>And because we didn't control the master source code for gcc, one of our senior compiler hackers, Jim Wilson, spent a huge fraction of his time merging our changes upstream into FSF GCC, and merging their changes downstream into our product, keeping the ecosystem in sync. We handled that overhead for significant other tools by taking up the whole work of maintenance and release engineering -- for example, I became FSF's maintainer for gdb. I would make an FSF GDB release two weeks before Cygnus would make its own integrated toolchain releases. If bug reports didn't start streaming in within days from the free software community, we knew we had made a solid release; and we had time to patch anything that turned up, before our customers got it from us on cartridge tapes. They get it. Man. I've seen first hand how unsustainable it actually is to adopt a "private fork" (in spirit because of course anyone can GPL request your source) business model. Your stuff stagnates and falls behind upstream because your business is elsewhere. You didn't have the discipline or acumen or backbone to work with upstream from the get go so the effort required come time to update everything is utterly massive and can easily amount to decades of engineering time. It's possible the leadership never really understood how software works and was convinced it would be a risk to contribute back upstream, but it's no excuse if you ask me. It's your responsibility as an engineer to help them understand. I wish more business and lawyer and founder types understood software licensing and how to make money in the software ecosystem beyond pure cloud SASS.