SSWG Package Maturity Review 2021

Server Workgroup Updates
1

Hello everyone,
the SSWG team came together to review and update the maturity levels of SSWG endorsed projects recently and we'd like to share the results with you.

The projects currently endorsed by the server work group can be found here: Swift.org - Swift Server Work Group (SSWG) and we'll be updating their status (according to the changes outlined in this post) shortly.

Keep in mind that the SSWG endorsement's purpose is not to pick the "best" library, but only ensure that long-term health and quality of these projects is kept to a high standard.

You can learn more about what each status in the Incubation Process means over here: sswg/incubation.md at master · swift-server/sswg · GitHub

This year we also introduced a "conditional level-up" given that the review is a periodic (currently every 6 months) process, and we had a few packages which were just on the edge of moving up a level and we'd rather collaborate with their maintainers to polish them up rather than have them miss a cycle.

Projects not mentioned in the list below, remain in their current status. We discussed all projects in depth, however to keep this list short and focused, we only mention projects which changed their status, or deserve more discussion on why they remain in the current status (e.g. why they didn't graduate yet).

  • SwiftMetrics
    • has gained good adoption throughout the ecosystem, both in libraries, frameworks and end-users directly adopting the API successfully.
    • not well documented release methodology preventing graduation
    • good amount of production use both in open source and commercial projects
    • Recommendation:
      • conditional on documenting the release methodology: promote from Incubating to Graduated
  • PostgresNIO
    • has gained a good amount of usage
    • has major major internal work & potential API changes upcoming
    • Recommendation:
      • stay in Incubating
  • RediStack
    • has gained adoption and is a great project overall
    • single maintainer requirement is preventing it from graduating to Incubating
    • Recommendation:
      • stay in Sandbox
  • SwiftAPNS
    • lacking secondary maintainer, Kyle the primary maintainer would love to find a collaborator so we could move the project to the next maturity phase though -- if you're interested, please reach out!
    • Recommendation:
      • stay in Incubating
  • SwiftStatsdClient
  • SwiftPrometheus
    • adopted by various real projects and very responsive maintainer
    • @ktoso fills role of secondary maintainer, in addition to the primary author @MrLotU
    • Recommendation:
      • conditional on stable release (pending) and 2nd maintainer (done), promote to Incubating
  • gRPC Swift
    • project is widely used in various organizations and has a dedicated team supporting it
    • Recommendation:
      • promote to Graduated
  • Swift Crypto
    • guarantees around API of Swift Crypto and its evolution are somewhat tied to Apple platforms, so defining it purely in terms of SSWG maturity is a bit tricky.
    • Recommendation:
      • stay in Incubating
  • OpenAPIKit
    • Smoke framework integrating into their code generation tooling supporting production use cases
    • Not quite wide enough adoption to promote to next level just yet
    • Recommendation:
      • stay in Sandbox
  • MongoSwift
    • confirmed a few significant production use-cases
    • has dedicated and responsive team supporting the project
    • Recommendation:
      • promote from Sandbox to Incubating
  • Swift AWS Lambda Runtime
    • confirmed significant production use-cases via vapor and other communities
    • significant API changes coming after Swift 5.5 lands, so team recommends keeping in Sandbox until the API stabilizes.
    • Recommendation:
      • Stay in Sandbox until 1.0 with stable API is released, then may promote to Incubating
  • Backtrace
    • real solution to this would be done on the language level, no need to promote this package further than its current level.
    • should be used through Lifecycle most of the time rather than directly -- such documentation was added to the README: https://github.com/swift-server/swift-backtrace/pull/50
    • Recommendation:
      • stays in Incubating
  • Service Lifecycle
    • expected API changes for async await, however possible in additive non-breaking ways
    • Conditional Recommendation:
      • needs better documentation around usage and integrating with other frameworks
      • tag 1.0 and commit to stable API
      • conditional on the two points above, promote to Incubating
  • Soto for AWS
    • confirmed use-cases in various communities
    • project is well supported and maintained
    • fairly stable API, though will change/gain async/await support following SSWG guidance
    • Recommendation:
      • promote from Sandbox to Incubating

The remaining projects, e.g. AsyncHTTPClient (Graduated), SwiftNIO (Graduated) and similar ones receive no changes to their status. You can check the full list of projects here: Swift.org - Swift Server Work Group (SSWG)

We would also like to use this opportunity to mention that RediStack and SwiftAPNS specifically are very much interested in getting new contributors and maintainers -- if these domains are of interest to you please reach out here or in the appropriate repositories!

It would help those projects reach the next maturity level if we could confirm there are more active maintainers on them :heart:

We will continue to revise and think about the maturity levels and requirements as well, so make sure they suit the needs of the ecosystem.

We're excited to see all those projects mature and grow communities around them, and we're already looking forward to the next maturity update cycle!

SSWG Team

11 Likes
2

Thank you to the entire SSWG for continuing to review the ecosystem's (that have gone through SSWG processes :sweat_smile:) project maturity for all of us to benefit.

As the maintainer of RediStack, I obviously have some questions for the SSWG that I would like some guidance on.

  1. What is the definition of a maintainer in the eyes of the SSWG?

I have made sure that at least 2 active members of the SSWG from different organizations always have admin access to both the GitLab and GitHub mirror repositories since the beginning.

Some of those members have also contributed to the project, with at least one being a major contribution: the connection pool feature.

Does someone have to be the one who cuts releases, do code review, provide a certain number of contributions or a regular amount of them in order to be classified as a maintainer?

  1. Why is there this hard requirement to have more than one maintainer to go from Sandbox to Incubating?

It's entirely reasonable to have this requirement to reach graduated, but we're now at odds of definitions of requirements to also track number & frequency of contributions to move to Incubating.

This makes it confusing for RediStack, given that the project is clearly not a "sandbox" project as it has stable 1.0 release, adheres to SemVer as best as possible, and is known to be used in production apps.

My concern is that the Incubation stage labels are viewed without context as to why they are applied to projects when someone views the SSWG package index on the main Swift site (or in the future hosted sites like the Swift Package Index)

Having the label of Sandbox while being 1.0, with regular contributions, gives the impression that the project is immature for use rather than immature for long-term stability of project management.

  1. How hard is this requirement going to be applied to low-level projects that are easy to identify as being be "done"?

From Kyle himself, he has stated that SwiftAPNS is relatively feature-complete and requires little maintenance. Barring changes to the language, dependencies, or the APNS protocol... there's not much more for the project to do.

How does that stage of a project's lifecycle factor into the requirements for regular contributions, number of contributions, etc.?

  1. There is now inconsistency in applying the guidelines between the packages without clear guidance on why it was appropriate for this inconsistency.

SwiftAPNS is now in the same state as RediStack regarding maintainer count, but maintains its status as Incubating, rather than dropping back down to Sandbox - even though this is possible within the SSWG incubation process.

2 Likes
3

Thanks a lot for the questions Nathan!

We're going to think through the process and discuss it in depth in 2 weeks. Maybe there's some process simplifications we can take out of this. We'll get back to this once we discussed as a group :+1:

On a personal level I can reply a bit right a way, though these opinions are non-binding (not the sswg's official stance).

You're right we need to define this better, thanks for calling it out.

So that's just my personal opinion but these levels are less about "how much churn / done the project is" but more about "when a new swift comes out, will someone update it" and "if a security or general issue comes up, will someone respond to it quickly". So it's really mostly about the responsiveness to ongoing moving swift development world rather than feature completeness.

A feature complete project that'd e.g. fail to compile once Swift 6 drops, and its author "falls under a bus" and had no other maintainer (write access and will to maintain) is able to make a new release un-blocking the rest of the ecosystem depending on this package would be an issue. This is less about how complete it is, but about that there's someone responsive and responsible for it.

That's the primary reason we're concerned with the single maintainer projects; even though you're very right that low level projects may be hard to get many maintainers, especially if it is "done" then how would one prove that some person is "maintaining" if there isn't anything to do in the repo on a day to day basis :thinking:

We'll have to figure out this part of the process and probably adjust some rules?

Yeah I can totally see that and share your concern. It's not necessarily sending the right message to have a pretty mature project such as yours but still be in sandbox - people may misinterpret the meaning of that by just skimming the list hm.

Good point and I think we somehow missed this? Another reason to look into the rules again.

We'll definitely discuss these in the sswg group and get back to this with an official response, thanks again for your questions and great work on RediStack -- let's figure out how we can make sure the project has less risk and the rules make sense to highlight such mature projects :+1:

4 Likes
4

Minor follow up, the status of the projects on Swift.org - Swift Server Workgroup (SSWG) has been updated.

3 Likes
5

Okey, sorry to leave you hanging like this @Mordil for a while -- back to it though!

We discussed the role and meaning of "maintainer" in the group recently, Tim made an update PR to the repo here: Clarify the role of maintainers and committers by 0xTim · Pull Request #61 · swift-server/sswg · GitHub

  • Must have 2+ maintainers and/or committers. In this context, a committer is an individual who was given write access to the codebase and actively writes code to add new features and fix any bugs and security issues. A maintainer is an individual who has write access to the codebase and actively reviews and manages contributions from the rest of the project's community. In all cases, code should be reviewed by at least one other individual before being released.

I'll try to add some more notes / discussion from what the group converged around:

We believe that the goal of the SSWG recommendations and incubation process is to guarantee the long-levity of packages. Setting some baseline for quality is also part of this, but the primary purpose is really for adopters to know "I can adopt this, it won't become 'dead' next month" when we'd need to upgrade e.g. swift or library version, or react to some security issues etc.

In that sense... the maintainer requirement is there to lessen the "bus factor". Even if the primary developer were to disappear, there is a higher chance of the project ongoing if there was another maintainer. It doesn't really solve the issue perfectly, the second developer could also disappear... but at least we're trying to help. So, what it seems we need to do with such projects, is to help you get additional maintainers, even if the project is low traffic, having someone step up an take some ownership in the sense "i'll be around to address some issues if they come up" would be a goal to have here...

So, what can we do to help RediStack cross that gap?

  • We can try some explicit calls to action, on the forums, twitter and else where?
  • We can try to make some issues marked as "nice first time contrib"?
  • Maybe we can include server side projects in mentorship official programs?
  • What else can we do?

I hope I summarized the thoughts of the group well; please feel free to chime in and let's keep this an open discussion.

cc @server-workgroup

3 Likes
6

Thanks to you and the SSWG for adding the clarification.

  • I guess I'm just stuck not seeing how having SSWG members (or prior ones) have as much access as possible to both the GitLab and GitHub repos is any different from having "active maintainers" to increase project longevity by reducing the bus factor for a library that is relatively bug free and stable for the ecosystem's needs
    • If I was to disappear, and a critical fix needed to be made, there are members who could do that entirely without me being a part of the process
    • I'm unable to link publicly to the list of collaborators in GitHub like I can in GitLab, but most of everyone w/ access to GitLab have access to GitHub
  • I've kept a list of Good First Issue labeled issues for anyone to tackle, that range from documentation, to implementation complexity of single methods, to more complex things such as adding Redis command convenience methods
  • I think it's a good idea to include any SSWG incubation projects as part of the mentorship official programs, if at the very least to give more variety to those who participate (or want to)
    • This obviously would require some partnership with the mentorship working group (SMWG? :laughing:)
5 Likes