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

General
1

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

@halcwb 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. First created by Thomas Petricek, but then left afloat for a lot of years, while being used by many other libraries like ProjectScaffold 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.

2

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. :man_shrugging: :slightly_frowning_face:

(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. :pensive:)

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. :wink:

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.

1 Like
3

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.

2 Likes
4

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

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.

3 Likes
5

:100: Absolutely this :100:

1 Like
6

Some really good points. And if I may summarize the most important:

  1. There has to be agreement what are ‘core libraries’ essential to the F# ecosystem.
  2. These projects should be sponsored.
  3. Core libraries should target .NET in general, not just F# (which FAKE and Paket and others are doing actually really well, I think).

I am sure I am not the first who realizes these points. The question remains how to proceed from here?

7

I am surely want to help as I use Fake for a lot of things.
But where do I start and what issues do I tackle first?

I know there was once a mentorship for F# (maybe it still exists). So my question is is there a mentorship of some sort to help me get started in contributing to F# OSS projects?
If Fake has some low hanging fruits issues I am willing to start with them if someone can help me start.

8

AFAIK there is a mentorship program:

https://fsharp.org/mentorship/

9

Phil

One way that may support this - by lowering the barrier to entry somehow - could be to have some searchable directory of projects that are seeking e.g. financial support, with details of what they’re looking for, who it is, what the contributions would help guarantee etc.

I think that things like this can work - Ionide on Open Collective is a good example of that - but perhaps having a landing zone for corporations who are interested in contributing would help?

2 Likes
10

We’re starting to experiment with F# on the company I work with, and we have the endorsement of the CTO to do so (not only use it in our next projects but give back contributions to the community as well).

The main problem we’re facing rn is:

  • Architectural decisions on how do things on F# and which tools to use.

  • What and how to contribute back to the community.

So, as @isaacabraham pointed out;

but perhaps having a landing zone for corporations who are interested in contributing would help?

I’m a manager myself. It would be really helpful for me to have a list like this, of things we could do that solve the problem 1 & 2, then I can ask the CTO for resources to do so.

3 Likes
11

First of all I think you will find F# an excellent choice for the type of software you are writing. F# excels in complex modelling and data science.

As for your question on architectural decisions. I think on a high level F# can be used exactly as you would use C#. On a per project (solution) level I think that MiniScaffold gives a very complete picture how a skeleton setup looks like for an F# project.

As for the what and how to contribute back to the community, I am not in a position to give any answers. But I am sure a lot of people could help you with that in the F# community.

As a side note, looking at your company I am interested as I am creating software for decision support for medical purposes. Please contact me if you would be willing to discuss this.

1 Like
13

Possibly relevant to the conversation here:

1 Like