It won't be easy, but we have a plan — and more importantly, a business case — for removing proprietary dependencies and supporting self-hosting.
I wrote a thing for work about our commitment to eventually supporting self-hosting for PubPub (the platform this blog is published on). People sometimes ask us for it, and it’s certainly mission aligned and something we’d like to do. But it’s difficult, because as the piece notes, the desire to be “fully self-hostable” often conflicts with our desire to serve our core users, who typically can’t or don’t want to self-host.
We’ve been having a lot of conversations internally over the last year or so about how to square this circle, and I think we’ve come up with a pretty good solution: bake it right into our sustainability plans. Because we chose a membership and services model, rather than a pay-for-use model, there’s no incompatibility at all between offering hosted, managed, and self-hosted versions of PubPub. People can choose to become members or contract with us for services no matter how they use PubPub, and because many people do want to self-host, supporting it will likely only increase our membership.
So that feels good, and has led to a lot of technical discussion about how to get there, too, that the post gets into in some detail. It won’t be easy, but we know how to do it, and conveniently, most of the work required is already planned for the hosted version.
The behind-the-scenes here, which hopefully I won’t get into trouble for sharing because no one reads this, is that there seems to have been a bit of a whisper campaign going on in some circles of our little open publishing technology niche claiming that KFG is not really committed to “openness.” That word is so broad, and has so many different meanings in different contexts, that I suspect some of these critiques, if not leveled in bad faith, at least willfully trade on the word’s imprecision to conflate open-source with open publishing/access. No doubt this convenient weaponization serves the open publishing ecosystem’s incumbents and gatekeepers well, helping them steer resources to projects that meet the latest openness threshold one must clear to be in the club. But it’s not particularly helpful for advancing the open publishing movement.
Like many other shibboleths our industry has embraced, openness has become an end in and of itself, when it should be understood as a design decision en route to what we really want: an effective, equitable, and sustainable publishing ecosystem.1 Much of the time, openness is the right design decision. But as we’ve learned from the surveillance publishing industry’s ready embrace of open access, it’s no guarantee of progress. In the open-source world, as my piece details, over-commitment to openness over usability, accessibility, and sustainability often leads to underserved communities, unusable code, abandoned projects, or unexpected pivots that leave erstwhile users with no recourse. And in community spaces, as we know all too well from the disastrous societal effects of social media platforms, too much openness actually prevents functional communities from forming.
As always, our goal is to attempt to strike the fine balance of openness, accessibility, and sustainability. We certainly don’t always get it right, and appreciate being criticized for our mistakes. But we’ll happily continue to brush off the rest of the criticism as the irony it is: gatekeeping “open.”