Split the "F# Core Engineering Group" and the "F# Open Projects Group"

[dsyme]

I was talking about this with @tpetricek, @ReedCopsey and @mathias-brandewinder, and it relates to @sergey-tihon's suggestion here: https://github.com/fsharp/fsharp.github.io/pull/13#issuecomment-64055161

The http://fsharp.github.io group has historically been called both "The F# Core Engineering Group" and "The F# Open Engineering Group". It seems it might be sensible to start thinking about splitting these aspects more carefully.

• The FSSF Core Engineering Group would be closely affiliated with the FSSF (effectively part of it) and have responsibility strictly for the core repositories and cross-platform releases of F#. The mission of the group would be specifically focused on fulfilling points 1 & 2 on the mission statement of the FSSF. They could still formulate recommendations and advice under the last bullet of the mission statement too ("Seeks to... expand the relevance and importance of F# skills and knowledge" etc.). The FSSF board (once established) would appoint one or more people (not necessarily on the board) to help guide this effort and to work with Microsoft, Xamarin, Debian etc.
• The F# Open Projects Group (or some other name) would be separate. The group would be affiliated with the FSSF just like many other groups and companies are, but either way the FSSF would seek to facilitate and support this group just like they support many other groups and companies. The group could do many things - but one thing would be to run "fsprojects", and help people to publish nuget packages and so on. They might also for example run an optional "badging" system so people can get a sense of how mature an F# package or project is - green badges for documentation, testing, completeness, stability, tutorials etc.
• The first group would publish software using the FSSF name (including the unadorned FSSF logo for F# or the name "fsharp.org"), if at all. It's possible the second group would use a different identity (fsprojects.org) or have individuals publish the packages.
• Some non-core projects not mentioned on the FSSF mission statement (such as FSharp.Charting) would likely be moved from http://github.com/fsharp (I've opened an issue on FSharp.Charting here )

I've been meaning to talk more with @sergey-tihon about this (I think he's interested in helping guide the second group and has been very active with logos already) but I thought I'd jot down the ideas here for broader feedback.

[ReedCopsey]

There are some points which I think could be addressed immediately:

• I agree 100% with trying to move "non-core" projects out of fsharp and into fsprojects (or elsewhere, depending on the project and maintainers). That would help make the current state of the projects consistent. This would also help differentiate between "core" and "non-core" projects within FSSF, inline with the mission statement.
• I agree that the FSSF Core Engineering Group should be closely affiliated (and actually part of) FSSF directly. This would typically be done as a board committee/working group, and given "official" status via a resolution by the Board of Trustees. As this already fits with the mission and history of how FSSF has been run, I will add this to the agenda for the next Board meeting.

As for the other proposals - I think we should move slowly. My thought would be that it might be helpful to create a list of the projects within fsprojects, noting the main maintainer(s), current quality levels when known, etc. This might help determine the proper course of action, and allow everybody to formulate the best proposals for how to move this forward.

As for moving fsprojects into a separately managed group, not under FSSF, this may be a good idea, but I think it's something we should do slowly. I am hesitant to introduce large changes immediately after establishment, especially without discussion.

The mission statement is broad enough that it could easily be argued that fsprojects could stay under FSSF, given the inclusion of "assorted tools and applications" in point 1, and "may perform these services on behalf of other open source F#-related codebases" in point 2.

As FSSF has been involved in managing these during its life as an informal organization, I think it might be worth having some broader discussion among the membership as it becomes formal prior to making dramatic changes to how this is managed and operated.

[Bellarmine-Head]

Since 1985 I have worked for enterprises that have looked to Microsoft alone for all the software bits that are "of a standard". Since 2002 we have trusted Microsoft to deliver .NET frameworks / libraries that:-

• are of a high standard
• are documented in a standard way
• conform to the Framework Design Guidelines
• have internal consistency, and are consistent with other Microsoft components
• have been passed through FxCop / Code Analysis, with all the issues fixed or justified
• in general: dot all the i's and cross all the t's.

It's long-winded and tedious to go the whole hog on this, which is why Microsoft pay people to do it. In our new, open world that is reliant on community contributions, it's understandable that these boring but necessary things don't always get done.

To provide the same level of trust and reliability that we've been used to, I think that there should be the strongest possible link between the FSSF and the "The F# Core Engineering Group". There should also be an "FSSF Projects" space / group / project / identity that houses non-core, functionally-idiomatic libraries / frameworks / components that conform to all of my bullet-points above, and conform to all of the FSSF's Core Engineering Group's guidelines and specific engineering advice. This conformity should be guaranteed by the FSSF.

Incubation projects are devolved, but as they mature their maintainers may seek to promote them to the level of being admitted to "FSSF Projects".

It all comes down to trust. To gain trust, the quality must be there and (like justice) the quality must be seen to be there. In our new, "open .NET" world, the FSSF is well poised to lead the way in showing how quality and trust and consistency can be maintained without over-reliance on Microsoft.

[dsyme]

Hi Andrew,

Like anyone familiar with the .NET design processes, I'm highly sympathetic with the quality goals and design processes you describe. The F# ecosystem is based on the work of Microsoft on both F# itself and the .NET ecosystem, and F# benefits enormously from these solid foundations. Let's call this a "Microsoft-style" base for a software ecosystem.

That said, I'd like to see community dynamics that don't place the full responsibility for a "Microsoft-style" ecosystem on the FSSF.

The FSSF is primarily "a voice for F#" - a neutral, open community organization that is entirely dedicated to the promote, protect and advance the language, as described in its mission statement. The mission statement may evolve and be clarified over time. But at the moment it's not quite an open source software foundry like the Apache foundation (though it may certainly have a role facilitating, soliciting and managing open source repos), nor like the .NET Foundation. It's a different thing.

Now, there are many things involved in being a "voice for F#" and "promoting, protecting and advancing" the language. Open source, commercial, enterprise, incubation, quality, guidelines, community, conferences, social media, some "Microsoft-style" gatekeeping but also much more.

The key to the FSSF will always be to work with a range of groups and companies to continue to make great things happen. Even today, the FSSF acknowledge and appreciate the key contribution of the Microsoft Visual F# Tools team in acting as quality gatekeepers for community contributions. It's not a role the FSSF plays today - Microsoft have it covered and that's great. Likewise, it's inevitable that the FSSF also need to work and encourage organizations that don't do full "Microsoft-style" gatekeeping on software (for example, at another extreme, people running hackathons or coding dojos). Quality at the core is non-negotiable though, as you say.

Cheers, Don

[dsyme]

Reed - I agree with everything you say - and you are right about the mission statement being broader than I made it out to be : )

There's a related interesting discussion about core/non-core projects here: https://github.com/fsharp/FsCheck/issues/69.

Cheers! Don

[sergey-tihon]

I agree with @ReedCopsey that we should move slowly here to find the right direction. Also I agree with @dsyme that we need to distinguish The FSSF Core Engineering Group and The F# Open Projects Group. But I really think that we need to split fsprojects for more part.

The first step is to separation of The FSSF Core Engineering Group that focus on lang, IDE support, core tooling like FCS and cross platform compatibility. This group own and live inside fsharp organizations and publish guidelines for others fsharp.github.io.

The second step is to define The F# Open Projects Group. According to my thought this group should maintain projects critical to F# ecosystem, like FAKE, Fsharp.Formatting, FsCheck, FsUnit, maybe Paket in one day. I see these projects in new organization, for example fsinfrastructure.

I prefer to keep fsprojects as a playground for new ideas and a place that can help people to know each other and understand that they are ready to build new org and take an ownership of some projects.

For example I believe that we are ready to have FSharp.Data organization with FSharp.Data, FSharp.Data.SqlClient, FSharp.Data.DbPedia, FSharp.Data.Toolbox, FSharp.Data.HiveProvider, FSharp.Data.Experimental.XenomorphProvider inside. It is more than enough projects for new org that care about TPs for data access...

The same is also true for FSharp.Cloud: we have a lot of projects for Azure & Amazon + active maintainers and contributors like @isaacabraham and @theburningmonk who can care about Cloud-domain projects.

The same rule should be applicable for other approved second-level namespaces from Recommended Guidelines for F# Projects:

• FSharp.Control
• FSharp.Text
• FSharp.Net
• FSharp.Client
• FSharp.Compiler

If we have a domain, approved second-level namespace and people willing to maintain this domain - this is good sign for new organization that are ready to work independent and outside of fsprojects.

It should help to decentralize management of F# projects and organize domain expert in more precise and focused groups.

[dsyme]

I'm closing this because this split has generally happened (fsprojects has a brand separate to the core "fsharp" projects now)