Can F# afford losing FAKE (and other libraries)?

I while ago I created an issue related to another issue 36 regarding a problem with an the use of an older version of paket. The reply from the maintainer was this:

@halcwb 1 Sorry, I kind of lost motivation for various reasons. Nobody volunteered yet to take over. And to be honest some people prefer the “the build as a project && dotnet run” approach which doesn’t have issues like these and might be a way out of this as I guess you are not volunteering to take over.

And I really understand the problem from the maintainers perspective. Also, I had to admit that I am really no real programmer at all, but a pediatric intensivist, very enthousiastic using F#.

Moreover, I feel that there is a bigger underlying problem, i.e. there are more extremely usefull and beautiful libraries that have a similar problem. They are created by some very smart people, but those people move on. Another example is the FSharp.Formatting library 13. First created by Thomas Petricek, but then left afloat for a lot of years, while being used by many other libraries like ProjectScaffold 4 which suffered a similar fate. Therefore, this problem can even cascade through multiple projects.

So, I have to admit, I am not part of a solution, but I do experience the problem. Also, I think this can be quite an existential threat to F# as a language. There should be an overall organisation that can supply the necessary every day task of maintaining the really core libraries for F#. Microsoft, are you listening?

Interested to know other views on this.

First and foremost, the issue described is not unique to F#. It is a common problem for all free software projects.

And I appreciate your disappointment and your concerns. It’s really depressing to watch a good project “wither on the vine”. But I don’t see the larger systemic issues being addressed in a meaningful way by the (relatively) small and resource-constrained folks who make up the vast majority of active contributors to open-source F# projects.

(Aside: Project Scaffold was only ever meant to be a learning tool. That folks would take a hard dependency on it was… flattering. But it was also a “use at your own risk” situation.

Then again, maybe that should’ve been better communicated. Lesson learned. )

Further, with respect to:

There should be an overall organisation that can supply the necessary every day task of maintaining the really core libraries for F#

The key point is: who decides what is (or isn’t) “really core libraries”? Don? The FSSF? There will certainly always be many more projects than there will ever be available resources. So what criteria does one use? No easy answers.

In any event, I wouldn’t expect much more from Microsoft. In fact, one might argue that Microsoft has already decided – based on where they do and do not contribute – which projects are “core” for their interests.

That’s not to say that other companies (or non-profit organizations) couldn’t do more. However, it’s not a cut-and-dried problem. There are issues of: time, money, and – most importantly – ownership. In fact, we can see that a few of the smaller companies who leverage F# do contribute back, in terms of both money and patches. However, this is still a drop in the bucket, so to speak. And, as with Microsoft, they contribute where it’s aligned to their interests. So what happens when their needs and yours differ? No easy answers.

All this having been said, if folks have ideas for improving things, I’m very eager to hear them.

FSharp.Formatting is actively maintained. Not sure about FAKE and ProjectScaffold but they are not necessary for F# users and are not beginner tools. It’s likely that ProjectScaffold gets less popular as “File → New Project” and “dotnet new” produce well scaffolded projects that are cleaner.

The problem with the F# library ecosystem is that it is VERY insular. People write libraries in F# for F#. Writing in F# is great. However most libraries should be written for .Net instead: the traction would be much larger and .Net is a perfectly good API target. While F#-F# sometimes results in better APIs (e.g. Fabulous), the restriction to .Net APIs would improve most libraries by preventing excesses (a common culprit is crazy operators).

Libraries which are written for F# which should be written for .Net include: FAKE, Farmer, most type providers (the erasing ones). If these were retargeted it would 1. help them remain actively maintained projects 2. integrate F# by bringing in contributors who normally work in other languages and turning F# into a useful producer language not just a consumer one.

You made excellent points here, so I’ll add to them

All this having been said, if folks have ideas for improving things, I’m very eager to hear them.

This is something that other OSS maintainers have said, but the solution here is to have industrial users / corporate partners step up with significant sponsorships or contributions.

Microsoft (as a corporate entity) already contributes far and away the most into the F# ecosystem by:

• Building and maintaining the compiler, tools for VS and VSMac, .NET SDK distribution, build from source distribution, and documentation
• Paying employees to spend time helping maintain things relevant to their business interests (FSharp.Formatting, XPlot, FSharp.Data)
• Hiring people on contract to complete work that is mutually beneficial (Ionide for several months in 2019)
• Solving upstream issues that mainly impact one OSS library specifically to unblock them (most recent example was unblocking someone building tools for wasm)
• Incorporating several projects into manual integration testing (SAFE Stack)

There are thousands of other corporate entities out there who rely on F# and a subset of them undoubtedly also rely on FAKE, paket, and other parts of the F# OSS ecosystem. It is absolutely within their power to get some skin in the game and help support an ecosystem they’ve made money with.

A fine example of this is G-Research, who have paid their employees to contribute back to several projects (including dotnet/fsharp!) and also paid OSS authors to implement mutually beneficial work for them. Another example is JetBrains, who build wonderful IDE support for F# in Rider.

Which other corporate entities are willing to step up as well? It’s not terribly expensive to help maintain a project like FAKE from a corporate perspective. If one person could revamp it and maintain it for several years in his spare time, someone being paid to maintain it certainly can pull it off. This requires employees to also ask for this, though. You have to make the case that it’s good for your business, and you won’t always be successful. That’s fine though, because there are many thousands of corporate entities using F# that could afford it, so if enough people really do try and convince their management that this is a useful investment, I’m quite positive at least one will step up and help maintain FAKE.