Why I gave up on Snipsnap
It can be summed up as a lack of future, cost to host and missing functionality.
The first reason obviously was that the developers walked away from the code. Those looking to rescue the code failed to build a community around the codebase; obviously I didn’t help but the actual community they inherited was both small and mainly user based, their main contributions were use cases and thus RFEs. This lack of future and lack of support was a serious problem for me since I do not do Java. It became clear to me that WordPress had won this particular marketing war and that it was easy for low and medium skilled users, and had gained a massive community with huge extensibility.
The fact that it is java/daemon based means that you need quite extensive admin privileges (including the rights to install Java if not in place, and I had come to the view that I needed Sun’s Java 1.5 to make it run). The JRE became scarce in hosted environments ignored by both those that wanted to be up to date, and by those for whom Java is not part of a Linux core build. Such self-administered environments are expensive. Once I had to move it off my private server, which was a foolish solution in the UK; it’s the wrong side of an ADSL link, I ran it on Amazon. Snipsnap itself would have fitted into a ‘tiny’ system but I also needed a burst in RAM to support the backups which added cost to the AWS solution; you can’t burst RAM, only turn it instances on and off. I’d have needed to develop a client server solution, which wasn’t beyond me, but I didn’t find the time, and it wouldn’t have been free, but probably cheaper than what I did.
It just got to a point that the functionality of snipsnap and my needs diverged. The most frustrating is that the blog articles had real names consisting of the ordinal within date. This made it impossible to determine what a search was returning since it consisted of a lists of articles called ‘1’ & ‘2’ and occasionally ‘3’. The blog browsing was also insane, you could start from a date and move forward or back an article at a time or use the calendar widget to find the next set of articles, or start from today and go back 10 at time. This seemed a worse problem due to the article naming implementation. It became very hard to find previously published content. The tagging solution was also hard to use. Finally despite having RDF baked in at the start, the only RSS feed was on the blog, and that only consisted of the last 10 entries; this limit was hard coded. I had come to the point where my requirements needed extensibility and this required Java or Groovy and these were steps too far.
Which of these criteria forced my hand? Who knows? Maybe it’s just that WordPress is much better, although there are things about snipsnap I really liked.
The snipsnap community site, http://www.snipsnap.org, was rescued by Leo from a Frauenhofer spring clean and is now hosted by him.