New project maintainer/owner required

[sbfaulkner]

It's been several years since I've been engaged with this project.

Thanks to @shuber for starting this.
Thanks to @billymonk for helping maintain "way back when".
Thanks to @saghaulor for managing things since then.

None of us have had time for this in quite a while though.

So...

If you have an interest in taking over this project, please respond here. Hopefully we can find a group of interested contributors to take over.

Cheers

--Brent

[saghaulor]

I apologize for not being a great maintainer over the past couple years. Life has caught up with me. As @sbfaulkner said, it may be time for another maintainer to step up. I will do my best to keep things moving, but I really don't have the time anymore.

If you feel like you can handle this project, please reach out to me.

[dudo]

We could just support another library? I've used attr_encrypted for a long time, but maybe it's time to shift?

https://github.com/ankane/lockbox looks promising.

[david-a-wheeler]

Note: This gem attr_encrypted does work with Rails 6.1 (!). My apologies, I misunderstood an earlier error.

@dudo : My existing application depends on attr_encrypted. It'd be a pain to rewrite it for a different API. I'd prefer to keep using the existing attr_encrypted API (in part because most code "just works" correctly) instead of trying to rewrite existing code for a new API.

[david-a-wheeler]

Note: This gem attr_encrypted does work with Rails 6.1 (!). My apologies, I misunderstood an earlier error. It definitely should keep going.

Also: I think it's reasonable to have this gem not have a lot of functionality. "It does this one thing well" is perfectly reasonable.

[majormoses]

@david-a-wheeler I don't think anyone here is saying that this project should die, the maintainer is asking for someone to pass the torch onto. I have been on both sides, it can be bittersweet. I have maintained thousands of open source projects and still maintain a fair number when I can spare the time. It is a lot of work and it's not fair to assume that because someone started or maintained a project at one point that they will be in a position or want to do that forever.

I would like to thank all the amazing folks who put in their time into building something that so many have relied on over the last decade. This includes maintainers, code contributors, bug reporters, feature requesters, etc.

[david-a-wheeler]

I also want to greatly thank all the amazing people who've put work into this!

[mvastola]

Hi @sbfaulkner,
I work for a fairly mature startup named DailyPay. We are a FinTech company of 300+ employees based in New York*. I saw this issue linked in your README.md, and wanted to reach out as we'd love to offer our resources and passion by taking up the slack/reins and helping this project continue to flourish.

We have actually been using this gem in-house since we began in 2015, and are -- obviously --quite fond of it. (Incidentally I believe one of our founders is a former colleague of yours'.) In any case, given the nature of our business, we are very passionate about keeping our (and our users') data secure. We would love to, in this small way, help the greater community do the same. As we would need to maintain this gem anyway for our own use, this seems like almost a perfect fit.

I'd love see if we can make this happen and would be more than happy to discuss a possible transition. I'm not sure what medium would be preferable for you, but please let me know and I can make it work.

* As a bit of background, our firm helps employees achieve financial security by being able to access their pay right after they've earned it, instead of waiting for a payday. We don't do loans and we don't charge any sort of interest. We work directly with employers to integrate into their payroll systems and our service is offered as a benefit to employees. If you're curious, more info about us/what we do can be found on our website.

[sbfaulkner]

thanks for your offer @mvastola

I think the primary qualification we have for this is interest, so this is great news!

I'm pretty much open to ideas regarding the transition, and figure we can probably manage it here in this issue.
We haven't had much in the way of formal process or ownership or roadmap or anything, so there won't be much to do.

@saghaulor as the most recent steward, I'd appreciate your input on how we should do this.

As a start, in no particular order, we'd need to deal with...

• add you to the attr-encrypted github org and/or repo
• any rubygems authorization

if anyone comes up with other things we'll need to address, please comment here ❤️

[mvastola]

@sbfaulkner Awesome!

I can't think of anything major. The only additional changes I can think of that might come up are:

• I imagine we may want to transfer this repo into our GitHub organization to simplify management/access control.
• I imagine we might switch the CI from Travis to BuildKite, but, again, I haven't spoken to our devops team, so it's just a guess.

We haven't gotten into too much detail on the logistics of this internally though (other than being enthusiastic about extending this offer), so these are just guesses. Given your interest, I'll investigate this further, and we obviously won't be making any changes until then.

[saghaulor]

@mvastola that's great news! Don't you think it would be better to keep the project under the current org, so that no particular company owns it? Then if you end up in our situation where you just can't find the time to dedicate to the project, you don't have to worry about an org transfer, you just request that you be removed as maintainers? I worry that a particular company owning it will cause it end up like Paperclip, where everyone thinks it's dead and then another org must fork it to continue the work.

I don't have any particular affiliation with Travis CI, but it seems to have done a good enough job. Is there a reason to change things?

My only input would be that I tried to make this gem be as simple and most secure to use as possible. That being said, having a bunch of people that can push to rubygems reduces the potential security of the gem. I would say that we should be careful about how generous we are giving access to rubygems. The same could be said for Github, but at least then you can see the source code before you pull it. It's possible that someone can push to rubygems and not github, removing transparency. Of course once you pull from rubygems you can inspect the source, but I don't know that a lot of people do that.

Related, I tried to sign the releases, but I don't think anyone checks that stuff. When I asked around there were only a handful of projects on rubygems that actually signed their work. The signing process is weird because you have to sign, then push the code, then push the signatures after, or something like that. I can't remember the order of operations, but it was a little tricky to get right.

I had plans to do a major code cleanup in the next major release, dropping some functionality, and cleaning up the tests. People have tried to drop support for legacy releases of Ruby and Rails, but I kept that code around because it didn't muddy things up that much, and it's nice to have a library that works across multiple major releases of Ruby and Rails, so that upgrading is rather painless.

Should you become the new maintainers, it's obviously up to you how you want to do things, I'm just giving my approach to things as @sbfaulkner requested.

[mvastola]

@saghaulor, to reply to your points:

Organization

In talking to my team I apparently spoke to soon re: those two predictions. We are not planning on making any of those changes. I had just assumed we'd want to. This is our first foray into the open source world, so I didn't have any precedent to go by. I was just using what we do for other projects and what other gems do as a frame of reference.

For what it's worth, even if we had done this, we certainly wouldn't consider it to be owned by us (as that's kind of antithetical to the idea of OSS), and I would be very shocked if there were ever any consideration of us holding this hostage if we could no longer support it, whether or not we moved organizations on it.

Part of my thinking on this was that we would make it match the way we work internally, and internally we work with branches instead of forks. But, as far as I know, our approach is going to be to not change anything that isn't broken. Along the same lines, we use a CI service other than Travis, which is the only reason I thought we might change from them.

Security

Our approval pipeline gives maybe half a dozen people (max) the ability to deploy releases as well as to merge to our master branch. I'm not sure how many people will actually end up working on this (though obviously we'll make sure all PRs/issues get fielded in a timely manner) so I doubt we'd have a "too many cooks" issue there.

I'll see if we can get signing figured out. (It's a nice-to-have, even if it's not widely used yet.) It's also possible our devops people would be willing to construct a deployment pipeline for the gem that might make signing and releasing more consistent/automated, but I don't want to make any promises I can't keep.

Lastly, to be clear, regarding for any future work you are hoping to do, we would definitely love you to still be involved to whatever extent you'd like. (This goes for the current maintainers as well.) We're certainly not looking to push anyone out.