When I asked the question on twitter about what problems people see in current way of F# development and growth.. one of the answers was:  "Enterprise people who think C# is the best and only the best are a problem ;) But I wouldn't know how to reach them...".

So I will try to express my thoughts on this topic here. I met a lot of enterprise people in my life. In particular, C# enterprise people. Speaking to them about F# is hard, because they have their own philosophy. The name of this philosophy is "Money". Now I am not talking about regular software engineers. I mean people who make decisions and have power to choose which direction their company is going and may influence all the potential changes. Imagine there is a company, not so small and not so big, 500 - 1000 employees or similar. And pretend there is one of the technical directors of the company, responsible for .NET stack. Here they have a bunch of C# projects: desktop, web, mobile, services, etc. for existing clients. The technical director feels pretty OK making money for the company, he also watches new trends in .NET stack, accurately evaluates the reasonableness of its usage inside their projects, and so on. Then imagine, what happens when a number of respectable architects from some of the main projects come to their boss to convince him to use F#.

First thoughts of regular management are like this: "What exactly is technical profit?", "How much will the money profit increase after this?", "If we save time, what is this time in terms of money?", "How long would it take for our company to get maximum profit from this decision?", "Do we loose something?", "Are we still paying the same salary to our software engineers?", "Is hiring of F# devs as easy as hiring of C# devs? Will we always be able to find them?"...

Usually good architects can give a good and really full answer to the first question about technical profit. But it is *enterprise*. It evaluates money at every step. F# is a cool language, it has amazing features, type inference, pattern matching, monads, type providers..... it's awesome, but it means nothing for your management. If you answer only the first question, your management will still have doubts about profit and reasonableness of this step. For enterprise commercial companies all changes have a cost and therefore, they should be proven with undeniable advantages, both technical and material.

And the big question for the F# governance and community is, who should clarify the rest of answers? I am not speaking of product companies who see the profit about technology usage or change. But for other companies, for which business is specific about having lots of different customers and clients and projects, it's unclear. So there are several options. We can describe technical advantages of F# in the language of money, looking from business perspective. We should operate facts, showing successful examples and numbers that obviosify the commercial profit. We should show the difference between current and suggested approaches, that must have *valuable* result, either hours of development time saved, or less support, or etc.

And another point is to construct the convincing presentation in the easy for understanding way. Enterprise people often have not enough time and are always busy. If they are happy with C#, why should they introduce something else?

So one of the main task for us, as F# community, is to create an easy way of helping enterprise companies to realize that F# will bring profit. We already started to work on this topic. And I believe we should do more and create the correct image of F# for the management of enterprise companies to help them understand when it may be commercially useful.

UPDATE. And sure, you shouldn't fix not broken things. You may want to change something only if it makes sense. Enterprise isn't stupid. It's smart and tough for decisions. Therefore its more diffclt to justify changes.

A funny video on the related topic.