I generally think of retrospection as a healthy exercise; however hurtful it might be for us to deter from the daily, always-on-the-move activities or new initiatives calling for our attention, an analysis is necessary. Thus, we took a short break from the development of the 4th version of our infrastructure to reflect on what we’ve seen on the horizon of WordPress hosting in 2018.
The Idea Probably one of the major shifts in our product development strategy was that we’ve open-sourced the core of our Presslabs platform and named it, plain simple—the Stack. It didn’t take long until we decided to build it using Kubernetes, which got us to the next point. It crystallized our vision and the mission we’ve signed up for in order to achieve it: we’re driving full speed ahead towards democratizing WordPress hosting. Yes, you’ve read that well.
The way I saw the state of managed WordPress hosting one year ago underlines a series of walled-gardens named ‘SaaS’. The larger walled gardens such as WP Engine and Pantheon tend to become the next Wix.com-s, even if you compare them in investment sizes. Why would such a big player open up the way they provide their services and invest in meaningful open-source touching the core of their business? I bet that companies will do this, sooner than later. Presslabs is just one of them.
We believe there needs to be an extension for WordPress so that it reaches major advances in tech. Although the market share of WordPress does not indicate fragility, I believe that lacking a solid wrapper to boost performance, control costs, allow true scalability and ensure and enforce security is what really makes it increasingly fragile.
At Presslabs, we did our best to get there; we’ve invested in this direction more than 15,000 hours of work in 2018 alone. The first step we took on this path was shifting to a new programming language. We’ve distanced ourselves from Python and questioned the value it brings to our future plans, and, after thorough research, the engineering team has concluded to replace it with Golang. The decision has been taken reservedly, but there were certain indisputable arguments in favor of the switch, such as the routine induced by using the same language for the past five years, the desire to learn something new, and, to top it off, the use of Golang as the language of choice for Kubernetes. Another important aspect of this decision-making process is that none of our engineers had previous experience in using Golang, yet it didn’t stop us from doing it. As bold as it was, this decision was actually a firestarter, as we’ve managed to develop a working prototype for our project in less than a year. This is noteworthy to us and the team deserves a huge appreciation from my side.
Conference-Driven Development We were glad to see some curious minds showing interest in our work, too. Attending several national and international WordPress and infrastructure conferences where we could showcase our work helped us gain some traction and receive qualitative feedback. We’ve used this valuable input to adjust our milestones, which we now internally call it conference-driven development flow. We call it like that because it made us commit to three basic principles:
present it like you mean it (hands-on, demo & everything nice) show progress at every event never deliver the same speech twice. WordCamp Vienna 2018 in April has turned out to be a good moment for us to look for and find the right words to present our plans. The number of questions—which was zero, even during the tech track, has made us realize that our approach was faulty. In our talk, we focused on the idea of incorporating the infrastructure in a standard for hosting WordPress. Our expectation was that by finding a name for it, neutral to what we were doing (we thought of hawp.io – High Availability WordPress) and a corresponding website domain, we would encourage the community to jump in and contribute, or at least give it a second glance. We also created a dedicated Google group and personally welcomed the only person who was interested to support our idea. Well, one is better than none for sure.
Calin, our Presslabs CTO has made a demo on how fast the WordPress cluster could be launched and introduced the MySQL Operator. Undoubtedly, the demo met its technical goal, yet the presentation deserved a little bit of polishing, in our opinion. So we didn’t stop there.
We had a second chance of leaving a mark at WordCamp Bucharest, in October, when we’ve been able to revamp our presentation and prepared a supporting landing page, which turned out to be a great method for us to condense our ideas, spread the word and also ask for feedback.
What Went Wrong? There’s a cost opportunity for everything you choose to do or not to. And that includes some of our initiatives related to the Presslabs Stack, too. To start with, despite the visibility and introspection it offered, attending conferences implied a conscious choice to defocus our team for brief periods of time, which has certainly influenced other aspects of our work, too.
Secondly, maintaining open-source projects requires dedication. Just opening projects on GitHub without an assigned maintainer can easily become a burden. There are chances people will use the open code on GitHub as early as alpha versions, which is rewarding in itself, but these people will need assistance for changes that can break setups—this gets even more complicated if you don’t update the documentation to prevent issue flood and long chat-based support sessions.
In a wider perspective, we realized we should concentrate on finding the critical path for releasing a working prototype and avoid doing more things at once, perfect from the beginning. And last, it’s all useless if we don’t take the time to write more often about our deeds and involve the entire team in communicating the progress.
The Power of Feedback We’re extremely grateful for the most valuable feedback and encouragement that came from XWP’s VP, Jonathan Wold, with whom we’ve nurtured a fruitful relationship to this day. We’re also grateful for the feedback we’ve received from Marius Vetrici at WP Riders in terms of shaping our message to suit our target audience’s interests and eventually to reach potential early adopters.
In order to explain the impact of the next conference, we need to dig into a few implementation facts regarding the Stack. As we are building it based on what we consider to be the next universal language for hosting infrastructure, i.e. Kubernetes, the Stack is comprised of a series of operators, out of which some are entirely written and wholeheartedly open-sourced by us. The MySQL operator is built on top of Percona’s server and following the Kubebuilder operator-writing recipe.
Closely following, we’ve introduced the MySQL operator at Percona Live Europe in Frankfurt this November, right in front of a highly demanding audience, including the core contributors to the projects that our code is using, for example, Percona’s XtraDB and the Orchestrator from GitHub.
To be honest, our work has been so far better received outside the WordPress community, as our async replication MySQL operator has received numerous PR’s, reports and mentions. As of version 0.2.3, the operator is in production at some major organizations: Agriterra and Platform9. My impression is not only generated by what I have seen during these conferences but also because we’ve not reached yet the WordPress community as we’d expected to; to put it mildly, none of our speakers’ applications for WordCamp US or EU ever made it among those accepted. Also, our intentions to contribute to the WordPress core has faced dismissal and long delays from core contributors.
Still, there were parts coming from the WordPress ecosystem that made our (and Stack’s!) day: the feedback and full openness we’ve received from the Roots.io team, determining us to incorporate the Roots.io Bedrock into our WordPress Kubernetes operator work.
I’d like to mention that letting our clients and friends know about what we’re working on since the early stage of our work has added up to our motivation and drive to deliver a working prototype. Big thanks for being with us to Mischa at Pixelstart and to Andrei, whose push for deliverables and questions are helping a lot.
What’s next? We’re baking some interesting stuff for the Stack, but as a general idea, the work is still in progress, and we’re currently focusing on the way it can be installed and used. To be more specific, we’re planning to add some more hours to the feature of locally running and developing sites for Stack and making the most from the ubiquity of Kubernetes setups.
Looking Ahead It’s been a real inspiration to read Morten’s post on LinkedIn regarding the fracture between the open-source nature and SaaS-ification of the hosting services. I believe that the future stays in the open and collaborative effort, rather than in the closed-garden solutions, especially when the time for Kubernetes is now. More and more Cloud providers include Kubernetes in the standard offer and make it a so-to-call-it a universally spoken language for building the infrastructure for deploying and hosting software projects.
On the same note, I must agree with Matt Mullenweg that putting the right technology in the hands of people, at an affordable cost (let’s set the target to open-source!), can significantly change the web as we know it. WordPress needs a better engineering management processes to stay relevant from 2019 onwards, influencing the need for radical improvements in UX/UI coming in the form of Guttenberg. Especially when new technologies such as JS come into the mix, today’s WordPress developers need to continuously learn and master.
The Stack can become a standard, too and we’re committed to continuing our technical work, but at the same time to attempt at becoming even more open by learning on how to better manage a project that is open-source and democratic at heart. This brings to the table our next priority—a governance model, even for the less than 10 contributors we’ve had so far. WordPress has a complex task to adjust its governance model, or rather to implement a formal one.
So learning from this is important to lay down proper paths from the beginning for an open project. I believe that you cannot democratize something without a deep commitment to the process of doing it. We’re set on the track to democratizing hosting for WordPress thus trying to make it accessible and open.
