Navigating the ecosystem of F# projects can be very cumbersome, and the lack of exposure of existing technologies leads developers to create solutions for problems that are already solved, and in many cases, go to other ecosystems for solutions. Neither of these encourage growth within the F# ecosystem, as would-be contributors aren’t contributing to F#.
Additionally, financial incentives encourage maintainers, and projects like OpenCollective help facilitate the process of funding projects. There there are several prerequisites to being involved in OpenCollective, as there needs to be planning and coordination of the work to be funded. The FSSF has no place in picking projects for funding, but could do a great deal towards helping projects mature and plan strategically so they are successful in gaining funding through these programs and attracting more funding to the programs themselves.
The FSSF could take an active role in promoting the ecosystem in two major ways:
- Provide a framework for F# projects to incubate that encourages these projects to easy to find and consume, well documented, and reasonably easy to contribute to.
- Engage with a funding program like OpenCollective or Patreon or the like, or partner with other open source organizations like Mozilla Foundation or Travis Foundation that have grant programs to fund more strategic projects.
The FSSF currently has a few lists of projects on the fsharp.org page and those projects are listed simply by sending a pull request, with little more than a snippet of information and placement in some category (i.e. GPU, database tools, cloud). The information gets outdated (funscript is still there), but is also lacking in information for consumers regarding platform support, documentation, build status, licensing, contribution process, etc. Compare this to the Apache Software Foundation’s Incubator: http://incubator.apache.org. There are licensing and project guidelines, to encourage projects to maintain a certain level of fitness for inclusion and promotion in the incubator. And there are various listings of projects based on their categories and incubator status. IP clearance documents reduce the friction for use of those libraries.
An incubator program should include policies that encourage projects to be well defined, documented, actively maintained, and encourage contribution.
- Category
- Source repository link
- Links to documentation covering both usage and project strategy
- Nuget or other release archive
- License and copyright
- Platform support with CI badges and dates
- Maintainer listing
- Contribution process
- Release schedule
Much like nuget packages, much of this information is optional, but the more complete information provided, the better the listing is. There is certainly some initial setup, but after the fact, maintainers can contribute their information, and after some quick review to ensure quality, the listing is updated. This can lead to a “tiered incubation” where projects that provide complete information and gain maturity can be promoted according to a policy set by a working group of FSSF members.
This information is fundamental to gaining funding. A lot of projects run with little more than a GitHub repository with an issue listing that is largely tactical, and, at best, that leads to sporadic financing. To get significant or ongoing funding takes presenting a strategy. Again, this is largely up to the projects to promote themselves. The FSSF should provide the framework and guidelines for promotion, but can’t pick projects for funding. The FSSF could also facilitate engagement with a program like OpenCollective or partnerships like Mozilla Grants, to help align the strategies of financiers with F# projects that support them.
I’d really like to hear people’s thoughts on this, especially areas they’ve seen these sorts of programs succeed or fail and the practicality of it.