Scott, as someone who’s studied evolutionary biology, I know that specialists in particular areas are almost always exponentially better at what they do than non-specialists. This doesn’t mean that we don’t need alternate projects or new ideas which may result in new “Cambrian explosions,” and even better products.
I also feel that one needs the right tool for the right job. While I like WordPress for many things, it’s not always the best thing to solve the problem. In some cases Drupal or even lowly Wix may be the best solution. The key is to find the right balance of time, knowledge, capability and other variables to find the optimal solution for the moment, while maintaining the ability to change in the future if necessary. By a similar analogy there are hundreds of programming languages and all have their pros and cons. Often the one you know is better than nothing, but if you heard about one that did everything better and faster, it would be a shame not to check it out.
This said, I often prefer to go with specialist software, though I do usually have a few requirements which overlap or align with Indieweb principles, including, but not limited to:
- It should be open, so I can modify/change/share it with others
- I should be able to own all the related/resultant data
- I should be able to self-host it (if I want)
- It should fit into my workflow and solve a problem I have while not creating too many new problems
In this case, I suspect that Wallabag is far better than anything I might have time to build and maintain myself. If there are bits of functionality that are missing, I can potentially request them or build/add them myself and contribute back to the larger good.
Naturally I do also worry about usability and maintenance as well, so if the general workflow and overhead doesn’t dovetail in with my other use cases, all bets may be off. If large pieces of my data, functionality, and workflow are housed in WordPress, for example, and something like this isn’t easily integrateable or very difficult to keep updated and maintain, then I’ll pass and look for (or build) a different solution. (Not every tool is right for just any job.) On larger projects like this, there’s also the happy serendipity that they’re big enough that WordPress (Drupal, Jekyll, other) developers can better shoehorn the functionality in to a bigger project or create a simple API thereby making the whole more valuable than the sum of the parts.
In this particular situation, it appears to be a 1-1 replacement for a closed silo version of something I’ve been using regularly, but which provides more of the benefits above than the silo does, so it seems like a no-brainer to switch.
To reply to this comment preferably do so on the original at: