Modules needing maintainers

[rossabaker]

The following modules are currently unmaintained. If you would like to help revive them, please follow the volunteer link!

Module	Since	Volunteer
http4s-async-http-client	2022-06-09	volunteer
http4s-dropwizard-metrics	2023-01-04	volunteer
http4s-okhttp-client	2023-01-04	volunteer
http4s-play-json	2023-01-06	volunteer

If you have a security issue with any of these, please contact the http4s security team.

[rossabaker]

There are discussions on at least three forums. I'll put some opinions on each to help the aspiring maintainer choose. These opinions are as of January 2023. Some of this is blunt, but hopefully it gives people an idea what they'd be getting into.

async-http-client

• Highly popular alternative before blaze-client was stabilized and ember-client existed
• I always found it to be the least stable, but seemed to be an outlier. I could trivially crumple it under load.
• Upstream was abandoned for a year or so, but got a new maintainer in November 2022
• Extant bugs, and I fear many of them are in the upstream Java Reactive Streams integration that wasn't as well maintained as teh rest of the project
• Lots of compelling alternative backends in http4s these days

boopickle

Update: got a maintainer

• I am only aware of this ever having one user
• No upstream commits since Summer 2021
• There's no competing module, unlike the backends
• Thin integration. Maintaining this would be an exercise in Git.

dropwizard-metrics

• I soured on upstream when my working PR was closed by Stalebot without comment
• Thin integration. Maintaining this would be an exercise in Git.
• Upstream is multi-module. There's a lot to think about with respect to versioning on PRs that are otherwise green.
• http4s-prometheus-metrics is the present, and I hope otel4s is the future

okhttp-client

• extant bugs in integration
• thread model is an awkward fit for cats-effect
• upstream is written in Kotlin. It works, but thins the pool that can read it.
• claimed non-breaking changes to its Okio library definitely break our CI
• there are many compelling alternatives in http4s ecosystem
• apparently Scala Steward uses it, but I'd be more interested in fixing that instead of fixing this fixed by @TonioGela

play-json

• Upstream team is friendly and responsive.
• It's theoretically a nice bridge for people moving from non-functional Scala.
• Unlike Twirl, it's been a long time since I heard of anyone crossing that bridge via this.
• Circe is an established incumbent in our corner of Scala, and Fabric is a newcomer that's also a Typelevel project.

tomcat

Update: got a maintainer

• depends on an intermediate repo (http4s-servlet) between this and core
• highly unsexy servlet technology (editorial: which has had magnitudinally more eyes on it than any of our other upstreams, save Netty. I don't know why people sleep on this.)
• sits somewhere in the middle on technical complexity
• there is Servlet 3, 4, 5, and 6 to contend with. It's a dizzying Git exercise, but a maintainer could draw the line and say "We only support ___."
• servlet aficionados can use the http4s-jetty integration instead

[rossabaker]

Updates:

• @cquiroz is making a Boopickle comeback
• @dhinojosa is going to help out on Tomcat (and Servlet)

[armanbilge]

More updates: thanks to @TonioGela in scala-steward-org/scala-steward#2888 okhttp-client is no longer a dependency of Scala Steward

[rossabaker]

I've decided to put http4s-play-json up for new ownership as well.

[armanbilge]

Quoting Ross from http4s/http4s-boopickle#1 (comment) because I completely concur

My interest is more in developing new maintainers for organizational health than in these modules themselves. If these modules interest you, then it's a good fit for everyone.

Alternate idea: if you're interested in maintenance more than specific libraries, there are Typelevel ones that are relevant, similarly easy, and would help me to have help: jawn and jawn-fs2 come to mind.

I similarly have a growing list of libraries I could use help with. Just ask! :)