Open Source as a Full-time Job

I have no idea what you did at your job last week. I couldn’t find out if I wanted to. But if you were curious enough about it, you could find out exactly what I did, Monday through Friday. For instance, on August 31, 2016, I made 3 commits to various branches on Reaction’s main repo. Two of them passed their tests. One failed, and I had to go back and fix the error. Yesterday, I spent my day fixing linting issues for our upcoming release, and today, I prepped our repo for our next release, which I happen to be the lead on.

You didn’t need me to tell you that, though. That’s because everything I do, every single day, is visible for the world to see on GitHub. We do have a few private branches, which I work on occasionally, but other than that, the bulk of my work, along with the work of all the other developers at Reaction, is right there for you to see. It’s intimidating. It’s gratifying. It’s fun. It’s terrifying.

This is the first time I’ve worked for an open source company. Prior to Reaction Commerce, I was at Media Temple and TTPM, both closed source companies. It’s been a challenge, but thanks to the transparent, connected, and collaborative nature of open source, I’ve become a better developer and communicator, and I’m learning a lot, each and every day. Here are some of the unique lessons I’ve taken away from working in open source full-time.

Absolute Transparency is Absolute

You can tell a lot about me based off of my GitHub activity:

alt

You might notice that I’m a night owl based on the times of my commits. You might also notice that, for two weeks, I made no contributions to the project because I was on vacation. You can see my biggest coding days, which I’m proud of, and you might think, “That’s nothing!”. My livelihood is yours to judge, all without my input. It’s a scary thought. It’s also scary to think that any prospective employer down the line has a fully documented day-to-day rundown of everything I do.

In a closed environment, a lot of what happens goes under the radar. It’s discussed in small teams, or not at all, and as long as it works, it’s never questioned. But in an open environment, I can’t hot-fix code. If one line of code needs to be changed, it’s my duty to inform the community and tell them what I’m doing. I make an issue, create a branch, make a PR, and then ping a team member to merge it in. Everything we do affects thousands of people everyday. Every variable changed could break a store.

Learning to be completely transparent has been a challenge, but I believe it has made me a better developer in documenting our ideas and forcing myself to see what I’m doing. A couple weeks ago, I made a Pull Request from a branch I had accidentally made off of the wrong branch. It’s a simple mistake that every developer makes, yet my mistake will live on in the Reaction codebase for all to see. I had to explain, publicly, exactly why I was killing one branch to make the same changes in another. Oy vey!

There’s also the matter of unrestrained—and at times, undefendable—visibility of my working habits and contributions. In a closed environment, my direct managers will usually be the only people who have a grasp on my day-to-day activities. If anyone else needs to know, I have a chance to explain what I’m doing. But in an open environment, it’s all out there.

24/7 Availability is Rewarding and Frustrating

In a closed environment, it’s a rarity that you would even need to help anyone with your software’s codebase, because they just don’t have access to it. Any issues are fixed internally during business hours. But at Reaction, our codebase is accessible by everyone, everywhere, and so is our public chat room. Because we are open 24/7, the world can ask us a question at anytime and we need to answer. Some days, we help get a shop back online when something goes wrong. Other days, we spend a couple hours helping someone install Reaction for the first time.

It’s awesome having someone around who you know is going to respond, but 24/7 connectivity can be disruptive when you’re expected to answer inquiries quickly, especially when you’re in the flow of things. Still, the product you’re preoccupied with trying to build is ultimately for the same people you’re helping, so you kind of have to interrupt yourself. Plus, I’d say our community has gotten to know our habits well enough that they know our availability, and so they curb their expectations accordingly.

It’s just nice to see the number of times people say, “Thank you!” in our chatrooms. I’ve been on the other side of things, where someone hasn’t always been there, so I can really relate with how our contributors feel.

Collaboration Leads to Discovery

In a closed environment, you have a team you work with, and that team rarely changes. Decisions, failures, triumphs are all shared between this team, and usually that’s the end of it. I think often about this great quote from our very own Sara Hicks:

“Open source development might just be the peak collaborative experience.”

We have an amazing core team here at Reaction. But in reality, my coworkers are literally every single developer who has ever contributed to Reaction. Whether you fixed a typo (which, by the way, was my first ever contribution, long before I was hired) or contributed an entire dashboard feature, each single contribution has made Reaction what it is today.

Living outside of your comfort zone and receiving constant feedback from users across hundreds of countries and backgrounds has been amazing. You learn new ways of doing things that are completely different to how you usually work, but still lead to the same result. At the same time, having so many cooks in the kitchen causes great contemplation when we want to make changes to our product. It may seem like the Wild West, but we spend a lot of time debating how we should be doing things best. Collaboration makes you think far ahead into the future, which is important for something as ever-changing as JavaScript.

We started in ES5, converted to CoffeeScript for a short while, then went back to ES5. In 2015, we updated our code to ECMAScript 2015 / ES6. We also recently started moving our UI codebase from Blaze templates to React. I’m sure this is the case for thousands of our developers, but at the time, I didn’t know React. Now, you can watch me learn React, first making updates to a few of my colleague Mike Murray’s existing components, and with our next release, you’ll see a few of my own.

These are huge changes. Working on a closed source platform, they are choices that can be easily made and decided upon between a team of developers. But with open source, these are huge decisions that will affect thousands and thousands of people. It puts a pause on drastic decisions. Switching to React means we have to trust that our community will know and want to work with React. We have to explain why we chose React over Angular, LESS over SASS, Mocha over Jasmine, and 2-spaces over 4-space tabs. This can be challenging to productivity, especially when we’re under a deadline, but once we do reach an agreement, we can feel confident that we have the buy-in of our entire community.

Conclusion

I’d never rule out going back to anything closed source (not that I plan on leaving Reaction!), but working full-time in open source has opened my eyes to a whole new side of things that I’ve truly enjoyed. Absolute transparency has made me a better planner and developer. Having to express my ideas to the world before, during, and after implementing them changes the way I do things. The 24/7 availability is both engrossing and also overwhelming. And finally, working with not just the core team, but our GitHub community, pushes me to make decisions together and grow as a developer. When we officially reach v1.0.0 in the coming months, I look forward to facing lots of new faces and contributors to our open source community, and lots more challenges.

Wanna work in an open source environment? Check out our careers page.

comments powered by Disqus