@kanishka Was asking me about my economic model, which I didn’t do a very good job of explaining. As I like to keep the conversation in the open, here is my reply.
Yes, this is not money that needs to be raised.
I probably did not do a very good job of explaining my economic model - the point of it is is really just to act as a frame of reference when the conversation turns to money. Essentially I am claiming that Elm as it stands is worth something like $11 million.
Maybe the company you work for has a warehouse with $11 million worth of goods in it. You can bet the finance department knows this and also the fire, flood or theft risks. The warehouse will be insured to cover a potential $11 million loss if something goes badly wrong.
Imagine that since Elm is not maintained satisfactorily, a concensus forms that businesses should not use it. The company you work for uses Elm extensively, but needs to ask the question - If Elms falls out of favor and we are the last company left using it, we have to choose to maintain that £11 million software stack ourselves, or more likely abandon it and move to React/Svelte/Vue/Typescript/whatever. I cannot guess the cost of doing that, as it depends on the codebase to be re-written, but for example I work on a 150K LOC Elm codebase, which would easily cost > $1 million to rewrite.
The alternative is that we get people on board from a wide range of organisations using Elm and share the maintenance cost of that $11 million software stack between them.
Some places may be happy to chip in a $ contribution towards the effort. Some places are going to want something in return. Ultimately control is what gives them security.
Currently if you hit a bug in Elm, you have no way of getting it fixed. If Elm was a “real open source” project that had multiple maintainers and actively reviewed and applied acceptable submitted patches, and had a public mailing list where the review process is conducted in an orderly and fair way, there would at least be a process for fixing things and a degree of control.
A business with a serious investment in Elm might also want a degree of control by having one of its own staff become one of those maintainers.
So the $ contributions, patches or funding maintainers are all economic costs that we might ask to be contributed towards a shared effort. Of course staff time can be translated to $, so all of this can be though of as the baseline cost of insuring that $11 million software stack.
My gut feeling is that the maintenance cost is much lower than $200K/year. $200K/year would get you 1 full time employee of the educational level of Evan - a computer science graduate with the ability to drive the language forward. Maybe thats something that we ultimately want to do, but I think the baseline cost of maintenance would be far lower. We are really just talking about reviewing and applying patches.
I think the patching type activity is better contributed towards by allowing company staff a bit of company time to be maintainers of Elm. It would be better if more people are involved in this activity, rather than finding money to fund 1 person. The reason I think that is that patches would need to be carefully reviewed and assessed for their impact on the overall system - we want to fix bugs not introduce new unforeseen problems, and this needs to be conducted in an open and transparent way where it can be seen by many eyes in order to avoid mistakes.
Just occurred to me that I should add the caveat. When I say “Elm” I don’t mean Elm as it currently stands, or that this is the right model for Elm, or that I am giving advice that things ought to work this way. I am talking about a model for a hypothetical fork of Elm that might better suit the needs of commercial users.