This blog just passed the 7 year mark from our initial "Hello World" post. We've always built and hosted our
own blog, initially using OctoPress but eventually migrating to just plain old Jekyll.
Artsy uses 3 separate editorial platforms now, we built our own for Artsy Magazine, use Medium for our Life
at Artsy blog and Jekyll for the engineering blog. There was a healthy debate about whether we would migrate
to one, or two systems, but I had pretty strong opinions on migrating the engineering blog to Medium and nipped
that in the bud pretty quickly.
With Signal vs Noise being a high profile of a example of migrating to Medium and back again, I thought it's
worth taking the time to examine our reasoning for doing it ourselves.
In programming, the process of creation rely on you depending on others. That ranges from operating systems, to
system dependencies like SQLite or VSCode to app level dependencies from CocoaPods/Node/Whatever. For this blog,
that we rely on GitHub's static site hosting, RubyGems + Bundler and Jekyll. Luckily for us, there are powerful
incentives for those projects to continue long into the future.
That's not even too much of a worry either:
If GitHub pages stop being a priority, we can switch Netlify or plain S3 in an hour (we already ship to netlify
for post draft previews)
If RubyGems or Jekyll goes down, we can switch to another static site builder in another language,
Because the code is some markdown, some HTML and CSS - that's all portable to whatever we want.
We call the process of making sure you understand and vet the full stack your dependencies "Owning your
Dependencies", and in this case we're sitting on a long-lived and mature set of dependencies.
To switch from our mature set of dependencies to a start-up which still hasn't found out how it can make money
greatly increases the long-term risks.
Medium is totally incentivized to get your post in front of as many people as possible, and that's awesome.
However, as a business they've not found a way to be profitable, and have taken a lot of VC cash which
eventually needs to be paid back. (Artsy has too, so yeah, that's kinda hypocritical, but we're not aiming to
disrupt & replace the existing "writing online" market we're augmenting the existing Art Industry.)
When newspapers like Forbes and Bloomberg are worried about the Medium business model, then
it doesn't look great for the longevity of your companies blog. For example, today Medium removed the developer
API for your posts. Folks who used Medium to make money have found themselves surprised time
and time again when that changes.
It's important to note here that I think a lot of this churn is reasonable, they are a start-up and that is
literally what start-ups do. Start-ups iterate through business plan ideas until they find one that scales in a way
that they want and that process takes time. It's when that ambiguity about what a company does or doesn't do with
your writing which makes it a dependency which doesn't pay its weight.
I consider our blog, and the rest of the site, to be the canonical representation of the Artsy Engineering team
online. We've carefully grown an Artsy Engineering aesthetic around it.
In contrast, had we chosen to host on Medium, we'd get a few templates and a highlight color. For example, check
out: AirBnB, Harrys,
Pintrest, Vimeo or
Not memorable at all, because you can't really work with the design constraints to do anything creative other than
a banner image and a color.
These constrains become worse on a post page, where you completely lose any sense of connection with the company,
and the team the moment someone scrolls an inch until the footer. Your team's writing becomes just "a medium post"
at that point. You've got limited options for attaching images, and no ability to use HTML/JS to showcase
problemsinteractively or explore new post styles.
These aren't blockers in any way, most of our posts don't do that - but the constraints mean you will never think
to try and explain something outside of those constraints.
Then at the bottom of your post, readers are redirected to other posts from other teams. For example, when I opened
a post on Vimeo's announcement of Psalm v3 (a cool looking PHP dev tool), there were three recommended
posts: one was about missiles being fired in Syria, another was a beginners guide to PHP and then a third was how
to set up Docker to work with a PHP framework. They're not that related, maybe they all have the keyword of PHP
behind the scenes?
Writing takes a lot of time, and provides so much value. It should be presented as quality worthy of art.
By using to a generic platform for your writing, you're trading that simplicity for building your team's online
Breaking the Sandbox
We've grown to need to showcase quite a few different types of posts:
Small posts that with only a few paragraphs
Long-form posts that take forever to read
Long-form interview style posts for many contributors
Sequential posts, in the form of a series
YouTube embed posts
None of these need to be treated the same, and since we created the blog, we've added:
When we've wanted to add a new feature to the blog to fit a particular post, we added the feature. This gave us the
chance to not constrain ourselves in ideas. For example, we've explored building a podcast into our blog
treating it as a first class feature in ways that no-one would ever build if it was a platform. Or we're interested
in making a way to highlight useful links for the
All of those features were made by people whose background was iOS development, which gave us the chance to expand
the horizons of our engineers knowledge.
Blog as Code
Because our blog posts are markdown in a GitHub repo, we don't treat a review for a blog post any
different than a normal pull request for code. It means our company Peril rules will run, and all of
engineering has the ability to contribute to the review process.
Having a static site in a GitHub repo means we don't have to special case our writing in comparison to every-day
Call to Action
Using Medium is a very reasonable call if you are just trying to get some writing out and online as fast as
possible. If you want to be scrappy and announce something - do it. If you want to do something more serious
though, you should really consider owning your engineering blog and identity. Giving that away to Medium in
exchange for hosting your content and getting more eyeballs isn't a great trade.
There aren't many shortcuts for getting folks to visit your blog, and relying on Mediums' recommendations or SEO
isn't a good path compared to say Twitter adverts or just writing interesting stuff and letting folks know via a
If self-hosting is an issue, Medium is not the only payer in eco-system, Wordpress's company
Automattic has been profitable for years and hosts all sorts of really big blogs. It's not going anywhere,
and you have the ability to customize it to your style and use a whole massive marketplace of plugins (free and
paid for) - it's a really great choice.
However, it's really worth noting how low the barrier to entry it is now to create a blog using a static site
Jekyll - Ruby, the default for GitHub pages and lowest barrier to entry.
gem install jekyll bundler
jekyll new myblog
bundle exec jekyll serve
Gatsby - JS, the project we regularly consider moving our blog to. JS folks have such a great focus on
developer experience, and the abstraction of having an in-direction layer for your content via an internal
GraphQL API for your static site is a very, very smart abstraction which will take them a long way.
npx gatsby new myblog https://github.com/gatsbyjs/gatsby-starter-blog
Hugo - Go, looks pretty reasonable if you have strong opinions against the others somehow
brew install hugo
hugo new site myblog
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke
echo'theme = "ananke"' >> config.toml
hugo new posts/my-first-post.md
hugo server -D
All of these come with some sort of theme or templating support so getting started could probably take about an
hour to get a static site up and running using a host like GitHub Pages, Netlify or Now.
All three of these you can set up automatic hosting from GitHub in about 10-15m.