Is coding a blogging tool still worth the effort in 2013?
I’ve been asking myself the question almost every time I’ve pushed some code on Publify for the past 4 years. Wordpress has for long consumed all the room for an open source publishing tool, from available users to contributors, now powering a tremendous 19.3% of the whole Web. Blogging has been left for dead since micro blogging started to disrupt our writing habits, lowering our attention span to 140 characters and the relevancy lifespan of any statement to a few hours. And Tumblr like silos took the remaining space left for the ones whose blogging activity was mostly about relaying what other people wrote about.
8 years ago, writing your own blogware was part of every Web oriented language and framework tutorial. Ruby On Rails legendary screencast wow effect heavily relied on the idea that you could have a working blog in 10 minutes. This was indeed a lie, but it worked.
I started my first blogging engine in late 2002 before I switched to a very young Wordpress in 2003. My love story with the most well known Web publishing content software last for 3 years before I took over the almost abandoned Rails based Typo Publify I’m still maintaining today with a bunch of cool kids.
Working on Publify taught me a lot.
I learnt how to follow a product over the year with a volatile team, dealing with a huge technical debt and so much legacy code you sometimes want to start over.
I learnt everything you should not do when managing a product. The first thing being not cloning what you believe is your competitor when you’re neither playing at the same level nor targeting the same market. We tried to make Publify a generalist publishing too designed for everybody while our users were mostly developers and system administrators.
I learnt that leading an open source project requires lots of managing skills. When you’re working with people who spend their spare time helping you for free, you have to listen to them and take care of them even more than your own employees or they’ll loose their motivation. This is even more true when they deal with “secondary” things like translation, packaging or side projects such as maintaining themes and plugins.
As years were passing, I slowly lost my motivation into coding a blogware. I pushed less code, left issues open without even replying to them, and releases became scarce. The only reason I would still fix a bug or add a feature was for my own needs, which is the reason why I started contributing to the project after all.
But to be honest, without any major feature and too many competitors, Publify was exactly in the state it was when I started using it.
For about one year, I’ve been thinking about moving my blog to something else. Database less static content generators such as Jekyll have a quite active community I could even connect to if I wanted. I even though moving back to Wordpress, if it didn’t imply to install PHP on my server.
Until Tantek started to live tweet the Indie Web Camp 2013, POSSE and opened some brand new perspective to both Publify and myself.
I’ve always been concerned about both privacy and data ownership. I started hosting my sites back in 1998, and implied myself into self hosting the year after. When I moved to Paris in 2001, I had up to 9 machines hosting various services on even more flavors of UNIX on my DSL line. It was fun time until I got married and had my wife decide that I had to drop all the noisy machines, specially the really loud Ultra 30 with its arrays of SCSI disks. I then started to rent a single server elsewhere.
My first day as a blogger, I started to code my own tool, as I could not imagine being hosted by someone else. As many startups began to offer hosted services — we now call them SAAS — I started to trust them and use more and more cool stuff, in exchange of my data. Some of them are still alive, but most of them died, losing my data without any real consequence: I still had all my important stuff at home.
Until that day Google announced they would close Google Reader by July the 1st 2013. For years, Reader had been the only feed reader really worth using as an end user, and even though I didn’t read that much RSS anymore, the closing was a blast. Google closing Reader was as chocking as a super hero dying at the end of the movie without any chance to see him come back again. I lost faith into Google being able to sustain not bankable services and lost faith into the whole SAAS model, even though I’m working for a SAAS company.
And then I heard about POSSE. Publish Own Site, Syndicate Elsewhere The POS had been natural to me for 15 years, the Syndicate Elsewhere part was brand new to me. Instead of giving my data to silos I’d use for themselves, it was clear to me that I would better use them as a way to syndicate the data I own.
In a POSSE world, I publish a short status on my Web site before it’s sent to Twitter with a short link back to my original content; I add a photo to my gallery before it’s pushed on Flickr, 500px or Facebook, one more time with a link back to the original content, my content.
I’ve already heard that I was breaking a moral contract
I spent most of my summer vacation thinking about that POSSE thing. In many ways, it was the missing link in my online presence. It was a partial but acceptable solution to the schizophrenia that made me manage my email, Web site and Jabber server on the one hand, and happily give most of my online published content to silos I had no control over on the other hand.
Implementation was the bugging part. I’ve enough experience in product design to know how hard it is to build something that does one thing very well. So imagine how hard it would be to build the perfect self hosted all in one blogging engine, Twitter client, hyper connected photo gallery… you name it. In the past, I used to schedule my tweets using a simple text file as a database and a crontab that would fire every 5 minute. It was more than enough until Buffer came with all its awesomeness. End of story.
I read code, in PHP, Python and Ruby. I actually read more code than I did for years. I studied other people implementation, to find the correct way to go. I read code at home, and I read code on the beach. I found many interesting projects, but most of them were built for their own purpose and were hard to extend / integrate into an existing one.
The first thing I wanted to do was to publish short messages on my site, then push them on Twitter with a short link back. I needed a cool Web UI because I would not be able to use any CLI from my iPhone, which I use a lot to tweet. I didn’t want a PHP tool — for religious reasons — either, nor would I use yet another tool that would die unmaintained in a few months.
I indeed had Publify, but Publify was a dying blogging tool and… oh wait, aren’t blogging tools supposed to be just content publishing software?
I quickly sent a message to my co maintainers suggesting we could go into that POSSE direction, and they happily accepted both from a philosophical point of view and because this would get Publify out of the blogging engine only radar.
Publify is far from being the best blogware around. To be honest, it kinda sucks on some points, mostly because none of us are frontend developers, so we left all the Javascript part aside and heavily relied on plain old Bootstrap. But Publify was designed to publish content, and it actually does it pretty well.
I started hacking Publify during the kids nap, giving it major new feature for the first time in years. I was excited like the first time I pushed a patch to an open source project.
Adding short statuses, I had 2 things in mind.
- It had to be quick. Either I would be able to release something within 2 hours without torturing the application core and break the existing, or it would be useless.
- It had to integrate well with the existing. Publify was for too long considered as a bloatware, and I wanted to stay as fast as it currently is, and not too memory greedy.
It went blazingly fast. By the time the kids would awaken, I was able to store short statuses, push them to Twitter and display them on my blog page without even touching the SQL schema. It felt awesome.
Extending Publify Content model to publish short statuses took me less than 10 minutes and so little code I shouldn’t mention it. The URL shortener had been around for ages, so I just had to reuse existing feature Adding basic push to Twitter took 20 more minutes, blame it on Twitter API gem. Everything else was adding Web UI instead of using Rails console.
One more commit and Publify was listed amongst the Indie Web Camp projects, starting a new life.
Later on, I would make Publify statuses to be stateful so I could use publishing workflow (and publish in the future). It took me litterally a few seconds to have it inherit from the Content model state machine.
Then, I added link auto discovery for Twitter accounts and hashtags. Once again, I didn’t have to change any of the application internals. Publify has a system of chained pre and post processor text filters. This is used to turn Markdown syntax into HTML, or transform some built in macros into nicely formated, syntax highlighted code block. I wrote a 10 lines of code filter that turns #hastags and @mention into links.
There was more.
I’m doing lot of photography, so I need a photo gallery to publish my photos on Flickr, 500px or even Instagram, using the unofficial API (RIP). Like webmails, photo galleries are the worst thing one can start coding because it takes lots of time to make them actually usable.
I created a local branch, and once again, started to extend Publify model without adding a single SQL table column. I wanted albums, tags, descriptions, comments, exif metadata display and push to Flickr.
90% of the code was already existing within Publify. All I had to do was to link the brick together.
- The content model (yeah the same we already use for articles, pages and statuses) would be reused for photos. What you just need is to add a Photo class that inherits from it.
- The photo would be handled by our Resource model that already manages uploading, various thumbnail sizes etc… and can be linked to a content.
- Albums would use the category model.
- Flickr API is already used in our publify:flickr plugin.
- For the exif, a simple helper will do the trick.
What’s next? Actually many things, without adding too much code: posting on Facebook or any other platform, a hCalendar / iCal / vCal compatible calendar with Google Calendar integration… There’s almost no limits as long as the silo on the other side offers a publishing API. But Indie Web is not only about POSSE: there are many other interesting projects that need more implementation: h-entry for content syndication, indie auth for users authentication, Web mention for Indie Web to Indie Web sites communication…
When I was not coding, I was thinking about open source content publishing tools and Wordpress hyper domination. Even though you can do all the above with some Wordpress plugins, I’m pretty sure POSSE gives a second chance to small content publishing projects.
Small content publishing tools going POSSE may attract hackers because they’re easier to hack. Small projects also make it easier to get contributions accepted. Starting small with a coder / hacker friendly platform (Jesus I hate this word) may help POSSE spread around like early Wordpress helped self hosted blogging spread around.
When I went back to my office, I had the answer to my previous question: Is coding a blogging tool still worth the effort in 2013? Indeed it is, if you don’t stick to blogging.
Original article published on Is coding a blogging engine still worth the effort in 2013? and other thoughts about content publishing tools
