Though Force wasn't quite Open Source by Default, it represented a really important step for Artsy's OSS
perspective but was not the end goal. We were opening our source, but not opening our process.
This month both Force, the desktop version of Artsy.net and Microgravity, the
mobile version - moved to being built entirely in the open. Read on to find out how.
Over the course of the last month, I've sat on and off with Charles "Cab" Broskoski, and figured out what it
would take to migrate Force to work in the public. Previous to this, work happened on a private repo, and we would
push that code to the public.
We scoped out what it would require, creating an issue that summarized the work. Then we waited for 2 weeks, to
give people the chance to discuss the idea and to offer examples for why we should delay or not move. Not all
projects should be OSS, and everyone should have a say when it affects them - giving some time let the team speak
their mind. Especially during summer, when people were less active at work.
It had been 9 months since the last commit to the public repo, and so auditing the commits was a matter of
investigating into configuration files, and seeing what's changed since the last public commit.
Next up, we renamed the current force repo to force-private. This was to keep the old issues and PRs around
after we moved to working in the public. With force now available we re-named the already public project.
We then ensured all outstanding PRs were merged or closed, and pushed the commits from force-private to the now
To get back up to speed we needed to set up CI, figuring this out took time.
We got testing up and running in no time. However, Force is deployed via Semaphore CI, and to deploy
we needed to push compiled assets to S3. To pull that off, we needed access to an S3 key, and token.
In our iOS projects, we do not expose environment variables to PRs from forks, so we don't expect
them to pass from external contributors. This is fine, because we have different expectations
for OSS apps vs libraries. We do this to ensure that we don't receive a PR that adds printenv to the CI scripts,
exposing our secret keys.
As we couldn't add the keys to our testing environment, we added them to our heroku environment then took them from
that. Semaphore sets up our heroku environment only during deployment, so in the deployment phase, we can use a
This sets up the environment like we used to have it when force was private.
We needed to move all the team members to using the OSS version of our apps. This is a little bit complicated as
we work from forks. Roop, an engineer on the web team, created a "Force OSS Dance Script" (
sidenote: his site is worth a visit, there's 15 years of interesting maps. )
## RENAME THE OLD REPO# on GitHub# - Go to my fork https://github.com/<username>/force# - Go to Settings tab# - Rename repo to "force-private"# on my local machinemv force force-private
git remote set-url upstream email@example.com:artsy/force-private.git
git remote set-url origin firstname.lastname@example.org:<username>/force-private.git
## FORK AND CLONE THE NEW REPO# back to GitHub# - Go to the new Force repo https://github.com/artsy/force# - Fork it to my account# back to my local machinegit clone email@example.com:<username>/force.git
git remote add upstream firstname.lastname@example.org:artsy/force.git
cp ../force-private/.env ./
cp ../force-private/node_modules ./ # or just 'npm install' again# all good now - both repos on local machine with correct remotes, envs, deps
For Force, all the same commits existed in both repos, so it would be difficult to push secrets to the open repo by
accident. However, individuals did to sync up a new version of their forks.
And that, is how we moved force into OSS by Default. :+1: - We'll cover the issues migration later.
I have a lot of love for Microgravity. It's the web project that made Eigen possible. Once Force had
moved, I started spending time with Craig trying to understand what it would take to open up Microgravity.
It is no surprise to find a lot of overlap, both projects are based on the same foundations: Ezel.js.
We didn't trust the commit history for microgravity, so we nuked it. Same as our native OSS apps.
We came up with a pattern to make it easier for people to migrate issues, we created a migrate GitHub label that
anyone can apply to an issue in a private repo. Then we use Issue Mover for GitHub with some inline
designers to choose ones that are important to them too.
I love that I got to help make these changes, the web team started the process of opening our apps at Artsy, then
the mobile team took the next big step. Now the teams are both in lock-step, and if you work on the front-end at
Artsy - OSS by Default is the way we all work now.