New maintainer(s) for sqlboiler?

[parnic]

I see that the project has been put into "maintenance" mode, but there are still a lot of projects that rely on sqlboiler (as evidenced by the nearly 7k stars on the project as of this writing) and others who are willing to provide new features for the community to use. For many projects, it is a significant amount of work to excise sqlboiler from their project and replace it with something else.

I am glad that @stephenafamo graciously stepped in a few years ago and chose to continue maintaining the project after @aarondl was unable to any longer. However, it appears that @stephenafamo has also moved onto other projects, in some ways competing with sqlboiler. That's great! I'm all for more choice in the ecosystem. We do still get occasional updates to sqlboiler, but not as much attention as it needs.

It is also clear that sqlboiler is in need of someone to keep it going. Issues like #1433 and #1441 should ideally not be allowed to live as long as they have for something that is this widely used.

To that end: I would propose that sqlboiler offer to add or transfer maintenance to other user(s) to keep the project going. I would be willing to assume that role, and hopefully others would as well.

Is that something the project is open to and willing to discuss?

[aarondl]

Hello @parnic!

First regarding the issues you cited:
#1441 is a unused transitive dependency that's used for sqlboiler's binary, and has no bearing on the runtime afaict. This means it's completely benign and doesn't deserve urgency. End-users of the library can force the upgrade themselves so long as there exists a semver backwards-compatible version. A nice to have.
However, #1433 seems to have deserved more urgent attention.

So that said, the project is definitely opened to having any and all conversations!

When @stephenafamo answered my call for maintainers on the project years ago, we had a great discussion that assured me that our goals were aligned before I handed the keys to him. I'd invite you to have a similar one if you're interested in being a maintainer. These days supply chain attacks are at large and I am not interested in inviting several people, but would consider one additional person. You can contact me on our Slack (if you've been previously invited) or email (if you prefer it or want a slack invite): github.scallop842@passinbox.com

When Go's generics came out, the both of us were dreaming of potentially doing something different with sqlboiler, and through his experimentation of what could be possible we found that his prototypes would just never fit into what sqlboiler is. There have also been many lessons learned from developing sqlboiler that remain unused for reasons of backwards compatibility etc, so it made sense at the time to create bob.

As the development of bob continued, our heroic maintainer's time did dwindle, also of course his passion for the older less shiny project - as is natural. Life events have stolen some time from him as well, and so we see the compounding effects of all of that in the delays or unhandled issues.

We decided to put sqlboiler into maintenance mode because there are great alternatives out there and this software at this time should be "done". It's achieved its goal even way back when I stepped away, and what was left was a hundred thousand edge cases for various people's use cases and various database engines and dialects, and some bugs.

These are some of our ideas, I'll be curious to hear what your ideas around sqlboiler are!

[parnic]

I don't have specific ideas around what to turn sqlboiler into or ways to evolve it. My main concern is that a lot of projects, mine included, depend on sqlboiler, and I'd love to see more reactivity to PRs being posted for new features and bug fixes. That's mostly what I am thinking about when talking about a maintainer - timely response to issues and new releases pushed.

This project works really well for me and my use case, and I'd hate to see it fade away. 🙂

[aarondl]

Yes, that makes sense. Though there is a mote of disagreement in there already, as I'd like to see the feature faucet turned off and sqlboiler just continue to get more stable over time as it gradually removes bugs.

I'm glad you like the package. I think sqlboiler can remain something people use and love even if it's not actively getting new features, so long as we're reasonably on top of solving the bugs.

[parnic]

How do you feel about ergonomics improvements that aren't quite bug fixes but not quite new features either? 🙂 e.g. #1439

[aarondl]

Those types of changes are fine, though I would try to find a way to name that function in a way that doesn't require the feature flag, rather than add one.