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.
Dependencies
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.
#branding
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 Lyft’s pages.
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 problems interactively 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 presence.
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
- Announcements
- Guest Posts
None of these need to be treated the same, and since we created the blog, we’ve added:
- Category pages - GraphQL
- Author pages - mine
- Site series - React Native at Artsy
- 4 separate post layouts
- Multi-author posts - Pair Programming
- GitHub Issue Powered Comments
- Real-time search on our static pages
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 work.
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 mailing list.
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 generator:
- Jekyll - Ruby, the default for GitHub pages and lowest barrier to entry.
gem install jekyll bundler
jekyll new myblog
cd 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
cd myblog
yarn dev
- Hugo - Go, looks pretty reasonable if you have strong opinions against the others somehow
brew install hugo
hugo new site myblog
cd myblog
git init
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.