[CRITICAL] Share package administration for long term Pothos stability

[Aarbel]

Thanks @hayes for this amazing library ! Today the reason we are not implementing it is because your are the only administrator of this library.

Problem: if you stop administration for any reason, we are all stuck. Do you plan to share / delegate part of this package administration / maintance ?

Thanks a lot for your help !

[hayes]

There has been a lack of interest in external contributions. I'm not going to hand off maintenance to a random person who hasn't been actively involved in contributing, so until there is more substantial external contribution, there won't be additional maintainers.

Unfortunately this isn't something that's easy to fix. My perception is that many libraries will stop being maintained when their lead maintainer leaves the project. Projects built/maintained by companies with many contributors are even more prone to this.

Pothos is MIT licensed, and can easily be forked if it ends up abandoned. I have no plans to stop maintaining it, and would be happy to accept more outside contribution, but it's not something that can be created artificially.

Pothos is also very stable at this point, and doesn't require much active maintenance to keep it working. There are always more plugins to build, but the core library has been working very well for a long time with very few new features needed.

[hayes]

Pothos also does not have any runtime dependencies, so urgent releases to pick up security fixes from dependencies are not needed.

I am open to suggestions on how to improve the current situation, but realistically if you are not comfortable using a library with a single maintainer Pothos probably won't be a viable option in the short term. Unfortunately this is also true about most of the alternatives (most of which have less active maintenance/development).

Using a schema-first option with graphql-code-generator is the only option I know of with multiple funded maintainers (through the guild)

[Aarbel]

Thanks a lot hayes ! Maybe you can add a maintance mention inside your readme (open for more maintainers)

That will bring more confidence for people to implement it ;)

[Hebilicious]

Just adding my 2 cents here :

• Pothos is extremely well built and is by a significant margin the best way to build graphql servers in Typescript. It is criminally under-rated and under-used.
• A significant amount of extremely popular library are maintained by one person. This is an unfortunate reality of FOSS.

When choosing a libray, I'd consider other things besides the number of active maintainers :

• Number of Runtime dependencies (Pothos has none)
• Extensibility (Plugin system)
• Documentation (Great docs)
• Examples (Dozens of examples)
• Tests (Everything is well tested including plugins)
• Stability (Easy upgrade path between major versions)

@Aarbel if you end up not choosing Pothos, I would be very curious to know what you endup choosing.