Skip to content

Instantly share code, notes, and snippets.

@houstonhaynes
Last active November 4, 2021 18:39
Show Gist options
  • Save houstonhaynes/7181e8a9243337de31cb8bdbee21b64f to your computer and use it in GitHub Desktop.
Save houstonhaynes/7181e8a9243337de31cb8bdbee21b64f to your computer and use it in GitHub Desktop.
High level outline

tl;dr

The main problem is not that the "F# option" is presented and rejected on its merits - the main problem is that the "F# option" is suggested and the answer is ...

  • 'What are you talking about?'
  • 'What is that?'
  • 'I've never heard of that before.'

F# has a mindshare problem. There are many ways to approach correcting that, and will probably require multiple approaches. For the FSSF's part of that effort there are both top-down and bottom-up efforts that should be considered.

Top-Down

This really should be the job of Microsoft - however - as everyone here should recognize the "memetic independence" of F# comes at a cost. So the FSSF should undertake projects/efforts to raise the awareness of business leaders on the value of the F#-in-.NET ecosystem.

This means producing materials that will be approachable by business leaders who know nothing about the language. I think what Don Syme started with the "Focus on F#" event is a great start in this department, but coming up with an "elevator pitch" and getting it into the ears of decision-makers is something the FSSF is uniquely positioned to do and falls well within purview of creating a more fertile area for F# developers to find more paying work.

These artifacts could be useful for presenters that need a few "business slides" for a technical presentation, but the emphasis I'm making here is for the FSSF to recognize - with it's programs and funding - that more to the role of the organization than getting JavaScript developers to look at F#. If you get the business leaders to recognize it - the work will follow.

Bottom-Up

Like the mentorship program there are additional efforts that the FSSF can undertake to help individual developers "grow the pie". Making OSS projects more contributor-friendly can help significantly with organic growth and adoption. So setting up a "practices and patterns" guide for maintainers would help to "level up" the projects and help support a more inviting experience for early contributors who might otherwise be put off by a project.

This is something that I found at "All Things Open" which was a point of emphasis. There are projects under way (primarily headed by GitHub's "All In") to help maintainers to be more supportive of contributors, particularly those who are coming to tech from non-traditional learning backgrounds.

It's also worth noting that the "All Things Open" conference was almost 100% on "hacking" projects and mob programming learning models - and absolute 0% interest in "academic" paths into software engineering. It was not subtle - Major League Hacking had a presence as big as Red Hat and Suse - and universities were nowhere to be found.

Even Microsoft is starting a security engineering program at community colleges here in the US. Shorter-form 1-to-2 year programs that skip past the university system completely.

So while I think it's incumbent for the FSSF to support a formal curriculum, I'm less set on the idea than I was a few weeks ago. The "All Things Open" Conference really was an eye-opener for me.

Summary

I believe that it is in the interest of F# developers world-wide for the FSSF to be more "out there" in the marketplace of ideas. Those efforts should include business-directed efforts as well as technical and community support, especially for supporting a more inclusive OSS environment.

CODA: regarding individual projects and perception

And while there shouldn't be "picking winners and losers" I also believe that the FSSF should be unafraid to recognize/support those OSS projects that both embrace foundation initiatives and provide fertile ground for bringing more aspiring engineers to the ecosystem. If OSS projects are concerned about "winners and losers" perhaps they can think more on "inclusion versus navel-gazing".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment