The two main open source LJ clients on Linux are LogJam and Drivel. Both use GTK, which means they have a graphical user interface. And both are dead.
LogJam’s latest release was three years ago (minus two weeks). Drivel’s latest release was two and a half years ago. Both exhibit almost no activity in their source repositories after that time. They’re not actively maintained, and no-one took up the baton after the project originator lost interest. For LogJam, there’s still a community where people post patches, but if you want your copy all patched up, you’ll have to manually apply all the patches yourself — there’s no way for new or improved code to flow back into the source repository. For Drivel, there’s not even that.
Which means the ‘state of the art’ for LJ clients on Linux is behind the times, so to say. And I have some things I want in an LJ client that neither of those does. Sure, I added tag support to the code of the stable release of Drivel (which I got 0 reactions on, so far), but there’s more I want to do. But if I try to resurrect Drivel, I’ll be facing an uphill battle, because there is no current maintainer who will vouch for the quality of my code, and it’s not like I’m already an active Gnome contributor. And I’d inherit a huge buglist which also includes things for Blogger and WordPress blogs — for which I have no interest.
I could, of course, create a fork of Drivel: remove all the non-LJ stuff and continue on with that. I would inherit some bugs that I would need to fix, some of which I don’t even know how to parse the bug description… The advantage would be that there’s already lots of code available.
Alternatively, I could take only part of the code, and use that. But the coding quality of Drivel (which I have seen the most of) is just not very good. To add tag support for LiveJournal, I had to also modify a certain function call in all the other blogging protocols. There’s no clean API implemented to communicate with LJ, so even a small change in the interface works through to the deepest code levels. Let’s just say that that’s not what I learned in my programming classes — and it makes me less than enthusiastic to run with that code. I would also inherit some ‘bugs’ that Drivel uses the wrong version of a certain library and stuff like that. I’d have to fix that too.
Still alternatively, I could create my own project. First implement a clean and well-documented module (in Python, of course) to communicate with LJ and Scrapbook. Then build a GTK client on top of that… But that would mean a lot of work — work that has already been done in the other clients…