Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call for help #71

Closed
lukechilds opened this issue Jan 5, 2019 · 16 comments
Closed

Call for help #71

lukechilds opened this issue Jan 5, 2019 · 16 comments

Comments

@lukechilds
Copy link
Contributor

lukechilds commented Jan 5, 2019

(this goes for both Keyv and cacheable-request as they're both heavily related)

Keyv got way more popular than I imagined it would. 3 million downloads a month on npm and according to GitHub insights, over 60k repos depend on Keyv 😬.

It was literally just built as part of a cache PR for Got, but my plans for it grew and now it seems like lots of people are using it for lots of different things.

Unfortunately this means with this amount of users, the issues/PRs come in at a rate quicker than I can deal with them.

I’ve also had an extremely busy year with paid work (which unfortunately takes priority over OSS so I can afford to live). On top of that, I’ve had a few personal/relationship/financial/mental health issues that I’ve been dealing with this year too. As a consequence, OSS has been pushed on the back burner a bit. I haven’t invested anywhere near the amount of time I’d of liked to into OSS (especially Keyv) this year.

I keep telling myself I wrote this for free and I don’t owe anyone anything, but people have written products they depend on to earn a living based on this code so I do feel obligated to try and keep this project well maintained, which I feel I’m failing at.

There have also been contributors who have been very understanding of my lack of response (which I really appreciate) and some of these open PRs are 99% good to to be merged and just need a tiny bit of feedback which I just haven’t found the time to do. So I feel pretty bad about that. Sorry guys, you know who you are.

Anyway, the purpose of this issue was a call for help to see if anyone is interested in helping me maintain Keyv. I’ve seen a few new faces recently that have made some pretty high-quality contributions.

Just to mention some: @sindresorhus @szmarczak @roccomuso @e0ipso @UltCombo @FabricioMatteMassive @dandv @kornelski

Thanks a lot for your help, it's been greatly appreciated. If any of you (or anyone else reading this) is interested in becoming a maintainer of Keyv, let me know and I'll send you an invite.

Just to clarify I'm not abandoning Keyv/cacheable-request or any of my other OSS projects. I'm just struggling to keep up with the maintenance overhead alongside IRL stuff and these are the two most demanding.

I've still got a todo list of about a gazillion things I want to improve with Keyv, and fully intend to do them. I just have bigger priorities I need to fit it around right now.

So yeah, thanks for all the contributions you guys have made so far. If you're interested in becoming a maintainer, hit me up. If not, time is precious, I totally understand.

Cheers,
Luke ✌️

@roccomuso
Copy link

roccomuso commented Jan 5, 2019

I'd be glad to help and review issue/PR 👍

@lukechilds
Copy link
Contributor Author

@roccomuso Invited you as a contributor.

I'm sure you already know this but the main advantage of Keyv is that its extensive test suite ensures predictable behaviour between all storage adapters. If we make a change to the core module and only test it against one adapter it could break others. We need to be very careful about changing anything and test thoroughly.

Also, any extra feature requests should be built on top of Keyv (as separate modules) instead of inside Keyv to keep the core module simple and easily testable. Although we really need #36 merged before more powerful functionality can be built.

Of course, you can always ping me to check anything.

Hopefully, we can finally get your storage adapters supported officially! 🎉

I also really need to set up a GH org to collate all the official storage adapters.

Thanks again for offering to help!

@lukechilds
Copy link
Contributor Author

Also paging @dusansimic @rubenmoya @thgh as you've shown an interest in contributing.

@lukechilds
Copy link
Contributor Author

Just gone threw all open issues on Keyv and storage adapters. Just wanted to also page the following because you've also made good suggestions/contributions:

@TehShrike @chocolateboy @adityapatadia @thebrodmann @rarkins @bahmutov @MySidesTheyAreGone

Just wanted to make you guys aware of this issue. Apologies for the spam, please unsubscribe if you're not interested.

@e0ipso
Copy link
Contributor

e0ipso commented Jan 5, 2019

I also have more OSS than I can chew at the moment, so I empathize with you. Thanks for thinking of me, but I don't think I'll be able to make the commitment.

Thanks for all your contributions and for trying to stay healthy. The community needs you strong and motivated, take your time.

@UltCombo
Copy link

UltCombo commented Jan 5, 2019

I’ve also had an extremely busy year with paid work (which unfortunately takes priority over OSS so I can afford to live). On top of that, I’ve had a few personal/relationship/financial/mental health issues that I’ve been dealing with this year too. As a consequence, OSS has been pushed on the back burner a bit. I haven’t invested anywhere near the amount of time I’d of liked to into OSS (especially Keyv) this year.

I understand perfectly, I've been on a similar scenario an year ago. Now I have a new job and a bit more of free time, so I may be able to help with reviewing and planning at least.

If we make a change to the core module and only test it against one adapter it could break others. We need to be very careful about changing anything and test thoroughly.

On a side note, are you not a fan of monorepo approach? Tools like Lerna could help with that. One of the main points is being able to test all packages together.

P.s. @FabricioMatteMassive is my work account, @UltCombo is my open source account. It was a requirement from contractor to use different accounts. Sometimes I forget or am lazy to switch accounts. 😅
So yes, this is my main account for open source.

@dusansimic
Copy link
Contributor

I'd like to help but I'm also a bit overflown at the moment. I'll help with the PRs as much as I can in any way possible. Other than that I'm glad there are people willing to help out with Keyv. 🖖🏻

@lukechilds
Copy link
Contributor Author

lukechilds commented Jan 6, 2019

@e0ipso

I also have more OSS than I can chew at the moment, so I empathize with you. Thanks for thinking of me, but I don't think I'll be able to make the commitment.

Thanks man, take it easy, don't work too hard 👍


@UltCombo

I understand perfectly, I've been on a similar scenario an year ago.

Glad you managed to get through it ok.

so I may be able to help with reviewing and planning at least.

Awesome, no pressure at all, if you see something you wanna take on, just go ahead and grab it.

On a side note, are you not a fan of monorepo approach? Tools like Lerna could help with that. One of the main points is being able to test all packages together.

I've never really been a fan of monorepos but I can actually see how that would be very beneficial in this case. I had a nightmare a while ago trying to test stuff locally with npm link due to circular dependencies between Keyv and the storage adapters.

I would definitely be open to giving it a go with Keyv.

P.s. @FabricioMatteMassive is my work account, @UltCombo is my open source account.

Ahhh, that makes sense. I thought it was strange that one account opened a PR and the commits were all from a different account. Assumed you were coworkers or something. 😆


@dusansimic

I'd like to help but I'm also a bit overflown at the moment. I'll help with the PRs as much as I can in any way possible.

Thanks, much appreciated. A little word of advice, if you're too busy to take on extra work, don't take on extra work 😉. I've definitely learned that the hard way this year.

But if you do find yourself with some time to spare and fancy doing some work on Keyv then by all means, go head.

@adityapatadia
Copy link
Contributor

adityapatadia commented Jan 6, 2019

I would help with PR merge and issue replies for Keyv. I have also written adapters for keyv like https://www.npmjs.com/package/keyv-mongo-gridfs and I can help maintain existing adapters.

Cacheable-request is even more important for us at https://www.gumlet.com/. We use GOT in production and have found bugs in cacheable-request in past. I can offer more time to keep it up-to-date and bug free.

@lukechilds Apart from OSS contributions which we will obviously do, are you considering any sponsorships for keyv / cacheable-request projects? If you can put Gumlet.com name / link as a sponsor in readme, we can sponsor development or work full time on these projects to keep them up-to-date. Please let me know.

P.S. I am founder of company Turing Analytics which operates Gumlet.

@lukechilds
Copy link
Contributor Author

@adityapatadia

I would help with PR merge and issue replies for Keyv. I have also written adapters for keyv like npmjs.com/package/keyv-mongo-gridfs and I can help maintain existing adapters.

Cacheable-request is even more important for us at gumlet.com. We use GOT in production and have found bugs in cacheable-request in past. I can offer more time to keep it up-to-date and bug free.

That's awesome, great to see it's being used in production!

@lukechilds Apart from OSS contributions which we will obviously do, are you considering any sponsorships for keyv / cacheable-request projects? If you can put Gumlet.com name / link as a sponsor in readme, we can sponsor development or work full time on these projects to keep them up-to-date. Please let me know.

That's a really interesting offer, thanks. If you/your company/anyone else makes significant contributions I will happily credit them in the readme. I like the way @sindresorhus does it on Got: https://github.com/sindresorhus/got#maintainers

The idea of sponsoring actual development time is interesting too. Feel free to email me if you want to discuss that further: lukechilds123@gmail.com

@TehShrike
Copy link

I'm open to maintaining this set of libraries.

I've been considering forking keyv in order to add the somewhat-breaking changes suggested in #64. In the long term I'm only interested in maintaining a version of keyv with these changes.

Other than those changes which are necessary for my long-term use, I would be very resistant to adding any new features, which means maintenance would involve answering questions, dealing with any potential bugs that might be found, and dropping support for old JS versions and testing in new versions of node as time goes on.

That's about the tack I took when I took over the deepmerge project a couple years ago.

I'm currently freelancing, and if there are companies using this library who would be interested in purchasing support contracts, I am open to personally fulfilling those.

@lukechilds
Copy link
Contributor Author

@TehShrike

Other than those changes which are necessary for my long-term use, I would be very resistant to adding any new features, which means maintenance would involve answering questions, dealing with any potential bugs that might be found, and dropping support for old JS versions and testing in new versions of node as time goes on.

I think we have similar ideas for Keyv. I have lots of things I want to build around Keyv, but not in it's core. (See #35). The main thing that really needs to be done is #36 to enable more features to be build outside of Keyv.

@lukechilds
Copy link
Contributor Author

@adityapatadia Thought you were going to discuss hiring me to work on this like part time or full time or something, that's why I asked to move the discussion over to email.

Will paste your email in here to keep the discussion open and so people are aware no money has changed hands for access rights 😉

Hi Luke,
I appreciate the efforts you put to build keyv and cacheable-request and as I mentioned in mail, I would be happy to offer my axe to maintain them in a healthy way in future for everyone.

For keyv, I and my company can offer time and resources to comment on issues / close PRs and occasionally add some new features. We will gradually increase our time dedicated to the same. It would be great if you can put our name as maintainers after we help you with some significant features. Please let us know what it will take to get us there. To get started, you can give me rights for code editing / PR merge on Github and keep publish rights to NPM to yourself.

For cacheable-request, we would offer full time feature addition / bug fix efforts and we are also willing to improve the functionalities as desired by community. We at Gumlet.com has also some feature requests which we will submit and merge. We can ramp up the efforts as soon as we are on-boarded. If along the course we feel we need more help, we will also financially sponsor its development.

I would also like to mention that I have a good experience in OSS. I created this image resize library in PHP about 6 years ago which I am still maintaining and it’s downloaded more than 19k times last month. I am not a big contributor to any nodejs package currently but in past I maintained this library for beaglebone which is still being used by some people. I will ensure the code quality in nodejs will not disappoint you :)

Let me know your thoughts. If you things look fine, you can give rights to my Github account @adityapatadia.

Regards,
Aditya Patadia

That's a really great offer thanks. I've added you as a collaborator to Keyv and cacheable-request.

One thing I'd just like to clarify:

We at Gumlet.com has also some feature requests which we will submit and merge.

This is totally fine and it's great that you're contributing features back. But it's important that the features are beneficial to the community as a whole, not just Gumlet. If you are adding Gumlet specific features or increasing code complexity for features that only really Gumlet benefits from it may be better to maintain these types of changes on a Gumlet fork.

Thanks so much for offering to help out!

@adityapatadia
Copy link
Contributor

@lukechilds We would obviously add features which we think will be used the most by others as well and when in doubt, will always loop you in.

Thanks for pasting my email, I appreciate the transparency. As I said in my mail, we will consider sponsorships if we feel our hands are full and we need extra efforts.

@lukechilds
Copy link
Contributor Author

@adityapatadia Yep, totally understand just wanted to clarify.

Glad to have you on board 🎉

@jaredwray
Copy link
Owner

@adityapatadia, @e0ipso, @TehShrike, and @UltCombo. I am taking over this project. Let me know if there is anything urgent and I will start to look at it. The goal I have now is to get through updating all the base supported stores then get to the main project. We have already updated and put live @keyv/redis, @keyv/sqlite, and @keyv/postgres.

Let me know if there is anything urgent to tackle sooner than later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants