Moving to OSS by Default

I interpret OSS by Default to mean that the work I do should go towards the benefit of humanity, and I think that through this pattern, we as developers can create a better world, faster.

Even if it is just by making CRUD applications which make pretty pictures of data.

---

Introduction (0:00)

My name is Orta. I run a team of mobile engineers at a small-ish startup called Artsy. Artsy’s aim is to make all of the world’s art available to anybody with an internet connection. Simple concept. But, what I really want to talk about is the value system of Artsy in relation to open source.

I started working in open-source in 2013. I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.

Impact Through OSS (6:54)

It’s difficult for me to spend my free time working on a project that I know affects almost every single person with an iPhone, and then coming back to a project that effectively makes it really great for students of the arts, and people wanting to buy art. The two have very different levels of impact. I wanted to try and find ways in which I could make a bigger impact with my work at Artsy, in the same way that I do with my spare time in open-source.

This was part of my initial justification for thinking maybe all of our work should be open-source.

So we found a way to create a terminology that describes making everything open-source by default. We should default to open and then we should work our way towards private if necessary. You would have to specifically have good reasons to keep someone private, whereas, if you don’t have a good reason, then it should just be open.

Make Any Mobile Team Transparent (9:24)

This all started by having a good mindset about what we were going to do. I wanted the team to make sure that they felt that they made an impact with their work on a day-to-day basis. And so, in order to get to open-source by default, we had to start thinking about the steps to getting there.

To give an exmple, our flagship iOS app is called Eigen. Because the mobile team now works in open source, you can see all of our commits. We wanted to publicly document all our processes.

Programming/Process

This ranges from talking about our upcoming milestones, to talking about our actual discussions about how projects should be led, how projects should be managed. Managing three or four people is very different from managing two people, which is very different from managing one person. And we didn’t have much experience with working in larger teams. Having these discussions out there in the public view meant that anybody else could go and look, and we got a bunch of really good comments from people chiming in with, “Well, within my team, we have done this…”

Code Review

We try to make sure that all of our code is reviewed on GitHub, unsurprisingly. It’s important we’re not having back room chats. And one of the great things about knowing that every single one of your pull requests is going to be reviewed, not only by people inside, but people outside the company, is that you try and treat each pull request as an atomic thing.

When I write pull requests, I generally have an expectation of two things: Other people do not spend all day working on this application, and there’ll be some of these people that will be code reviewing. Doing this means that I have to write better pull requests because I have to be able to explain for someone everything that’s changed and why. This makes it really easy for us to write better pull requests at the trade-off of taking a bit more time.

Design/QA

We do our design work and our QA on GitHub too. If you are interested in what the next version of the Artsy iOS app looks like, you could just go look under like, UIFix label, and you can actually go and see the upcoming designs. You can see us discussing whether this design could work with the designers. Designers can call out and say what is off in the implementation.

Ease of Install

We cared about it being very easy for people outside of the company to very quickly get a copy of our apps up and running. This has ranged from being simple, to more complex ones that actually require us to have stubbed versions of core data contexts in order to have a version that people can just download and start.

This is important, because these are great learning tools as open-source applications. If you can only just read the code, but not actually run it and run it through a debugger, and start to understand how and why we have come to architectural decisions, it makes it much harder for people to learn.

How We Started the Process (14:30)

It was a two-year process to go open source, and for us, we had to do a lot of ground work in order to get this working.

We tried to think about the core components that our apps had. And then we created a bunch of open-source libraries out of this. It was an easy sell to other developers and to management, because if the library is stand-alone, it will have to be well documented, and we may be able to get some free fixes from it.

My first pitch was actually a very simple one: we were not going to be the first people doing this. There are many, many iOS apps that are open-source that I have learned from.

Helping People Become Experts

We talked about how we could use these apps that we were open-sourcing to help people move from a informed programmer to an expert. An informed programmer is someone that’s probably read one or two books, has enough ideas to maybe be a little bit dangerous, but still isn’t entirely sure what to do next. I felt that by open-sourcing, we could reduce that barrier for people.

Great for Developers

We wanted to make sure that I was building solid foundations for the rest of the team, for the rest of its existence. People are genuinely proud of their work and one of the bad things about having a closed-source application is that you lose access to the code that you wrote when you leave that company. You can take it with you if you want to break the law… But, as a developer, I know that all of the work that I do in Artsy right now will be with me for the rest of my life, because its available for me now, it will be available for me at my next job, and the next job, and I can literally copy and paste it because it’s MAT licensed.

Great for Community Questions

We also have found that we could persuade the management that it would work well for when we tried to ask for help from the community. By being able to have a centralized place for asking for help, we could improve our own standing, and fix our own bugs. We found that it was great because we could get feedback from people on things that we’ve talked about.

Hiring

We could say that by having an entirely open source approach to both the transparency within our mobile team and our code, we could make it very easy to hire. Open-source by default is one pitch that we have that seems to resonate a lot with developers. And that was in my final pitch of why we should be doing this.

Expectations (26:48)

It’s important to then actually discuss a little bit about our expectations. I’ve heard people say that they think that when they open-source an app, it’s going to be very similar to when you open-source a library.

There’s just not a good overlap between iOS developers and people that buy and collect art. So we shouldn’t come in to the idea of open-sourcing our apps with the expectation that we will get pull requests, and that people will actually fix our bugs. You can not foster a community around a commercial application that you have open-sourced, because people aren’t altruistic in that way. And I don’t want people to be altruistic in that way. It’s nice that people can contribute back, but we didn’t come with the expectations that that was going to happen.

All of our apps are CRUD. This is a database terminology that says you create, you read, you update, and you destroy. The vast majority of applications, in my opinion, are just pretty pictures of JSON.

For Artsy, it’s about our database of artworks. It’s about our gallery relationships, our museums. And it’s about being able to take all of that art and bring it to actual people that buy art. As a part of that process, open-sourcing our apps makes that easier, and at the same time does nothing to risk the core parts of our business.

Open Source versus Non Open Source Assets (38:24)

We pay for our fonts, because to not do that would be stealing. But, we can’t give those fonts away. For our open-source versions of our applications, you get the open-source version of the exact same font. This one’s almost like, the exact same ligatures and stuff. So we created an API compatible fonts as a library, so that both of them would have the exact same API. So, if you were an Artsy employee, you got the closed-source fonts, if you’re not a Artsy employee, you got the open-source fonts.

Conclusion (40:18)

I’m driven by impact. It’s what I choose to do when I wake up in the morning. I think about what impacts the communities I care about, which is generally the iOS one. By making my day-to-day work open-source, I can have an even bigger impact.

We’re all building CRUD apps anyways, so the faster we could build them, the better it would be for all of us.