As someone working on a compiler which is not a primary business of this company I disagree. Our main product is a large library with quite a lot man-years of work put into it that we offer on lots of different platforms and frameworks – for the most part with near-identical API and capabilities. Compiling the source into different languages rather than rewriting everything is a very valid approach. In our case almost all bugfixes and new features can be merged directly into the other products and work (the exception being the glue parts to the respective platform/framework).
Being able to precisely control the output and thus guarantee API stability is a major factor in developing this in-house, especially as most converters only concern themselves with replicating the visible behaviour of a complete application.
If you license the library, why not directly cross-compile it (using existing compilers) and then just write wrappers to expose it in the target languages?
I disagree, because there are SO many examples of companies and products that do this. Basically every data storage company, every networking company, every database company (meaning they wrote the OS)..
Not to mention wasabi is a transpiler! It took VB-ish stuff and turned it into a few target languages. This is senior year undergrad complexity that they used for 10 years.
Writing a compiler sounds scary to some people. It's not scary. The only compilers training I have is a senior-year undergraduate course, and quite a lot of that was learning all the different ways to write parsers. Wasabi uses a LL(k) recursive descent parser, and you don't have to know what that means to be able to work on it. I've never even read the Dragon book; we used Cooper & Torczon "Engineering a Compiler" instead.
I think it's perfectly legitimate for a company to build those things when it's not their core business, provided that A. They hire people who are legitimate experts and give them free reign to work on it, and B. They open-source it.
A lot of quality compilers and databases have come from software companies whose primary business is neither a compiler nor a database.
A company should never do secondary business X if their proprietary take on X does not contribute to their value proposition in a way that external solutions cannot provide.
At one time, for example, ice companies did their own deliveries because they needed special hore-drawn carriages to keep the ice cold.
This is silly. If you make a reasoned decision, taking into account your specific circumstances and the projected changes to come over the midterm, and you decide to do this, well, why not? Should Google not have built go? Should Jane Street not have built core? Should Facebook not have built their suite of tools? I'm comfortable saying that the super smart people who advocated for those projects (among numerous others) had a pretty good case to make.
Why not? Because it creates a maintenance nightmare and if it's not your core business that means it will never be a priority. Using Google and Facebook as a counter-example is silly. These are $250B+ companies and these tools are a significant part of their business.
Or chat tool, or bug tracker, or... The list goes on. Basically, focus on your core business. If you spend more than ~10% of your time building infrastructure tools, someone else probably does it better, for cheaper.
Being able to precisely control the output and thus guarantee API stability is a major factor in developing this in-house, especially as most converters only concern themselves with replicating the visible behaviour of a complete application.