Category: Open Source

  • That Opening Keynote at WCUS 2024

    Ah WordCamp! The event opened on a Thursday and by Friday late afternoon Matt Mullenweg had driven a wedge into the WordPress community that still remains to be sorted out.

    Eventually, I got past the drama aspect of the event and started thinking about the content, and one thing that stuck in my mind was the opening keynote. Joseph Jacks, the founder and general partner of a venture capital group called OSS Capital talked about the difference between what he termed “closed-core” and “open-core” business models.

    I just went back and viewed the video of the talk and I think there’s a lot more to be said about “open core” and how it does and doesn’t work. We’ll get to that.

    The Bittensor bit

    What I also noticed was that there are a couple interesting bits thrown in almost as an afterthought at the end, when Jacks, obviously enthused about the project, took a few moments to talk through what the Bittensor project is.

    He was talking about the way that basing a project on a blockchain can allow a community to enforce that everything that happens on the chain is open source.

    Who’s source is open?

    Jacks said: “It’s also related to something that Matt was blogging about maybe yesterday or the day before which was… we have this kind of phenomenon in the industry where people are trying to say that their models are open source, and they’re really not open source.”

    His example for this was Facebook’s Llama, but it’s interesting as background for the way Mullenweg was thinking about the way that the loose couplings between open source projects and companies that exist because those open source projects provide a platform.

    Couple me loosely

    I think the issue that the WordPress community is concerned about at present is how that “loose coupling” is defined and managed. There’s been a sort of “loose consensus” about what’s acceptable for, say, plugin businesses, but clearly rather different understandings of acceptability have developed.

    It’s also interesting that Mullenweg, on the cusp of attacking WPEngine in no small part because it was now owned by an equity firm that he accused of taking value from the project and community without giving anything back, picked a lead-off speaker who invests in companies that build atop an open-source ecosystem.

    Mullenweg is clearly trying to reshape and tune the loose coupling model–and much of the pushback from a frustrated WordPress community accused him of hypocrisy regarding this precisely. These complaints grew louder, of course, when Mullenweg subsequently took far more active control over the WordPress.org site and its plugin repository. The community understood the .org site to be a community asset; legally it belonged to Matt.

    The question of who governs

    I’m not sure how the rift between Matt and a substantial fraction of the WordPress ecosystem will be resolved, but for me it raises the issue of how open-source projects should be governed.

    Funnily, I had somehow forgotten the tacked-on part of that opening keynote. I was excited to see how there already exists a fairly large open-source project underway that has a radically different governance model. Because what controls activities and decisions in Bittensor is rules built into the blockchain and the possession of the chain’s currency token, the tao.

    “What it also does,” Jacks said, “is it allows the user to basically actively participate in the ownership and governance of the model, so you don’t have a single company controlling the AI that gets produced.”

  • A Modest Licensing Proposal

    Hey OSS folk: we need to start thinking outside the conventional GPL licensing box. We need a rational ecosystem for paid plugins and themes (in WordPress) and analogous capabilities on other OSS platforms. I think we can create a much better arrangement for all involved.

    I envision a licensing system that allows participation in an overarching governance system. If you want to take part in a project that uses this system and use its associated .org repositories and so on, you’d get a license for any internet-facing deployment. You’d pay a small licensing fee, let’s say five bucks a year, calibrated downward as needed to take differences in international buying power into account. Five bucks gets you a vote. For some number of sites, let’s say two dozen, a single five buck payment would get it done, but for big players, measured by sensible metrics but I’m not sure which, more cash would be involved. And bigger players would have more (but not infinitely more) votes.

    It’s a board!

    The main task for voters would be selecting a three or five-person board, but for really large issues (classic editor or blocks, to take an example from the past), direct votes might be called.

    In a greenfield new project, I’d propose a mechanism where the project creator got a big block of votes, such that they could be benevolent dictator for a while (I think there’s value in this, early on—clarity of vision and so on), but as popularity of the project grew and more people acquired licenses, the control would naturally and gradually shift over to the community as a whole.

    Who runs the thing that run the things?

    Who would run this? I imagine a few pillars of the OSS world forming some legal entity that maintained the license sales and voting procedures. It would be possible, maybe even preferable, to run this on a purpose-built blockchain, but it’s hardly a requirement, as the community would just need to trust whoever was running it.

    Now then, what about the money? All the things you might expect the money could be used for would be what the money was indeed used for, at the discretion of the elected board. And we’re talking about a substantial amount of money, the kind of money that drives early marketing campaigns, but clearly also full-on development in the form of sponsorship for core developers and, well, other things like a project’s training videos on YouTube…all the things.

    Not GPL

    To make it work, we’d need to step away from GPL licensing. That sounds severe and even ill-advised, but just because something isn’t running under a GPL or MIT license doesn’t in the least mean it can’t be open source.

    With a non-GPL license, we could have the benefits of open source, but create ways for companies writing plugins and the like genuinely to keep control over how their code was used. The code could remain open, or mostly open, but no one would be in a position to simply take code and sell it as their own (something GPL expressly allows). If the takeover of ACF as SCF didn’t feel right to you, this is how to fix the rules that make it possible.

    If we went this route, selling licenses for use of the governance services of new OSS projects, we could deal with problems such as though currently creating havoc in the WordPress community in a straight-up fashion. Under this kind of arrangement, Matt Mullenweg would have migrated out of a BDFL role years ago. We can’t undo the WordPress GPL license (if we even wanted to), but we could avoid wasting our time wringing our hands and making squeally noises. That’s right: squeally noises.

  • Imagining a WordPress Greenfield

    Just suppose, just for a moment, that you and I were tasked with creating something every bit as wonderful as the wonderful parts of WordPress, but starting with a (mostly) blank slate.

    It’s the plugins

    Well, one thing we have to get out of the way right away is what to do about the huge number of useful plugins that are the particular strength of the WordPress platform. Do we want to walk away from the ecommerce plugins, the learning management kits, the membership tools?

    If we want our cake and the eating of it, we’ll have to reckon with the immutable fact that all of that stuff is written in PHP and it all runs on the server. There are no lambda plugins. There are no client-side plugins.

    And it’s PHP. Some folks argue that PHP is antiquated, but I think that’s about fashion more than sense. It’s a fairly sophisticated language, performant, all that.

    All JavaScript?

    But as long as we’re declaring a fresh start, you’ve got to reckon with the hard truth that PHP doesn’t run on clients. Essentially, JavaScript is the only choice in that regard. And if you’re running JavaScript on the client, it makes life a lot easier to be running the same language up on the server.

    If we change gears and use Node.js on the server, then the challenge is finding some way to continue using existing plugins.

    I’ve turned this over and over in my mind. On the one hand, it seems pretty likely that a WordPress-specific translator could be built to turn plugins in Node.js plugins. If we do that, though, then we have to support all the action and filter hooks.

    So, on the other hand, maybe what we want is to make it easy for plugin providers to rewrite their code bases anew. Assuming an approach that was generally similar to WordPress’s approach, developers would have a pretty good sense of how they should approach various tasks.

    For example, you’d probably want get_current_user() to be getCurrentUser() and you’d probably want it to return a user ID. And you’d want to have roles and the roles would be collections of capabilities.

    Post much?

    That’s easy enough (maybe), but do we really want to commit to preserving the concept of everything being a post? We’d have to give that one some thought, but maybe the easiest way forward is to stick with posts and pages and custom posts and such.

    There’s a lot of complexity in core, though, the inevitable result of organic growth over twenty years, and maybe we just carefully sort through and discard a lot of the baggage that still works but probably was never such a great idea. And maybe we tack on a new concept or two, like having a React-like routing system be the default.

    But what we want is for WooCommerce defectors to have a straightforward sense of how to write a new and significantly more straightforward ecommerce solution. NewCommerce?

    Astro adoption?

    There’s another question to consider: given the complexity of building this sort of system, possibly the best way forward is to start with an existing system and then add on whatever stuff is needed to support critical plugin rewrites.

    This is the line of thought that has landed me at the front door of the Astro community. If you’re unfamiliar with Astro, it does content sites, like our friend WordPress. And it’s server centric, like WordPress. But it’s also vastly newer and thus not yet covered in all those rustic barnacles.

    It appears to have themes. It doesn’t, as far as I can tell, have plugins in the sense one has them in WordPress, but it seems at least conceivable that an interface to a plugin system could be created. It doesn’t have an in-built editor, but again, that seems like something that could be whipped up. Or, in a funny little twist, I feel pretty darned confident that the WordPress block editor could be pressed into service.

    So I’m going to explore Astro. Not because I’m so convinced that the current troubles in the WordPress world are going to lead to WordPress falling apart, but because I think we all need to think about hedging our bets. And, frankly, because there may be better options out there in the blog-and-content-creation universe.

    So, more to come on this. One clear takeaway, though, is that WordPress has built up an enormous and enormously useful ecosystem and feature set over the years. Leaving would be painful.