At the beginning of June, after 19 months of development and over 4,400 commits, we open sourced the entire codebase to Ello's iOS App. 🎉
We believe in being open and transparent about the features we put into the product, putting our users first and respecting their privacy. We are a robust and growing community of artists, designers, musicians, illustrators, photographers, architects, GIF makers - creators, who understand that our process, practice, values and passions can push the world forward in a better direction. As we work together on a daily basis we are always looking for ways to live our values of integrity, honesty and active community involvement.
The iOS app constitutes the largest codebase in the Ello ecosystem right now - at 57,391 lines of Swift, it just barely edges out the 55,911 lines of Ruby in our Rails backend, and it’s almost twice as big as the 29,827 lines of JS in our React webapp. Ever since we made the decision to go Open Source by Default earlier this year, getting this app out from behind the curtain has been a major goal. We now have over 15 open source repositories on github.
Part of that desire to open source the Ello iOS app came from the excellent example set by our friends at Artsy - much of the open by default approach that we have adopted is heavily inspired by the approach that @orta and @ashfurrow have taken at Artsy.
Now that it’s done, we wanted to talk a little bit about the mechanics of getting it opened up, and what’s happened since the big day.
Private to Public
The first issue we had to address was perhaps the most familiar - cleaning the repository history of sensitive information. While we’ve gotten fairly comfortable with using the excellent BFG tool, two aspects of this project made it somewhat unique. One issue was simply the size and scale of the repository and its history - quite frankly, it is orders of magnitude larger and has had many more developers working in it than any other codebase we’ve open sourced to date. Luckily we’ve been consistent about isolating the locations within the repo where secrets get stored, so @colinta was able to come up with a comprehensive list of “secret” strings and files that needed to be removed from history. A few files were more straightforward to remove from the history entirely and re-add as a last step before opening the repository - things like our
xcodeproj file, for example, we were not confident in our ability to examine and redact even with BFG’s help. The second issue revolved more around the actual logistics of performing the rewrite in the middle of a very active codebase - it would be difficult for us to have a hard stop on all iOS-related work for an extended period of time just for the sake of having a stable repository to rewrite! To get around this, we performed that actual rewrite and repository changeover immediately following the stable 1.8.0 release to the App Store. Given the way Apple’s review cycles work, we tend to have a very structured release cadence, which means that there’s a bit of a quiet period after each successful release before we start working on whatever is going into the next release. The actual history rewrite involved three steps - cleaning the history with BFG, pushing the clean history to a new Github repository, and archiving the old private repository. We knew from several previous experiences that once PRs have been merged containing sensitive commits, cleaning them is impossible as Github will always hold onto the original SHAs. We have a lot of relevant information in our PR history that we couldn’t make public but didn’t want to lose, so we opted to simply archive the old private repository for reference purposes. The final step in all of this was getting each team member to remove any working copies they had pointing to the old repository and re-clone them from the new one. Ultimately, we only needed to freeze the codebase for a few minutes while running through these steps, minimizing disruption for the team - a major win!
The second issue involved certain components of the app that must remain private for security or licensing reasons. For us, that primarily meant two things - the SSL certificates that we use for pinning, and the licensed fonts used to render text within the app. While we could not make either one public, we wanted to ensure that anyone who wanted to clone down the Ello app and build it themselves would be able to do so. Luckily, we were able to use a private/public CocoaPod approach pioneered by @orta at Artsy, essentially defining an interface for these components that could be satisfied either via proprietary CocoaPods for internal builds or via open source equivalents for developers outside of Ello. You can see the fruits of these efforts in the Ello-OSS-UI-Fonts and Ello-OSS-SSL-Certs projects on Github.
We’re still working on a third issue. In order for the app to be useful, it’s necessary to connect it to a working implementation of the Ello API. While our ultimate goal is to open up a full public API, we’re not quite there yet. Our stopgap solution (again inspired by Artsy) is to stand up a sandbox environment that we don’t mind giving out credentials to. That way, OSS contributors can still test the functional parts of the API, but it stops short of us needing to rush a public API into production, which we definitely appreciate!
In addition to open sourcing the app we have decided to work in the open as well. We do not work out of view in a separate private repository. The process Ello employees follow when adding code to the project is the same as folks outside of Ello. Clone the project, create a topic branch, make changes, submit a pull request back into master and repeat. @colinta, @steam (or another Ello engineer) review and discuss the additions. When CI passes and the change is fit to be included in master we merge it in and the changes end up in a build in the app store. We’ve already had 6 non-Ello folks submit pull requests since we’ve open sourced it. Many thanks @BalestraPatrick, @BasThomas, @orta, @ReadmeCritic, @swiftcodex and @valeriyvan!
We’ve benefitted so much from reviewing other open source on github and are excited to be able to contribute back to the community with our own open source initiatives. We’d love your feedback. Pull requests, issues and comments are much appreciated.
Sean Dougherty & Jay Zeschin
@sean & @jayzes