The external consultant developers are incentivized to keep essential knowledge to themselves, in order to get new contracts later. The supplier's IT consultants (Bekk) don't share essential knowledge with the customer's developers (Vy).

We're working at the same location. On the same codebase. With the same access to our version control and issue tracker. There is full transparency. We even help Vy train their new hires.

We're incentivized to work this way because that makes the customer feel safe. Which is how we win contracts.

It might be that way where you work, but that's definitely not the case here.

In fact, I think what you suggest would be an extremely short-sighted "strategy" for a consultancy. Sure, you might get the next contract working this way. But once the customer could get rid of you they would, and they would never hire you again.

Then please answer why Elm was chosen instead of some mainstream programming language/framework. Choosing Elm seems like a very risky choice for something as important as railways.

Elm is a frontend language. Java works on the backend.

At Vy, Elm is used for frontend, Java and Kotlin for backend.

This doesn't address the issue of mainstream technology, versus bleeding-edge, obscure, niche technology such as Elm.

Kotlin in the backend isn't a mainstream technology choice either.

Elm was chosen because we believed it to be a better language than those which are mainstream right now. We believed it would make us more productive, prevent bugs before they reached production, be better at local reasoning and make it easier to onboard new people.

So far we are not dissapointed, and in my opinion Elm is on its way to become mainstream because of these things.