Why Your Default Setting Should Be Open Source

Code Sharing is the Core of Open Source

Code is valuable because it transforms lines of numbers, letters, and words into games, art, apps, and other useful, fun or potentially lucrative implementations. If you’re the only person with access to that valuable code, you’re the only person able to make changes to the end result.

Open Source implies that the code itself is not valuable when compared to the network effects of others using it. That doesn’t mean that all code is up for grabs.

Code that is normally open-sourced is effectively the plumbing for an app; an architect couldn’t re-create the Statue of Liberty by only knowing how the pipes work. Though, by sharing the piping plans, another engineer might be able to suggest an improvement that benefits both construction projects.

Open Source at Artsy

We take the code sharing philosophy a step further and assert that the user-facing parts of Artsy, the website and the apps, are also key parts of the plumbing.

We think about Artsy as more than just the online user experience. We have a rich, “in real life” connection with the art world, a respect for doing things the right way, and we’re trusted by our partners to build the global platform for their valuable content. As our CTO Daniel Doubrovkine noted, “Let’s not disrupt the art market by taking shortcuts, but serve it patiently by creating something new, useful, and timeless.”

As a topline governing principle, Artsy engineers agree that Open Source by Default is the best way for our team to work. However, each engineer brings different ideas and walks along multiple paths. For me, it’s been important to showcase the process and failures behind both simple and complicated products. I established my career as a self-taught programmer, and having examples from experts in the field to learn from and shape my engineering education has been invaluable. I benefited, and frankly needed, companies like Artsy to learn from, companies that were willing to share the amazing products they were working on. I needed to see the code, so I could grow as a programmer.

Our Culture of Cooperation

Open Source also provides a way of working with your competitors on tangential problems; for example Google and Apple — the biggest rivals in the smartphone world — work together on building compiler technology, as well as technology for displaying web pages. These are not showstopper features that sell a product (like an iPhone), but everyone who wants to build a smartphone needs these features as a baseline to start from. Surely, this is a problem that each might be able to solve on their own, but, by cooperating, they found a better, quicker solution and a shorter time to market.

Artsy is no different. We collaborate with our competitors in areas like analytics reporting and presenting tiled images. No one says “I love how well Artsy tiles their images” — it’s not a core competency for the company. By working together on our app plumbing, the developer community at large can make better apps, and focus more systematically on the harder parts — the bits that make people say “wow.”

A recent example of this type of cooperation is how we worked on a problem related to the time it takes for an iPhone app to open for a user. When you tap an app’s icon, the app is told to wake up. However, due to a small bug in Apple’s code, a common use case for developers was missed, meaning that the app could take seconds to load instead of milliseconds. By creating an open space for discussion with other companies, we found solutions and helped Apple fix the problem. It was a win-win-win situation.