How to get added to swift-server organization on GitHub?

The SSWG members can correct me, but my general understanding of the purpose of each phase is:

Pitch

"Hey, I have this project (idea), here's an outline of the API, here's it's goals/non-goals, what does everyone think and what would be your use cases you'd like to be able to use it for?"

Proposal

"Ok, here's a working version of the code and here's proof it works as spelled out. Here's the explicit goals/non-goals after accounting for feedback from pitch phase."

Proposal Review from SSWG

"This is useful to the server-side ecosystem, and based on the project's quality metrics (CI, test coverage, contributors, etc.) we feel it's mature as a [sandbox | incubating | graduated] project in the SSWG Index"

It is hard to resist to comment on this :slight_smile:

Fortunately the SSWG wasn't just founded, but even the fancy current iteration is almost 4 years old now. There is some solid understanding on what it and its model of working accomplished.

It clearly turned some initial excitement about the Swift on Server idea, driven by the truly excellent SwiftNIO, into a runaway success, not.
Yes, - outside of Apple - a few hobbyists and some indy devs, are using it (myself included), but ick, it's not an option considered by any regular business, such don't really even know about it since IBM quit it.
Interest in Swift on Server has never been lower.

Personally I think a reason is that the goals of Apple itself are too disconnect to the goals of a larger, potential "Swift on Server" community (fair!).
Apple's interest is in extremely high perf / HA servers (iCloud etc) and SwiftNIO is very good for this particular thing (Rust setups likely are the more reasonable choice for anyone but Apple in that space).

But that is nothing most people do and expect from server frameworks in the first place. Apple has so little interest in that domain that Xcode doesn't get the required bits, but the SSWG rather pushes VSCode to workaround that. Async/await? Not supported in NIO.

I really don't want to be mean, but honestly, the only thing the SSWG did in years is deal with themselves. It just exists to exist. Apple people do what Apple people want to do (or not).
I highly doubt you'll find someone saying that he chose package XYZ because it was recommended by the SSWG, let alone use SoS (:slight_smile:) in the first place.

Not sure how to make it better (if I'm honest I think the case is pretty much lost), but maybe opening up a little more would be a rather wise choice.

4 Likes

I keep seeing this thrown around, but I just don't see it that way.

Since the beginning Vapor has had at least 50% representation on the committee, and today Vapor and Apple each only have ~30%. That ignores what MongoDB is trying to push for, and everything Amazon has been working on this year.

From what I've seen in the "slowdown" in momentum compared to say 2-3 years ago is Swift's concurrency support is highly disruptive (in a good way) in this space and some pieces are still waiting (custom executors for actors) before we'll likely see another explosion in momentum of development

3 Likes

On a side note, I find several of those projects you mention interesting and hope they’ll be released and would evaluate, possibly use and potentially contribute to a few…

2 Likes

I mean that's something Apple people literally said in a Slack a while ago.

If you are cool with that, that is perfectly fine. It's not much different w/ Swift in general IMO. I'm also quite happy with Apple developing NIO and giving that away, it is a great piece of software doing a lot of the unpleasant hard work. Thumbs up for that.

I don't have scientific measurements by American scientists, but I think there is no "slowdown" of momentum, but a collapse, and that started at least 2 years ago, probably earlier.
Async/await could have been something reigniting interest (though yet another API rewrite). We'll see what 22 brings. :woman_shrugging:

3 Likes

Perhaps this kind of defeatist attitude doesn't help?

I occasionally take a look at the r/swift subreddit, and it's not uncommon that I see people asking about Swift for servers or Linux development.

Here's one from 1 day ago, asking how to deploy a Vapor project. Lots of responses from people apparently doing the same. Here's another one from 19 hours ago, looking for help developing a backend service in Swift. Here's yet another from a couple of weeks ago, asking about Vapor and React integration.

Unfortunately, another thing that I see fairly often is people actively discouraging other developers from even trying Swift, basically calling them idiots for even attempting to use it on a non-Apple platform.

There are lots of very talented developers putting in a huge amount of effort not just to fix bugs, but also make improvements (like language-integrated concurrency, or a first-class VSCode extension), and make Swift a great language for any kind of task. But some parts of the community are just toxic, full of people who lack vision and try to put down the people building things.

6 Likes

Why do you think I'm defeatist? I'm just looking at the situation after about 6? years.
It's not like I don't do any SoS, from Noze.io over Macro.swift, ZeeQL, or SwiftBlocksUI. Or infrastructure stuff Apple should be doing, like swift lambda or SPMDestinations.

It is cool that people are still occasionally interested, but common! :slight_smile:

I think "Taylor" hit a point here. The popular infrastructure pieces never(?) got produced by "working groups". It was small devs and if they hit a point the users liked, they grew. Maybe Apple should find a way to push such (though as mentioned, interest seems to be low, as shown by Xcode support).

3 Likes

thank you! you have no idea how much even a little encouragement means to us library devs… (sometimes it feels like i am coding into an abyss)

like you, i’ve been using swift since 2016. for me, the single biggest thing the SSWG accomplished was it created a reason for swift on linux to be taken seriously, whereas before it was mainly just a secondary platform swift “sort of supports”.

prior to the SSWG, it was very hard to say things like “removing the Foundation dependency is a goal” or even things like “SIMD should be in the standard library” and be taken seriously, because everyone thought swift on linux was a toy. for this, i give the SSWG a lot of credit, swift on linux would probably have died without them.

can’t speak for others, but editors are considered “server-side swift-related” exactly because XCode is macOS-only. i use Atom and i have atomic-blonde for that, i’m not surprised the committee manages the VSCode plugin. VSCode has got to be one of the most common non-Apple text editors out there.

i wouldn’t say there is a slowdown as much as there is a lack of progress in areas that clearly weren’t blocked by the transition to async/await. for example, the past year could have been a great opportunity to really tackle constructive string parsing, JSON libraries, URL libraries, resource management systems, etc.

2 Likes

There is a pitch process. If your argument is that it is too onerous, that argument would be more convincing if you had examples of pitches that were rejected, rather than library authors who didn't even try.

1 Like

Take that the other way around, how many pitches have there been? And from the few, how many originated at Apple?

1 Like

is it possible that these are three disjoint groups of people, who do not deserve to be blamed for the actions or reactions of the others? i develop swift on linux. why would i discourage people from attempting to use it on a non-Apple platform? it makes the pie smaller for all of us. and i would think most library devs see ourselves as “people building things”

2 Likes

I don't want this to be perceived as nitpicking, but I think there's a difference between "onerous" and "stringent". Pitches being rejected would prove the latter, while library authors not pitching their library would prove the former.

I also want to make a distinction between defeatism and the process of identifying areas of the ecosystem that didn't grow much in the recent years. People can raise concerns when trying to improve things, not to complain for the sake of complaining.

2 Likes

If that's the case, then I think the obvious next question would be: which parts of process do you think should be removed?

Personally, I don't think the requirements for the "incubating" level at least are too onerous - documentation, tests, some evidence of active maintenance. That's a pretty low baseline, if you ask me, and they are all things which meaningfully add value. Then you write a pitch.

2 Likes

to me at least, the word “incubating” suggests that this should be the stage during which a project gains things like a CI pipeline, API reference, issue tracker, etc. if a project comes in with all those things already, it’s hatched…

1 Like

Do you have something specific in mind here (full of people sounds like a lot)?
Is this thread in the toxic category already from your point of view?

Well that's where we differ: for something like a JSON parser, just as an individual, I'd want to see comprehensive tests and benchmarks at the very least (bonus points for fuzzing). It's a complex format with a lot of edge-cases. I would expect the SSWG to have at least those kind of standards before recommending a package.

I could go dig for some links, but I don't think that would be productive. And no, I don't think this thread is toxic. I've interacted with the people here long enough to know they post considered questions and opinions and do try to make things better. Generally these forums attract higher quality posters than places such as Reddit or Twitter.

4 Likes

i think there’s a misunderstanding here. i don’t think that recommendation should be the first thing that happens to a package once it goes public. rather, i want to see some kind of support or guidance for the package in the time between when it was spun-off from a private project, and when it’s finally grown all the things you’ve mentioned.

it doesn’t make sense to recommend a project while it’s still “sandbox” or “incubating”, and even less sense for recommendation to be the prerequisite to being considered either of those things.

i honestly think the committee would be better off renaming “incubating” to "graduated”, and “graduated” to something like “certified”. the question then becomes, where do we keep track of all these incubating projects, if not under the swift-server umbrella? how do we help them move forward?

right, a lot of us recognize each other from the mailing list days, even :)

2 Likes

since this discussion has been getting pretty abstract, i went ahead and made a pitch for json over in the pitches section!

7 Likes

I wonder whether we should just take a step back and reconsider the whole "server" in SSWG.

My personal take on that is that I fell in love with Swift and after writing 20 years of Python and Vala next to 12 years of Objective-C, I finally have a programming language that can target both my user interface apps and all the tools (not necessarily server-related) on Linux and macOS. Finally one language for both the shiny things and the boring things (exaggerating, of course).

For me, Swift has enormous potential to offer for the people who write Python, Ruby, Rust, and Go these days. And despite all the hassle to get a comfortable development environment working on non-Apple platforms, once you have something, it just rocks.

So: How can we make Swift more attractive to those people? Isn't that the more important question than "server" or not?

wouldn’t that just be a Swift Working Group?

3 Likes