What project or projects do you maintain and what was your motivation for creating those projects and releasing them as open source software?

Currently, myself and Andy maintain three main iOS projects used in Buffer. The BFRImageViewer, BFRGifRefreshControl and the BFRReorderTableView. Aside from that, we’ve just recently started to use and contribute to AsyncDisplayKit - which originally was built for Facebook Paper. We’re new there, but we love it and the community is great. It’s helped take Buffer’s performance to the next level, and we couldn’t have done it without them.

Releasing those three components as open source projects was really a culmination of us wanting to put our work out there to help other developers, living up to Buffer’s value of transparency and also just doing what we thought was the right thing. With our autonomous teams at Buffer, we’re really given the freedom to create our own path and take on initiatives we feel are important. Open source made perfect sense for us, and we wanted to give back and add to all of the help we’ve benefited from.

If you created any of those projects, were they meant to solve a specific problem you faced, or were they born out of a larger opportunity you saw?

For those projects - definitely the former. And really, that’s why we were excited to release them to everyone else. This is code we rely on heavily at Buffer, and we’re fortunate to have 115k monthly active users which means we can release it to everyone else with a good degree of confidence that it’s going to be reliable.

We’ve been in the iOS scene for a good bit, and we really have started to know the pain points. We think these projects can help solve a few of those. When you’re trying to get a project off the ground, it’s awesome to be able to plug in some quality work from other developers to get moving faster. We’ve done that at Buffer, and we hope these projects will do the same for others.

How has the project evolved since you first got involved or first released it?

They are still in what I would consider their beginning stages - but we’ve seen some cool things happen. I still remember the first day we had someone else open an issue for one of them on Github, that was great! In my mind I was thinking, “Awesome! Someone else is using this and likes it! And wants to help!”

That’s part of the magic of open source, the community building. It’s definitely one my favorite parts of it. Evolution of the software is a natural part of open sourcing it too, I think. We’ve seen others fork some of the projects and put their own spin on it - and we’ve already worked with others to get their tweaks merged in. It’s been exciting to see different takes on code we’ve used for so long.

How do you spend your time on those projects? (i.e. Developing, managing the community, triaging issues, etc.)

Since we use each one extensively at Buffer, Andy and I are always coding on them. It’s not uncommon to see a new release about every 2-3 weeks. We try to move fast and make sure things work the way they should, and if they do - we want others to get that code as quickly as possible.

At the same time, we’re learning a lot. While we excel at releasing quick, I’m personally trying to do better with the community side of things. I’ve had a few opened issues go unanswered for longer than they should, so I’m trying to tackle those types of things quicker. The thing with open sourcing your code is that it’s no longer just “yours”, so I want to get better at letting other devs get in there and put their touch on it too.

How would you describe the community around projects you participate in? What are your favorite and least favorite aspects?

The communities are amazing, as I mentioned earlier - they are the best part of all of this. We really admire AsyncDisplayKit (ASDK) and what they’ve not only done with their project, but their community building as well. They’ve really welcomed us and let us be a part of what they’re doing.

Of course, seeing other people use your code and benefit from it is super exciting. That will never get old! To be honest, there’s not really any one part of it all that I would consider my “least favorite” thing, to me it’s just really about learning how to be a part of the open source community and getting better at the things you’re lacking in. So you look at those things and issue little challenges to yourself, for me - that’s trying to get better and connecting with consumers of our projects and letting them contribute more.

What keeps you involved in those projects? Do you have long term plans for maintaining your involvement?

I think a few things keep you involved. For one, you ended up there because the code you used maybe saved you days of work, you’re just naturally interested in it or you found parts of it that you really learned from. Inherently, you want to stay close to those types of things. On the other side, if you authored it - you’re already bought in and using it. Hopefully, you want to see it help other people and watch the whole thing grow.

Then, the community part comes in - you meet new devs, make some new friends and the “family” part of it keeps you there even more. We’ve kind of made it our mission to help out the community with our code, we want to share it. And to us, there will never be a time where we get up in the morning and change our minds on that. We’ll be in it for the long haul! The projects might change, evolve to something else or even sunset - but we’ll keep looking for ways to contribute.

What is the most important thing someone submitting an issue or patch should know?

That we definitely look at every issue and proposed tweak. Sometimes, they may not make it in for a few different reasons - but that’s the exception to the rule I’d say. We know sitting down, thinking about those changes and coding them takes time. We want to respect that, because it’s a huge help to us and everyone who uses the projects.

Technically speaking - the biggest things we want others submitting code for our iOS initiatives to know are 1) Does it add value to the core purpose of the component and 2) Does it follow the conventions used in the project. If those both check out, it’s likely getting merged and released!

What’s your development environment right now?

For iOS devs - there really is only one option, Xcode. Luckily, I love the IDE and I’ve grown to be quite productive inside it once I learned the hotkeys and such. To be fair though, I’ve never tried JetBrain’s AppCode. I’ve heard good things though!

What was your first development environment? Do you miss anything from it?

The first place I ever wrote code in, ironically enough, was an early release of Xcode. I’d say maybe it was Xcode 3? I was trying to teach myself how to code around 2010, but I got a bit lost. I ended up going to school for it though, and throughout my education it was all Microsoft since C# and .NET are quite popular here in Missouri. So really, I did my first “real” coding inside of Visual Studio. I still miss it, it’s a great IDE and with Microsoft’s muscle you can be sure it’s going to get steady improvements. They just recently released a version of it for macOS, I’ve been eager to give it a spin.

Where do you see the open source software community headed?

We’re starting to see the big players open source their code, and that’s been super exciting. Who would have thought Apple would totally open up their new flagship programming language to everyone, say, not even 5 or 6 years ago? That’s exciting, and I think we’ll see that trend continue.

Everyone is starting to carve out their little space in the open source world, and places like GitHub are making it more accessible than it’s ever been to get plugged in. I think it’s fair to say that open sourcing your code could very well become a normal practice sooner rather than later, which is exciting to really think about.