Location of tooling projects [ was: Move to fsprojects? ] #69
Comments
|
Another option would be to have an organization hosting all "infrastructure" related projects like FAKE, Paket, F# Formatting, FsCheck, FsUnit & ProjectScaffold - that might be a nice logical grouping. Essentially, everything that the F# community cannot live without when creating new projects in one place. Incidentally, this should actually probably be another working group under F# foundation - because there has been a lot of activity around this topic - and having a separate group to discuss plans might be a good idea! |
|
Yes, it does seem that FAKE, Paket, FsCheck, FsUnit or ProjectScaffold don't fall directly within points 1 & 2 of the mission statement of the FSSF, which is about the language itself. Of course the FSSF is 100% supportive of these initiatives nevertheless. I think F# Formatting could potentially be seen as a very core tool - it is quite normal for core language tooling to have very strong opinions about code-integrated documentation (in-code XML docs, literate programming etc) since it forms part of the core textual programming model of the language. But it's borderline. I personally don't mind how the other projects get grouped. Structural groupings can be unstable in the long term, so I often advocate the "one big bucket" approach from which other groupings emerge. But equally using other groupings is totally fine. There are pros and cons both ways. All the groupings you mention above make sense and would help. In any case sounds like we're in general agreement. |
|
I actually prefer at this point to just move FsCheck back to my own account instead. It doesn't sound like fsprojects organization as a structure is stable and I'd like to avoid the moving things around busywork it may generate in the future. Note though that fsharp/FsCheck is currently the "root" project on GitHub, so please don't delete it while I try to sort things out. |
|
@kurtschelfthout - could you wait and work with us? There's no rush to make any changes here, and I'm confident any changes will be purely for the positive. At least, please discuss things with us. FsCheck gets real visibility through its location here, and that benefits both the tool and its users. Also, from my experience projects in organizations are more likely to get broader use, contribution and trust. "fsprojects" itself is certainly stable, and there are a whole host of very successful projects there (Paket, VisualFSharpPowerTools, FSharp.Data.SQLClient, SQLProvider and others). Nothing is going to change there. Can I ask - would you consider having FsCheck be part of an "fstools" grouping if it were created? |
dsyme
changed the title
|
@kurtschelfthout I completely understand your reluctance to move FsCheck to "fsprojects" - I think I have exactly the same thing with F# Formatting, which currently lives in my own profile too! I don't really have a single clear reason for this, but I simply don't feel that there is a good reason for putting all F#-related projects under a single organization - especially if the organization does not have any "real" organization behind it now that FSSF focuses on "fsharp" (yes, it helps with visibility as an "incubation space" for new projects, so I'm happy that "fsprojects" exists for those who want to use it). I guess any grouping will always be imperfect - for example, what about libraries that can also be used from C# but are used by the F# community? But I quite like the idea of building an organization behind "ProjectScaffold" and related tools. IMO, grouping those makes sense - because there is a clear "story" behind it. And it would be good to actually have an organization behind this where we can discuss e.g. project scaffold plans and call for help with other projects (FsUnit could use some tweaks) - this kind of thing worked very well with Machine learning & Data science group - and I think "infrastructure" is exactly the case of what @dsyme called "emerging grouping" :-) /cc @forki (FAKE, Paket) @dmohl (FsUnit) @pblasucci (ProjectScaffold) @mathias-brandewinder (share experience with ML group) |
|
Sure I'll wait just thought you wanted things out of fsharp org sooner rather than later. |
|
Just to clarify, I actually don't think of FsCheck as tooling - but maybe that's just me. Nor is it really F# specific, although I have to admit that historically my interest in making it really nice for other language has been low. I keep hoping someone shows up who can take on that part of the API and implementation - I could actually argue here that a contributing factor to why that hasn't happened yet, is that it's so strongly associated with F#. As a side note I don't quite understand the "incubation" part of fsprojects - incubating for what? :) Furtherrmore while I'm happy to contribute to a story around F# specific tooling - which I actually agree is a good idea - I'm not sure FsCheck should be part of that exclusively. (I am hoping for more organised open source activity in .NET now that MS has finally seen the light). Also for separate reasons we shouldn't be focussing on reifying things like that in an organisation on the source control/issue tracker level like GitHub. Separation of conerns and all that. |
|
@kurtschelfthout What you're saying makes complete sense to me - and actually pretty much matches my thoughts on this topic. I guess we can see if others would be interested in putting together a working group in this space - and then you can decide how you'll feel about it. I agree that FsCheck does not quite fit in a single tooling box - though I put it in that box in my Taking your craft seriously with F# talk and I think it is extremely valuable there (among other places). That said - FAKE, Paket and even F# Formatting and ProjectScaffold also don't aim to be F#-specific, but broader .NET. |
|
@kurtschelfthout - "Incubating" is just creating an environment which helps open source projects to reach maturity. "fsprojects" has been reasonably successful at this - it has given a home which has allowed some key F# community projects to mature, without exposing the FSSF to an ever-increasing number of projects in http://github.com/fsharp/fsharp (the original problem). It's also fair to say that ProjectScaffold has been key. Some good examples of successful incubation are VisualFSharpPowerTools and Paket. These are now maturing tools, also under active development, with multiple developers. FsCheck, F# Formatting, FAKE, Paket and ProjectScaffold are well past the incubation stage though :) |
|
@kurtschelfthout @tpetricek - it would be very cool to get some F# infrastructure projects into the .NET Foundation too (or other structures that evolve in more general .NET open source work) - some of these tools do seem to be good candidates for that, partly because they have a combined F#/C# orientation. |
|
So...more than a few months have passed. Has anything new come up? To reiterate I'm happy to move Fscheck "out of the way" of the fsharp organization, as I do agree it's probably better to keep F# compiler etc there only. I'm just not too sure about the fsprojects destination. |
|
It seems that we need to back to this question again. We need move votes here to make right decision Question: Should we create new organization ( //cc: @forki @dungpa @vasily-kirichenko @ovatsus @7sharp9 @dmitry-a-morozov @isaacabraham @pblasucci @pezipink @ReedCopsey @mathias-brandewinder P.S. We already have following groups:
and I think that FAKE, Paket, F# Formatting are mature projects that able to form new org outside of fsprojects. |
|
+1 - I'd be happy to move F# Formatting to |
|
An idea - how about a more general fsharp.contrib, basically a place where projects can "graduate" to from fsprojects? We can still have fstools and fslab for more focused organizations around a particular theme. Shouldn't there be a place where the more mature projects from fsprojects can go to without having to pick a theme - or that don't fit in any particular theme - or that eventually may graduate into FSharp.Core even. E.g. I would love to see more immutable collection implementations. |
|
Also I'm not completely sure if we need to keep the "F#" in the name.
|
|
I didn't even know there was a |
|
fsharp.charting seems to be in both fsharp and fslaborg. Fake is in fsharp as is FSharpMDXS, are they both tools, they both would be classed as "tooling" I guess. Categories are hard :-) |
|
No please don't change semantics of existing orgs. We already did this for
|
|
I always thought the semantics of the fsharp org part was core engineering endorsed things that were important to be maintained. I would of thought is fsformatting now working xpat it would be ideal in the fsharp org |
|
Yes, but this was applied after core engineering group was founded. FAKE is there for like 5 years or so. Now I think people are right to say it doesn't belong there. |
|
Also I wonder how do we make such decisions in the future. How can we decide if a project is mature enough for an endorsement. Personally I see two options: let @dsyme in dictatorship decide or let the fsharp foundation board decide. Both are equally good for me. |
|
Agree with a lot of what's been said (unnecessary F# focus for some projects, categories are hard,...) Feels like we're over thinking. Maybe we should just let each set of maintainers choose where they want to go/stay while mainly just cleaning up the existing groups. If a bunch of maintainers then feel like they should come together and create an organization, fine. If not, fine too. |
|
@kurtschelfthout I can sympathise with you wanting to move fscheck back, often organisation controlling can make you feel like a project has slipped through your fingers. I feel like that with some of the project that I helped to create that I am no longer even an admin on. |
|
It's not really about control...I would actually love for someone to be an admin on FsCheck so I can just contribute stuff ;) it just feels like this discussion is never going to end. |
|
This discussion definitely feels a bit unfocused. I'll let someone else do the constraint solving - here is what I'd like to do about F# Formatting:
|
|
For a while, I've been watching this from the side, but it's something I've wanted to take up. Apart from the visibility, there's no reason for OSS to be organised within any sort of affiliation group under a language umbrella. What C# OSS is out there has 'prospered' without any shared umbrella for many years:
In fact, for those projects, it would have been quite laughable if they had been organised under any sort of csharp organisation. This is emphasised with the abundance of choice there is: There's not only Castle Windsor, but also Autofaq, Ninject, etc. There's not only Moq, but also NSubstitute, FakeItEasy, Foq (written in F#!), etc. There's not only xUnit.net, but also NUnit, Fixie, etc. As Oren Eini quite astutely pointed out recently, it makes F# look immature that everything is gathered in the same organisation. Personally, I think it would strengthen the language with a diaspora of OSS. This would also open the floor for competition. Not that I'm particularly unhappy with the current selection of F# tooling, but as an example, there seems to me to be two up-and-coming web frameworks (or are they libraries?): Suave and Freya. Should they both go into the same organisation? Is there room for both of them? Or wouldn't it be better if they were allowed to evolve independently (as they currently do)? |
|
To be fair I've never particularly liked grouping things here, I'm quite happy for things to be just in GitHub somewhere. I think it makes sense for core important things like how Clojure incubate small intrinsic projects but there's no formal management of that here just a loose collection of "stuff". Maybe that's what the fsharp repo is anyway though. D.
|
|
As a follow up, as #100 indicates, I've gone ahead and created an fscheck organization. I intend to transfer the fscheck repository there in the next few days. I'm hopeful this is the right choice for fscheck (definitely more so than moving to my own profile - try remembering my last name as part of a url... :) ) as well as sorting things out in the fsharp organization. Please don't take this the wrong way - I'm not going anywhere - and none of this is due to what anyone in the F# community has done or said, and I am certainly grateful for the support. You folks have been awesome, and I hope you continue to be! |
|
Sounds like a good decision to me! I think FsCheck is a project that's mature enough to benefit from standalone organization. With a separate organization for FsCheck, it sounds like you should actually be able to host the docs at http://fscheck.github.io, which would be cool :-) |
|
This is a good move, both for FsCheck and github.com/fsharp, great work @kurtschelfthout!! @ploeh - I personally look at the C# open source situation very differently than this, and in particular I think that the comment in the blog post you mentioned missed the mark by a fair way. Indeed, so much so that I think C# should be learning from F# here, rather than the other way around :) This probably isn't the place to have this discussion in full, but I'll put some thoughts here in any case. First, C# and openness.... As much as a few C# OSS projects have prospered during the last 10 years (and well done to them!), during that time C# and .NET unfortunately accumulated an unfair reputation (especially amongst outsiders) of being a predominantly closed-source ecosystem. I think it's important for the thought leaders in the C# and .NET world to ask the question "How did this happen? How did we end up with this reputation? What can we do about it?". To some extent, the answer lies with Microsoft's old approaches, now gone. However, that's only part of the story. In my opinion, this reputation could have easily been very different if only there had been some kind of FSSF-like grassroots initiative for C# and .NET centered on openness and cross-platform which owned the message about C# and .NET openness - including on the Windows platform - and actively helped facilitate it. That is, the C# world (particularly MVPs and other key contributors) should have put forward a strong message that C# was welcoming to open source, no matter what Microsoft's old approach was. There was some great work in this regard by various individuals and things finally started to come together with nuget.org - and all power and respect to those who did these things - but until recently there has been no widespread grassroots C# or .NET community organization presenting a voice for C# or .NET and openness. If such an initiative had been in place, I think many good things would have happened and the whole reputation of C# and .NET as an open ecosystem and community would have been better. Now that C# is "open and cross-platform from the ground up" we're finally seeing things shift in this direction. If you start with this POV, and imagine what the C# open world could have looked like, including its reputation and self-empowered community dynamic, then it's pretty reasonable to imagine that parts of the C# open community would have done much as the F# community have recently done: those leading the way would, like F#, have found innovative ways to share news about open projects, incubate projects together and welcome new projects to the fold. Who knows what umbrella organizations would have formed to support those initiatives! But one thing I'm sure of: people would have pointed to those umbrella organizations as social proof that C# and .NET embraced openness. Isolated projects don't convince anyone - active social organizations that embrace openness do. There are hundreds of ways that might have played out in practice, but my point is that if C# had actually had a very widespread open ethos and spirit in the last 15 years, then the whole C# open project world would have looked different (and possibly a bit more like the F# or Python or Java worlds). The world of individual, isolated successful open projects (only brought together late in the day under nuget.org) is a symptom of an underlying problem - the lack of grassroots, representative organizations supporting open source - rather than a positive thing to aspire to. A mature community has organizational support for openness - with Python being a classic example, and Java to some extent, which has a large network of conferences, researchers and educators supporting its open existence. We're now starting to see things change with the collection of many C# open projects under the .NET Foundation. That's really an indicator that C# and .NET are moving in the direction of umbrella organizations with more of a grassroots feel. The F# world is very active and welcoming to openness, and efficient in its sharing and communication of open projects. The "mature" C# world, in contrast, unfortunately developed a largely undeserved reputation for being based at its core on closed source, proprietary software, and many newcomers did not historically find it welcoming to openness (again a largely undeserved reputation to be sure). These things tend to be a bit historical and don't change quickly. It's possible that the future of organized C# openness may start to look more like the F#, Python or Java worlds. Are C# and .NET immature because they only just got the .NET Foundation? Yes, in some ways - a deep embrace of openness is new to much of the C# and .NET community. However most of the C# and .NET world is now having the humility to recognize the problem and start the hard work to move C# and .NET forward. In any case, personally I think the F# world has got a good grip on open projects.
The rule I see being followed by the F# community is "let many flowers bloom, find ways to support their growth". For frameworks (WebSharper, Suave, MBrace, ...) and some tools (FsCheck) a new organization is often used. For core libraries (and some tools) people seem to find "fsprojects" or "fslaborg" useful, and some other libraries live under a company umbrella (Deedle). Anyway, in summary, I think the F# world of open projects is in relatively good shape and it is supporting the needs of F# users pretty well. There's lots of improvements to make, but reverting to a world where no umbrella organizations exist besides individuals and companies and occasional technologies would not be step forward for F#, nor is it where C# needs to be going forward. |
|
@dsyme Well written! @ploeh I just wanted to chime in re. the comments on Suave/Freya: We are having a discussion here SuaveIO/suave#153 if you're interested it would be great to have you partake in it. For me it's about compositionality of web frameworks; I want to move Suave towards more of that. If you just want it as a HTTP server, go for it and run Freya on top and use its Machine. Or use Suave mainly for WebSockets/SSE and distributed tracing/APIs and Freya on the side. Or help out to finish the OWIN branch for Suave, so you can run @leastprivilege's IdentityServer on top. =) Or use it as a foundation of other things; I'm currently writing a Suave-hosted service for JavaScript error reporting for @logary for example. A thousand flowers lead to innovation, but take time to pick. Especially for newbie flower-pickers. And time to properly secure, because effort is spread out. Having ongoing and well-considered changes/improvements done to existing projects, arising from the buzz of cross-pollination (pun intended), is probably the way to go here. |
|
@dsyme very nicely done! @ploeh, I concur with @haf on the web libraries. Our goal with Freya is to create a stack of libraries, building on OWIN, that allow you to do what you want. You could even run WebSharper on top of Freya.Core using WebSharper.Owin on top of Suave's web server (once OWIN support is complete). The endgame is to enable developers to use what they want, where they want. I'm also currently working with the ASP.NET team to see if we can share some of their tutorial content to make it easier to offer well-written, good examples of building web apps. |
Hi @kurtschelfthout
With the FSSF becoming legally established, it probably makes sense to have http://github.com/fsharp be very strictly only those repositories related to points 1 and 2 of the mission statement of the FSSF - e.g. fsharp/fsharp, fsharp/FSharp.Compiler.Service, the editor bindings and so on.
As a result, would it be ok to move this repository to http://github.com/fsprojects? There are some highly respected and successful projects in that collection now, so you'd be amongst good company :)
There's a related discussion here: fsharp/fsharp.github.io#19
Please let us know what you think.
Thanks
Don
The text was updated successfully, but these errors were encountered: