I would say reasonably easy to start with, but needing a lot of ongoing effort for improvements, bug fixes, and so on, which is exactly why I think it's a dangerous combination for a small company.
I think they're likely to be an ongoing distraction for the above reason, and also because of the fun/intellectual challenge reason.
> punt on it and carry on using it in house.
Over time, that kind of thing can (if you're not careful) lead to dangerous cruft, where the in-house divergences pile up to the point where it's no longer so easy to go back and forth between the public/open version. And thus is born a new species with a far smaller ecosystem than the original.
"I think it's ... dangerous .. for a small company."
of non compiler/language processing experts.
If you've built compilers before and know what you are doing (I have no idea if these guys are such experts or not) , it may be a reasoned decision taken after weighing benefits and costs.
For example, I can easily imagine PG building a variant of lisp and building a product/company around that .
Of course if you only have a vague idea of how to build a compiler/interpreter/whatever, then building a company around your first such project may be ... interesting.
yeah sure. I first wrote "arc" and then replaced it with "a variant of lisp" then replaced "another company" with "a company" so the sentence reads oddly.
I think they're likely to be an ongoing distraction for the above reason, and also because of the fun/intellectual challenge reason.
> punt on it and carry on using it in house.
Over time, that kind of thing can (if you're not careful) lead to dangerous cruft, where the in-house divergences pile up to the point where it's no longer so easy to go back and forth between the public/open version. And thus is born a new species with a far smaller ecosystem than the original.