The Artsy mobile team is small, especially in contrast to the other teams in this issue of objc.io. Despite this, we’re notable for our impact on the community. Members of our iOS development team are — and have been — involved in almost all major open-source projects in the Cocoa community.
Artsy is striving toward a technology culture of what we call Open Source by Default. We’re not the only ones. Something being open source may sound like a purely technical distinction, but it affects culture more than you might think. Open source isn’t just a setting on a GitHub repository — it’s a sentiment shared by everyone on our team.
Our team intrinsically believes in the ideas of open source. Though our individual motivations vary — from a conviction in the power of education to a determination to help others see from giants’ shoulders — we all maintain the value of open source.
Everyone on our team believes that unless there is a good reason to keep something secret, it should be open. That doesn’t just apply to code, either. We hold regular meetings on Google Hangouts On Air and invite anyone to join and ask questions. Our team is also organized using an open-source repository.
Our small team makes a conscious effort to contribute significantly to the Cocoa developer community. We do this in three ways:
-
We actively try to release components of our application that may be useful to others as open-source libraries.
-
We use others’ libraries while sending feedback, bug reports, and pull requests.
-
We encourage all team members to be active in the broader community, through speaking, blog posts, or books.
There are well-understood reasons to reduce the size and complexity of any given codebase. By writing small, well-tested components, we increase the overall stability and cohesion of our apps. Additionally, by writing reusable libraries, we reduce effort when building multiple apps.
Artsy has three main iOS applications, along with some smaller side projects, so not having to reinvent the wheel with each new project saves time. Improvements or bug fixes to a library written for one app are easily shared with the others. We’ve done well in leveraging this strategy of reuse so far, but there is still room to improve.
Dividing our applications into small, reusable pieces has a lot of technical advantages, but it also allows us to create distinct owners for the different components. When we do this, we need to make sure that we consciously spread knowledge to other team members. On both libraries and main codebases, we use peer code reviews on pull requests, ensuring that teammates are familiar with as much of our code as possible. This is really important; when a member of our team was suddenly and unexpectedly summoned for three months of jury duty, we didn’t have to panic because we were not in a situation where that developer was the only person who was familiar with certain parts of our codebase.
Beyond practical improvements to our team management, encouraging developers to explore different aspects of iOS development helps them grow as people and professionals. While we are certainly specialists in iOS, exposure to other languages helps us stay sharp, relax, and discover new ways to solve familiar problems.
We work remotely; our team has not yet been all in the same room together. By operating like an open-source community, we embrace — not fight against — the asynchronicity and flexibility inherent within our team structure.
At the start of 2015, we finished open sourcing the Artsy iOS app, eigen. This is a process that took many months; we needed to take considered, incremental steps both to prove that there was business value in open sourcing our consumer-facing app, and to disprove any concerns around letting others see how the sausage is made. This wasn’t a hard decision for our company, because sharing knowledge is a core value that everyone in our company believes in.
The first steps toward open sourcing eigen were already complete; we had open sourced as much generic code from the application as we could. Most of our time preparing was spent ensuring that sensitive details in our git history and GitHub issues didn’t leak. In the end, we decided that creating a new repository with a fresh history and issue list was the safest route.
Earlier, we said that being open source by default means that everything stays open unless there is a good reason to keep it secret. The code we do share isn’t what makes Artsy unique or valuable. There is code at Artsy that will necessarily stay closed forever. Practical examples include the use of a commercially licensed font or the recommendation engine that powers The Art Genome Project.
After setting the gears in motion to open an existing app, the next step was to build an app entirely in the open — from scratch. This gave us the opportunity to figure out how we could deal with project management, tooling issues, and actual development in the open. The experience felt very similar to working on a community-run open-source project.
We didn’t lay out a strict roadmap during initial development (something we’ve since fixed). This was partially due to a rush to complete the project on time, as well as lots of communication in our private Slack channel. Over time, we’ve tried to move more and more of our interactions into the public repository.
Developing a complex iOS application in the open is something that not many companies have done. As a result, there were gaps in tooling that we’ve had to address. The most significant was keeping our API tokens a secret. In the process of solving this problem, we’ve made a new, more secure way to store these keys.
Artsy is a design-driven company, and our designers are frequent collaborators during the development process. With very little help, our designers were able to adjust to working in the open. They were already familiar with using GitHub to provide feedback asynchronously, so moving their remaining contributions to the open was fairly easy. They have similar ideals about giving back to the design community and consider working in the open to be as much a step forward for themselves as for us developers.
Now that we’ve covered the hand-wavey, philosophical stuff, let’s talk about the nitty gritty of day-to-day work in the open.
Working in the open isn’t so different from typical software development. We open issues, submit pull requests, and communicate over GitHub. When we see an opportunity to create a new library, the developer responsible for that library creates it under his or her own GitHub account, not Artsy’s.
This encourages a sense of product ownership. If a team member has a question about this library six months down the road, it's clear who to turn to. Likewise, that developer now feels personal ownership of that code, helping to cultivate a fulfilling and joyful work environment. Finally, developers know that the code they make belongs to them, and they can continue to use it after leaving Artsy.
Let’s take a look at an example.
Like responsible developers, we try and automate as much of our jobs as possible. That includes using continuous integration to minimize the introduction of new bugs and regressions. Currently, we use Travis for our CI needs, but other solutions exist.
Many of our tests are based on Facebook’s iOS Snapshot Test Case library. This allows us to construct a view (or view controller), simulate some interaction, and take a snapshot of the view hierarchy for reference. Later, when running our tests, we perform the same setup and snapshot the same view class. This time, we compare the generated snapshot to the earlier reference file.
A problem we were facing involved the use of Travis. Sometimes, snapshot tests would fail remotely on CI but pass locally. Snapshot test failures leave behind reference and failed images that you can compare with Kaleidoscope to determine the problem. However, on CI, we didn’t have access to these snapshots files. What could we do?
During a weekend hike in Vienna, Orta and Ash discussed possible solutions to this problem. We ended up building a tool called Second Curtain that would parse xcodebuild output. If it detects any failures, the failing snapshot and the reference snapshot are uploaded to an S3 bucket where they can be diff’d visually. This tool was the first time Ash had built something non-trivial in Ruby, giving him the chance to improve our tooling and to expand his knowledge.
People often ask why we operate in the open as we do. We’ve already discussed our technical motivations, as well as the sense of purpose it gives individual team members, but honestly, working in the open is just smart business. For example, we’re working on a single open-source library to handle authentication with our API. Not only does this make writing apps against our API easier for us, but it makes it easier for everyone else. Huzzah!
There is a tendency, particularly in iOS developer communities, to eschew third-party dependencies. Developers fall victim to "Not Invented Here" syndrome and end up wasting valuable hours of development time tackling the same problems others have already solved for them. On our mobile team, we vehemently reject NIH syndrome and instead favor the philosophy of “Proudly Discovered Elsewhere” (a phrase we appropriated from another developer, naturally).
In our field, personal and professional growth are expected from employers; however, these processes are not just checkboxes on some HR form. If you’re doing them right, they should be daily activities that are intrinsic to your work. We accomplish this by working as an open-source team.
By developing our software in the open, the larger developer community is able to offer feedback on our work and we get to work with awesome developers all around the world. Sharing knowledge with others also helps cultivate an amazing workplace culture — one we’ve become known for — which in turn attracts great developers to work with. You can never have too much of a reputation, after all.
We often codify the knowledge we’ve gained on our blog or in presentations at conferences. Not only do these artifacts help to spread our knowledge to developers outside Artsy, but they also facilitate in bringing new members of our mobile team up to speed with how we work and the tools we use. We’ve even shared our experience sharing our knowledge, one of our more meta endeavors.
Working in the open isn’t all rainbows and puppy dogs, but the problems we’ve encountered have been minor. A common concern in open sourcing a codebase is the potential embarrassment of allowing others to see less-than-perfect code. However, we believe the best way to improve is by opening oneself up to critique. Critique is not a reason to feel embarrassed — and really, every developer understands that when you have to ship on a deadline, sometimes hacky code makes it into production.
We do know that some of our competitors use our code, because they offer their fixes back to us. We do the same. In reality, the biggest challenge to a business open sourcing a project is the obligation of stewardship. This responsibility is mostly a matter of working with people and needs to be managed correctly — especially if a project gains enough popularity. Most projects don’t get large enough for their stewardship to become burdensome.
It’s easy to release code and then either abandon the project or ignore the community, but we gladly accept the obligations tied to running a project in the open.
The extra time necessary to create and maintain open-source code often helps us unwind and relax from our day-to-day tasks, and over-communicating on GitHub has helped the remote members of our team.
In our experience working as a small team in a company that believes in open source, any risks or costs associated with Open Source by Default are negligible. If actual disadvantages even exist, they are far, far outweighed by the technical advantages, business prospects, and personal joy of working in the open.
There is a fundamental difference between releasing a library to the open and creating an open-source library — the same difference between the technical distinction of open source and the mentality of open source. The difference is summed up by answering the following question:
Are you opening code only for your benefit, or are you doing it for the sake of everyone?