How to Work on Open Source at Your Company
Over the last 6 months, I’ve released 3 popular open-source projects I built at IFTTT (check out RazzleDazzle, FasTTTcamera, and Jot on GitHub!), while still shipping new features and products at a fast pace.
Here are some tips for how you can get started working on your own open source projects at work, while ultimately shipping faster than you would have otherwise.
Finding a Project: It Starts with Writing More Modular Code
Even if everything you work on ends up staying internal, the difference in the way that you approach your code when you’re planning to open-source it ultimately makes your code base much nicer to work with.
When you have a new feature to build out that needs something custom built to support it, try to imagine a scenario where you’d need something very similar, but with a slightly different configuration. Instead of building a single-use solution that will only work with the exact specifications and design you’re given, build something with a more flexible interface that you won’t have to completely rework if the design or specifications change. Try to write the complex logic of the feature in a way that you’d be able to reuse that piece without any changes in a completely different project.
Tools You Wish Existed
When I need to add a fancy new feature to one of our apps, as a first step I like to do some research on whether there’s already a project out there that solves this problem well. IFTTT is built on open source projects, and it makes a lot of sense to spend our time building *actually new* features instead of reinventing the wheel on a problem that’s been solved well before.
Sometimes, I come up totally empty-handed, or more often the best solutions I find have flaws or limitations that would make them more of a burden to use than brewing our own. In that case, I write the tool I wish I had found, then share it publicly. The next person who comes along with a similar problem can use my project instead of repeating my work, and may even contribute features and improvements along the way.
Jot was an example of this. I looked for a great framework that could handle the touch-controlled drawing and text manipulation I wanted to do, and when a tool for that didn’t exist, I built the one I was looking for.
Pain Points in Your Codebase
Another place to look is for pain points in your current codebase. Is there some part of your code that is super complex and easy to break when you need to make changes to it? Something where engineers accidentally introduce regressions and bugs every time they touch it?
In the interests of maintainability, I try to write code that is clear and easy to follow, and aim for simplicity over complexity. Sometimes, though, you need to do something complicated and there’s no way around it. In that case, I like to build walls around that piece of code.
Inside the walls, I can use all of the fancy tricks I need to for it to function well and efficiently. Outside of the walls, I have a simple interface to use when I need to interact with the tricky part. I do everything I can to build the tricky part in such a way that I shouldn’t have to make changes to it internally once it’s working properly, and I write lots of unit tests to make sure that the complex part is working as I expect it to.
If you’re solving a complicated problem other people also deal with, this is a great candidate for open-sourcing!
For example, we had a bunch of headaches around our complex image cropping and orientation code for DO Camera. I rewrote the code into its own framework that would handle the complicated image cropping, scaling, and orientation for a camera viewport of any size, so that changing the camera’s layout wouldn’t break cropping, and all of the tricky code was separated from the main code base. That internal framework became FasTTTcamera.
After you’ve found a project to work on that would be great to open source, you can get to work on it in a way that benefits both you and your company.
Making Open Source Projects Work for Your Company
Does your company value high-quality engineering? There’s a strong incentive to write excellent, well-tested, thoroughly documented code when you know it’s going to be in the public eye.
If your project becomes popular, you might even be lucky enough to have great engineers who don’t work for your company catching subtle bugs and making improvements to the code your products rely on.
And, of course, releasing useful open source projects is great for recruiting smart programmers who are interested in the kinds of problems you’re solving. (By the way, IFTTT is hiring! Get in touch if you’d like to join my team.)
What’s great about this method for working on open source projects is that you can do it as a part of the work you’d need to do anyway to ship a feature or clean up technical debt.
Sometimes it might take a little bit of time to get a project off the ground, or to clean it up so it’s ready for prime-time. In the long run, though, working in this way will almost certainly save you time, as you won’t have to spend miserable days fixing regressions, or making surgical adjustments to a single-use, brittle implementation of a feature.
Originally published at engineering.ifttt.com on August 17, 2015.
Interested in using open source to connect all the things?
Come join us.
