This has been on my mind for awhile, and now as we start reaching acceptance of some critical packages such as NIOPostgres and NIORedis I think it's important to cover this topic.
Should "critical" packages be owned by the SSWG in terms of packages being under the swift-server GitHub organization, with the authors maintained as contributors?
I'd personally define "critical" so far as database drivers & the HTTP client
Where I'm coming from, is that it solves two pieces:
We are without a strong / reliable package registry for SPM projects
SSWG should have access / authorization to graduated repositories in case of emergency
This also stems from the fact that personal repositories in GitHub do not have robust permission schemes, while organizations do (from Teams).
Does this make sense at all? If not, and we want to leave packages primarily up the implementors to decide, I plan to migrate from GitHub to GitLab for NIORedis before the proposal review - as it's my preferred git platform.
I think this is one of those things that seem good on the surface but have an (not necessarily good) impact in areas one might not have thought about initially. I'm saying that based on experience from Scala ecosystem which has had a mix of "thousand libs to do the same thing" as well as "standardisation efforts" (at least a few ).
With that said: I would recommend avoiding such "strong centralization" – at least currently.
Standarization has an effect of "let's wait for the official one to happen" rather than many people trying out ideas and as a whole growing the ecosystem, and IMHO we are not at a point in time where we have the problem of "too many ways of doing a thing", rather, we should enable and empower people to try out and experiment with server-side Swift
Some examples from my prior experience with such efforts:
lack of "package registry" is true, but we can definitely life without it for now and use Swift.org - Swift on Server as source of truth
note that we only "recommend and promise to (at least somewhat) maintain" those projects, it does not mean that "this shall be the only one lib to do X"
not forcing libraries to move into a specific org can be empowering to library authors and "get their name out there", which is great and also helps to keep the motivation up for working on a project (vs. "I made it but now it's part of this org and people don't know my name...") which can matter to help people get the recognition they deserve
we can definitely offer moving repos under the swift-server org if library authors would wish for it to happen, though enforcing it I think would have negative effects
I could name examples of organizations which maintain repos in various places, such as lightbend or typelevel, and in general I have not seen it pop up as a problem that some repos are under one org and some under a person's, who's recognizable thanks to their efforts on their libs for many years.
if there is a "the org" to check the "official" projects, it inherently:
a) disincentives users from "looking elsewhere", which is not so good, since we not only want to lay out a strong foundation (with the SSWG) projects, but overall I think growing the server-side swift communities should be a goal of ours
b) it also disincentives developers from kicking off their "similar but not the same" libraries, since they may feel "if it's not the official one, it does not make sense to make one", and
c) limits us in case we'd have for some organizational reason have a repo not inside the org (things happen™)
swift-pm "by nature" is distributed, so embracing curated lists over "one repo location" seems like natural fit for Swift (some day maybe a registry would materialize for searching things...)
I think my preference would be to continue as we have so far, with the swift-server org available to those who want to use it, but it's not required.
Off-topic, but I'm interested why this is? GitHub is the gorilla and moving elsewhere may well reduce your chances of attracting contributors, which is one of the SSWG criteria.
@ktoso Thanks for your thoughts - they're the exact thing I was hoping to see when I posted this thread.
You definitely mentioned things that I hadn't considered (simply due to blind spots I have) and I have some thinking to do this week
I've used GitHub and GitLab pretty aggressively, and it's mostly down to a lot of "minor" features that on the sum makes the workflow and experience much better for me. It's definitely subjective aside from the CI feature set and how tightly integrated it is with the entire project.
I am fully aware of the clout of GitHub - especially for open source - and a slight part of my desire is to potentially expose people to the world of GitLab
GitLab does support repo mirroring, so perhaps I will check out the possibilities of doing that rather than full-stop migrating.
It seems to me (as a casual observer, having read the related threads about module names and such) that there are contradictory goals here. From the document linked in the original post, about the goals of the SSWG:
It seems to me that not all packages that might be of interest to developers of server applications belong under the SSWG umbrella. There are hurdles to pass to try and ensure quality, integration with other SSWG packages like NIO & logging, and distinguish experimental libraries from stable, production-ready ones that are being actively maintained. It is by definition something of an exclusive list that prioritises quality over quantity.
Even if library authors need to develop their packages elsewhere, I still think it would be worth having an official, SSWG-controlled mirror at least.
It's important to give credit where its due, but I'm not sure it necessarily needs to be in the form of the repository's URL and ownership. Would some kind of prominent attribution in the README be sufficient?
It's also quite common to see projects which are maintained by somebody other than the original project author. In such cases URL-based attribution gets the wrong person's name out. For open-source projects where longevity is key, a stable, neutral URL is best for everybody IMO. Even if it is only a mirror of some other, author-controlled repository.
Glad that it seems most people chiming in are aligned on the general outline I wrote up there
Right, definitely it is a quite focused and quality>quantity group of projects. With the location of things though, it is not quite binary good or bad, since people are involved, and we're/they're fuzzy beings – so it is as much (if not more) about managing expectations and impressions.
I pointed out a few downsides of forcing the single location, and not even mentioning that it is not status quo anyway already – e.g. with NIO living under apple/... and perhaps other projects which may also live under such namespaces). One tends to put everything into the same bucket if one wants to claim that it is "my bucket" (e.g. if you're a software vendor, and want to show "buy my bucket of libs" etc), though we don't really want to play that game -- we want there to be many successful buckets, and some of the projects in them, we want to give special attention.
Side note about "evil lib author," which could technically happen; In reality it does not change much where a lib lives, owners/admins can be added/removed anywhere etc.
The same just-works™ when depending on such repo via github url. I do not know if such renames work on GitLab, though another migration of major projects was between orgs without removing old one, just archiving old, and also worked out okey (esp. if tied timing wise with "next major version" etc).
).