Once a Maintainer: Josh Branham
The journey to making attr_encrypted compatible with Rails 7
Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story.
This week we’re talking to Josh Branham, contributor to the popular attr_encrypted gem and the person who made it compatible with Rails 7. Josh is a backend engineer based in Boulder, CO where he works as a Staff Engineer for Salsify. We talked with Josh about custom forking, the guts of Rails, and how to get to the right person in an open source project.
How did you get into programming?
I took the path that I think is more common than I thought it was, which is going from desktop support/systems engineering and building data centers and all that, to DevOps, and then after a while I was just like, man, I'm tired of writing Chef and Puppet. How does this stuff actually work?
I just got more interested in how can I write automation that isn't just bash scripts and like, how do I actually build tools? What are the people on the other side of the fence at my company doing that actually build the product? Thankfully my company knew that I wanted to write software and not just be a sysadmin with a fancy title. So I got more and more interested in that stuff, and then through various reorgs and things ended up doing software full time.
How did you choose that path to begin with, from when you were younger?
Yeah, I feel like most people in our industry, I just liked computers when I was a kid. I was just kind of tinkering and, you know, how do I make video games, that kind of thing. In high school I had information technology courses and we did some C++ and I was like, man, this is hard. My friend helped me do all that homework in high school and then we both went to college for Computer Information Systems, which is half business, half comp sci. I struggled on the math and on some of the weirder stuff. We did COBOL and Visual Basic - lots of Visual Basic. So I did all that stuff, but I never thought that I wanted to do it as a career. I was more interested in networking and storage and like, how does virtualization work? VMware also came out around that time. So that seemed like the new hot thing. So yeah, that's how I kind of ended up there.
Do you remember the the first computer you ever had access to?
Yeah, it was an HP with, I think it was, Windows XP. That was like my first new computer that my parents got me for Christmas. They wrapped up a SpongeBob mouse pad and gave that to me as the gift. And I was like, why do I have a mouse pad? This is weird. And they're like, “Go downstairs.”
So what led to getting into open source and then attr_encrypted? How did you make that leap into into open source?
One of the first ones I got involved with was kOps, which is for Kubernetes. It existed before Amazon had a Kubernetes offering and Azure and all of these kinds of things. In my company around 2016-2017 we had started with Kubernetes, and back then it wasn't very turnkey. kOps was really the thing that made it so people could set it up in the cloud.
I actually knew one of the maintainers from Boston, where I'm from originally. I got added as a reviewer and just started doing some simple stuff just to you know, see how this open source thing worked. And that’s all in Go. At the time, Go was very important to me. I didn’t do too much, but it was interesting to join the office hours and get pinged on PRs and just vet them for being reasonable changes, even if I didn’t know what the idioms of Go might have been at the time.
With attr_encrypted, I guess like most people we ran into the Rails 7 issue and some Ruby keyword arg deprecation issues and stuff like that. We ended up forking it and I made some changes. Technically I’m on a developer experience team, but I'm within the infrastructure group and we provide all sorts of platform defaults and best practices and things to devs. And some of that stuff is a guideline that says you should use attr_encrypted for encrypted attributes, and here's how we recommend using secret key and all this other kind of stuff. Just to kind of guide people on the right path. So when something like this comes up like, oh, no one can upgrade Rails versions, you know, it ends up being us to spend a little time to figure that out.
So I did the fork and then realized a bunch of fixes need to be made - why isn't anything happening? And then I found the “maintainers wanted” GitHub issue that was two years old and 500 comments deep and I found out that someone else had taken over maintainership of it, but hadn't really done much. So I reached out to him and I was just kind of the squeaky wheel, we chatted a bit and you know, he didn't really have much time to work on it or desire anymore. But he was kind of the gatekeeper, so I had to work with him to figure it out. And that was a very interesting thing for me to navigate because most of my experiences working with other devs have been inside my own company.
And I'm just like, I'm just trying to fix these problems for people. I don't necessarily want to rewrite this entire gem because I think people are just going to stop using it when they use Rails 7 eventually. So I'm just trying to like build a bridge, you know, to Rails 7.
How do you actually work through that practically with someone you never met before?
We ended up using Keybase, just a messaging app. That's where most of our conversations happened. We never got on Zoom or anything like that, which probably would have helped to be honest. I feel like a lot of people run into these things and you've never met this person, you're talking about technical things and you're doing it via texting basically. So that was interesting.
I just checked and there are 432 forks on Github. So the code that makes this gem compatible for the next version of Rails had already been written. Maybe a bunch of people wrote it. But what you did was the political problem of taking that and taking it upstream so that there’s an official fix, which is purely a human collaboration problem.
Yeah, I mean in my case my company is all for people contributing and we have engineering time as we call it, where every Friday you can basically work on anything. And especially in my group, we don't have PMs and deadlines or you know we're not shipping product that customers see. So when something like this comes up it's like, oh, yeah let's just go make that better. My coworker has done a lot of stuff for Kubernetes and some other things.
I will say full stop that the way attr_encrypted hooks into Active Record, there's a lot of stuff there that I didn't fully understand and I had to really dig into, and this is one of my gripes with Ruby. There's just a lot of stuff going on there. And there's still huge problems with, you know, how do we deprecate old version support and testing. And that's still something that politically we haven't decided.
In this case it's supposed to be a generic attribute encryption tool. So it worked with DataMapper which doesn't even exist anymore. It was formed into a new tool and all the tests are still there for that and it's still pulling the gem in and that gem doesn't work with like 2.7 etc. How do you make the test suite work for that when you have this old thing. So then you say ok, let's just remove that old thing. Then someone's like no, someone might still be using that for their big company. And it's like, yeah, but they're on Ruby 2.5. I don't care. I should care. But it makes your world really hard, especially when you're just contributing free time to an open source project.
Whether it's naive or not, I'm just assuming that most people that are using this tool in a modern tech company are not on Rails 5 and Active Record 5. There might be some, there's definitely some, but you know, that's something I didn't have a good sense of. Because internally at my company, if we build a new version of something, here's an automated report that says all the services that haven't migrated this thing and we're just gonna spam those managers until people put it on the roadmap as tech debt. Versus open source, that's not the way that works. And you have to think about all those other cases.
One of the questions that we have is how do we get more people into open source? And this kind of touches on the friction that you encountered.
Yeah, so another interesting thing that I found with my company is that part of promotion is your impact in the communities with the tools you're using. So actually you're actually incentivized to be involved in these projects versus just using them. If you've heard of Ember, our front end architect is one of the key maintainers. We have super active maintainers, multiple in our company working on Ember because we use it for everything. Our founders were all engineers originally and they understand open source, so that helps.
I know for me, getting into open source was kind of intimidating. The asynchronous nature and what are the contributing steps, like, do I open an issue asking if my approach to a problem makes sense? That alone is probably intimidating for people. Other people go the complete opposite way and spend 40 hours making this giant change and opening a PR from their fork, and then they just get shot down because the PR is way too big, and it doesn't follow the semantics that are probably not documented, but they're documented in code, but maybe you didn't pick up on them. That stuff is hard.
Mentorship of people into open source is probably the best thing. In my example, if my company is incentivizing me and giving me the time to work on open source, maybe I can then use that to mentor more junior engineers to also get involved in that project. I feel like I got that with kOps. I would go to office hours, meetings, and anyone from the community that wanted to come could join and there was an agenda and they could just say, I think we should use, you know, the widget service from Amazon to do this thing now. And then me as a junior engineer at the time could ask really dumb questions like why? And I think that that was super empowering to be like, oh, maybe I can be in these conversations and maybe I can review this code even if I don't understand 30% of it or something.
What are some of your other favorite gems or packages?
This one is hard because Ruby is so turnkey and has so much built in. Active Support is something that I've used outside of Rails heavily, but my other vote would be OctoKit because I think GitHub just makes good packages. I've done a ton of automation with GitHub in my Ruby days and OctoKit has always been the one.
And what about other people, who do you think is doing some interesting work?
My non-Ruby answer to this is spf13 in the Go world, who wrote cobra and afero and a bunch of other stuff. You'd be hard pressed to find a Go CLI that doesn't use cobra, including Kubernetes. Really good packages. I've been writing a lot more Go in the last couple years so that's where most of my my brain goes to by default now. But yeah I think that's an interesting thing about timing. Go isn't that old and it's a simple language. You know when a new language comes out, people are like, oh, let me build a CLI abstraction and you get there first and then it becomes popular and everyone uses it. So that's a super interesting thing about new languages.
The guy who got me into kOps, his name is Mike Splain. I think he's at Sonos now doing Kubernetes stuff. I met him at a meetup back when we were starting to do Kubernetes at my company, and he was presenting about kOps at the meetup. He was very nice. It shows that just one person can kind of get you into the community.
Once a Maintainer is written by the team at Infield, making open source dependency upgrades safer and faster.
To suggest a maintainer doing awesome work in the community, find us on Twitter at @infieldai.