Project Moiety – A Hypothetical WordPress Roadmap

Recently on the PostStatus Slack team, Brin Wilson started a discussion about what it would hypothetically take for WordPress to get to be installed on 51% of all websites (it currently sits at about 27% at the time of this writing):

"Brin Wilson - So WordPress now powers 27% of all websites and seems to be increasing its market share at a rate of about 2% a year. So to get to 51%, at the present rate, that'll take another twelve years (happening in 2028 then). Is this realistic do you think? Or do you imagine it'll take more/less time? Or perhaps even never actually get there at all?"

It is an interesting thought experiment, and a lot of interesting points were made during the discussion. Matt Mullenweg weighed in on what he would think makes WordPress the “best possible product”:

"Matt Wullenweg - market share is a symptom and result, not a goal. it's a way to measure how much we've created the 'best possible product"'

Helen Hou-Sandí made an interesting observation about the two different “camps” that seemed to emerge:

"Helen Hou-Sandi - I think the gap between 'I believe the growth of WP lies in what users of the UI find to be tangible improvements in their workflows' and 'I believe the growth of WP lies in its technical underpinnings' is quite interesting"

Franck Frémont went ahead and wrote up a proposal for a long-term roadmap for WordPress, and challenged me to do the same from the technical perspective. So here’s my take on what I would think is necessary to get WordPress to account for 51% of the web.

Target Audience

Before making change suggestions to go on our roadmap, we need to define what audience we are mainly targeting. Given the methodology that is used to measure the market share (top 10 million websites according to Alexa rankings), I don’t think that targeting individual end users will amount to major changes in market share anymore.

I would rather think that big enterprise clients are the next major audience to target. Right now, WordPress is lacking a lot of important features for enterprise clients, and while they might use it here and there for a blog, it is not often used as a full-blown CMS in an enterprise setting.

The next target audience for major growth opportunity for #WordPress are enterprise clients. Click To Tweet

That’s why I suspect the enterprise segment to provide the biggest growth potential and I will target my hypothetical roadmap accordingly.

Here it is then, my proposal for a long-term WordPress roadmap…

0 – Overview

  1. Technical Requirements
  2. Release Strategy
  3. Compliance
  4. Editorial Workflows
  5. Integration Interfaces
  6. Deployments
  7. Command-line Control
  8. Certification
  9. Recommended Partners
  10. Leadership

1 – Technical Requirements

For WordPress to be able to continually grow, it needs to have tools at its disposal to keep Software Entropy in check.

Please consider the following two laws from Lehman’s Laws of Software Evolution (paraphrased):

  • The software must be continually adapted or it becomes progressively less useful.
  • When the software is changed, its complexity increases.

This means that WordPress will need to deal with an ever-increasing level of complexity, and following from that, making changes to WordPress gets increasingly difficult and costly (at least in time and effort, if not financially).

#WordPress needs to have tools at its disposal to keep Software Entropy in check. Click To Tweet

As WordPress is a procedural codebase with a lot of global state right now, most changes will need you to consider the entire code base (and thus, the entire complexity) at once. Therefore, my first priority would be to refactor the WordPress Core in a way that gets rid of that global state, and allows for complexity to be properly partitioned, so that you can deal with changes and their consequences in smaller subsets of the code without having any impact on the rest of the codebase.

This is necessary to be able to adapt to small and large requirements changes that the future might bring. What needs to be avoided at all cost is to encounter the next major web revolution without the means to meet its requirements in a timely and satisfactory way. Failing to do so might eventually lead to WordPress just becoming obsolete.

I have already written about what I think needs to be done to make WordPress ready for major changes in a previous post.

Apart from these basic technical requirements, I feel that two additional components should be provided by the WordPress Core:

  • Logging subsystem, available to all components. Logging is such a vital feature that it ends up being implemented by nearly every substantial plugin and custom solution. Having a centralized solution provided by Core would avoid everyone reinventing the wheel and would allow for a company to route their entire logging efforts through external logging servers.
  • Message Bus system, allowing to decouple processing tasks from the frontend page requests. There are cron jobs right now, but their usefulness is very limited, and they often cause all sorts of issues. Having a message bus system that can optionally be decoupled from the actual WordPress process (using something like RabbitMQ) would avoid having everything under the sun be directly coupled to the web server’s page rendering process.

Both of these can easily be added through custom development right now, but having them be included within Core (at least as an interface and stub, with optional implementations installed separately) would mean they can be used across vendor boundaries. As an example, if there was a central bus system, a product like WooCommerce could create an event ProductAddedToCatalog, to trigger its own update mechanisms. This would allow third-party extensions to also listen for that Event and trigger their update mechanisms as well. Both would run independently from each other (so one can’t break the other) and wouldn’t be able to slow down the frontend page request (as they would run in a different process and could potentially even run on a different server).

2 – Release Strategy

WordPress lifecycle management policy should be rethought, so that there are occasional windows of opportunity where breaking changes are allowed and expected, so that there’s a structured way of shedding needless way and getting rid of legacy burden.

#WordPress lifecycle management needs occasional breaking changes and LTS releases. Click To Tweet

The policy should include a long-term release schedule, with occasional long-term support releases (LTS) and recommended migration paths from one of these to the next.

node.js release schedule chart with normal and LTS releases

Example: node.js release schedule (click to open node.js LTS schedule page)

The benefits of such a release strategy are the following:

  • Backward compatibility (BC) needs only be kept up to the most recent LTS release.
  • BC within the version spectrum between two LTS releases can be even more strict than it currently is.
  • Legacy code and thus complexity can be regularly discarded.
  • LTS releases let enterprises integrate the software into their own long-term planning.
  • Maintenance / updates / migrations are foreseeable and plannable.

A proper release strategy is essential for enterprises, where less “agile” processes like 5-year-forecasts are rather the norm. They need to be able to orchestrate deployments across several different software projects in cycles that span years rather than months.

3 – Compliance

For enterprise clients, controlling compliance is not a “nice-to-have”, it is a basic requirement of doing business. If WordPress intends to be usable in any mission-critical context for larger organizations, it needs robust tools and solutions for implementing and/or supporting regulatory compliance. This could imply changes like subjecting the business content to enforced data retention policies, keeping auditing logs with the content workflows or even having connectors to integrate with over-arching compliance management solutions.

For enterprise #WordPress, controlling compliance is a basic requirement of doing business. Click To Tweet

This is a very complex subject matter, and difficult to get right at an international level (being that most regulations differ from country to country). While having integrated solutions for all compliance-related areas is a lofty goal indeed, a good first step might be to go over something like the guidelines set forth in ISO 19600 and make sure that none of these recommendations are actively obstructed by WordPress at least.

4 – Editorial Workflows

Given that WordPress claims to be a full-blown Content Management System (CMS), it is quite alarming that managing content at scale (large team with large volumes of content) is not realistically possible without a combination of plugins and SaaS enhancements. The actual “Management” of the content does not extend much beyond a simple CRUD interface.

Right now, it is not realistically possible to manage content at scale with OOTB #WordPress UI. Click To Tweet

Large content teams need workflows, customizable states, editorial calendars, communication and collaboration tools, notifications, reports, … In this regard, WordPress better fits the “development framework” drawer rather than the “content management system” drawer, as the management experience out of the box is far from polished.

I think this should be tackled from a UX perspective first, while completely disregarding the current technical underpinnings. When the ideal workflow has been identified, the implementation requirements for this workflow should inform the development roadmap, to make the perfect workflow “eventually” possible over a series of iterations. The important thing is that a specific goal has been decided that gives direction to all subsequent UI/UX changes. While there’s lots of work being done on the editorial experience, it often seems as a series of random, disjointed spot repairs, rather than a concerted effort.

5 – Integration Interfaces

Any larger organization already has lots of mission-critical systems in place that are not easily replaced. WordPress should provide the relevant integration interfaces where it makes sense, opening up the possibility to write connectors to the other systems in a reliable and fail-safe way.

#WordPress needs clear integration points to allow reliable connectors to external systems. Click To Tweet

Although there is already the possibility to add functionality through plugins, this often results in solutions that are arbitrarily tacked onto existing functionality, and that break when using several of these in combination.

For each of the main integration points, there should be a clearly defined interface that makes it possible to add any number of these integrations in a reliable way.

Here are some examples of such integration points:

  • User authentication, to provide integrated Single Sign-on, letting IT manage users from outside of WP and letting users log in via their fingerprint or other enterprise mechanisms.
  • File management within Media Library, so that IT can attach several externally managed media libraries and document management systems (with correct support for authorization, searching, etc…)

6 – Deployments

Right now, proper deployments of a WordPress site are only possible with huge amounts of additional efforts. Two main issues need to be solved to allow for more streamlined deployments:

  • Environment-specific data mustn’t be stored within the content database. The content database should be completely agnostic of the current environment it is being used in.
  • The content within the content database must be properly versioned. Currently, given two similar copies of a WordPress content database, it is next to impossible to find out what exact changes have been done in what order.

These issues are the more common nuisances that deployment systems for WordPress have to deal with. Addressing them to allow for straight-forward and reliable deployments would also encourage the use of standardized deployment tools, instead of all the custom WordPress-specific solutions you need to use right now.

#WordPress needs standardized deployment tools instead of a random collection of custom solutions. Click To Tweet

7 – Command-line Control

An enterprise site needs to be scriptable. The IT department does not want to click through the admin screens on a daily basis to address upcoming action items. They want to write scripts that let them control the entire infrastructure as a coherent whole (or at least give it an honest try).

The IT department wants scripts that let them control the entire infrastructure as a coherent whole. Click To Tweet

There’s already a great project called WP-CLI that allows you to control your WordPress installation through the command-line. However, it has a few inherent short-comings due to the fact that it is an external addition, not part of the WordPress Core.

Ideally, WordPress would move towards adopting a hexagonal architecture, with both user interface and command-line actions having practically the same execution paths. This opens up the opportunity for more advanced command-line antics and consolidates code between both WordPress and WP-CLI. Having the actual logical processes be decoupled from the user interface representation also makes it much easier to change said user interface in the future.

8 – Certification

Enterprise HR relies on certifications to be able to hire for minimum skill levels. We all know that this is far from ideal, but it is the only way that HR departments without technical expertise can make sure they don’t hire a complete lemon.

Enterprise HR relies on certifications to be able to hire for minimum skill levels. Click To Tweet

There needs to be a network of certification bodies that can ensure that certified developers / implementors / coaches / … do indeed offer the minimum set of skills that their position would demand. As a bonus, these institutions could also offer “standardized” training as well.

As nice as it is to “hire for attitude” or similar approaches, your company will be in real trouble if your developers cannot write basic PHP code without copy-pasting from Google results.

While this will definitely have an impact on the current low barrier of entry of WordPress, I would assume that the enterprise much prefers having gatekeepers to avoid the most obvious abuse of trust.

While the 5-minute install is nice for private end-users, most larger enterprise projects start by getting implementation/integration experts on location to support the in-house IT staff with collecting requirements first. So, they want to see a list of recommended partners from their area to know where to start and whom to contact.

Enterprise IT needs recommended partners to collaborate on large-scale projects. Click To Tweet

It is very difficult to do this without introducing bias and unfair advantages that hurt the core philosophies of the WordPress project. This should be governed by an independent non-profit.

10 – Leadership

I’ve kept the most important one as the final entry. It is the one element that has a direct impact on the success of all the previous points.

For a group to make a concerted move into a specific direction, there needs to be leadership. Without leadership, movement will be distributed amongst all sorts of different directions and the result will just average out to lose its impact.

For a group to make a concerted move into a specific direction, there needs to be Leadership. Click To Tweet

If an enterprise client wants to base its 10-year strategy on a specific offering, they need to see that the team behind that offering has a strong vision and a clear direction.

The Open Source WordPress Community should try to distil true leaders from its huge group of contributors, and encourage them to proactively shape and chase a bigger vision. While we already have several forms of “middle management” at different levels, it seems to me that the overall progress is decided by a random set of actions, rather than a concerted effort.

Okay, Where’s The Source?

Unfortunately, I don’t have finished source code to share this time… 😜

All of the above is mostly meant as food for thought. The way the Open Source project has grown and is currently set up certainly makes it difficult (and maybe uncalled for) to have true leadership and an overarching vision. But that is probably “the next frontier” to explore.

Please put all feedback and expressions of dismay in the comments below!

25 Comments

  1. Keanan Koppenhaver on November 18, 2016 at 10:15 pm

    Hey Alain,

    Great piece, definitely lots of food for thought.

    RE #9, isn’t something like https://vip.wordpress.com/partners/ what you describe in a way? Especially because the VIP program already does target those more enterprise level clients.Report

    • Alain Schlesser on November 18, 2016 at 10:19 pm

      Hey Keanan,

      Thanks, glad to hear that!

      Well, the list you’ve linked does provide partners like what I describe above. However, these are for WordPress.com VIP projects (the commercial Automattic WordPress.com platform), not for the Open Source WordPress.org software.

      These are different entities, and as far as I know, do not even technically share the same Core.Report

      • Keanan Koppenhaver on November 18, 2016 at 10:46 pm

        Technically, you’re correct. But as a VIP Partner, we also take on projects that aren’t strictly VIP projects. We get some incoming leads that saw us listed as a partner and know they don’t need a VIP project but are using that list as just an initial bar to clear for quality.

        Potentially, something like that could be adapted (maybe expanded?) for non-VIP agencies…Report

        • Alain Schlesser on November 18, 2016 at 11:44 pm

          Yes, I assume it can’t hurt to appear on the .com partners list anyway… :)

          I would guess that this might have more to do with the general confusion about understanding the difference between .org and .com, though…

          It would certainly be beneficial to have an official partner list on the .org site as well.Report

  2. Donna on November 19, 2016 at 1:31 am

    While all this sounds wonderful, I don’t see this ever happening. It takes years for the smallest of changes to take place in the current system. The whole applecart would have to be dumped and even then, it probably would stall out early on. Incremental to the millionth degree is more likely. But I like the concept. Just doubt anything near this would turn into reality.Report

    • Alain Schlesser on November 19, 2016 at 11:30 am

      Yes, that is the most probable scenario. But who knows? Maybe we can try to get more and more people to buy into such a long-term vision. With the high number of people voluntarily contributing, I can only imagine what we could be able to achieve if we could channel and focus all the effort towards a common goal…Report

  3. Tim on November 19, 2016 at 2:54 am

    This is an excellent piece, Alain. Thanks for sharing your thoughts. It’s true that points 1 through 9 are lofty goals, but with proper leadership (point 10), who knows….we might be surprised at how fast things take shape.Report

    • Alain Schlesser on November 19, 2016 at 11:42 am

      Yes, I agree. While I am not that optimistic that we can reach these goals easily, I also wouldn’t say these are strictly impossible.
      We should at least give it an honest try, right?Report

  4. Ralf Koller on November 19, 2016 at 6:50 pm

    I can’t second enough the list of technical requirements by Ryan McCue and you for point 1; especially the point „Support PHP versions“. People have to realize one thing, with WordPress running 27% of all websites, with its current approach towards backward compatibility WordPress is fostering the bad practice and laziness of not to update unsupported and insecure PHP installs on 18,63% of all websites (69% percent of all installs are on PHP < 5.6). If you want to get a wider adoption and interest especially in the mentioned enterprise segment you have to solve especially that issue.
    Point 4 you have to extend massively in my humble opinion. Editorial workflow is necessary but especially for the enterprise context WordPress is lacking a thing or two in its foundational capabilities in the regards of content. At the moment WordPress is still a blogging software based on its database schema. Out of the box you have a title field and a wysiwyg field; the latter a big blob of information everything is stuffed in. In todays enterprise context, especially with a large amount of content, you have structured content, the exact opposite to those bulky blobs, which means specific reusable chunks. At the moment you have to use plugins like Advanced Custom Fields, Pods.io or CMB2. The Fields API is on the horizon (haven’t taken a look at it yet) but nonetheless all those plugins as well as the API still rely on the unaltered underlying WordPress storage system which means all custom fields data is saved in post meta encoded as text. In that context Jeff Eaton sums up the crux pretty well in the „Redesigning The Toast“ article:

    This isn’t a problem if you’re only using custom field data when a post is loaded and displayed. If you plan to use these custom fields to handle complex relationships—connecting a post to multiple authors, say—the SQL queries to handle that data will be punishingly slow.

    The missing Fields API and the storage system are my main hassle and reason not to recommend WordPress in the context of a content intensive projects.
    But it also lacks two enterprise relevant capabilities which are vital for the content context. On one hand the ability to translate the site content; at the moment only the translation for the UI parts is provided out of the box.On the other hand WordPress is missing a more granular role system to make certain pages and interfaces accessible to certain roles within the frontend and admin menu as well as functionality in core and its active plugins. Drupal is a good example for a granular permissions system.
    For point 6 a huge +1. If you refer to settings with „environment specific data“ then the removal from the database into config files would not only be useful in regards of the deployment but also performance wise – far less db queries.
    For point 10 I might disagree or better want to rephrase your suggestion. WordPress already has some sort of leadership in place with its release leads and the core committer team. The problem in my opinion is that each new release cycle is some sort of reset to the goals and vision each new release lead has. So you have short term goals each time (sort of) but not the bigger picture and the strategic vision is taken care of. I wouldn’t deal with that issue by bringing in another layer of administration and leadership but solve it with the existing „staff“. Start with a surveys for existing users, possible future users and persons from the enterprise context and do bespoke questionnaires in regards of missing functionality, current top tasks and so on. Based on that survey the core committers might start an open discussion shaping a long term road map instead of planning from release to release more or less. Just my two cents. ;)Report

    • Alain Schlesser on November 21, 2016 at 7:51 am

      Wow, Ralf, you’ve written an entire post yourself here!

      I want to quickly address the points you’ve raised:

      Re. 1 – Yes, it should be a responsibility to have the sites be forced to keep up-to-date and secure. While I understand the reason why WordPress does not want to break existing users’ sites, I am concerned that this leads to security implications on a global scale. DDoS attacks through unsecured servers that are not even aware they’re being remotely controlled are constantly rising, and it seems very likely that old PHP/WordPress sites are part of the bunch.

      Re. 4 – Yes, there is a lot of improvements that can be made in that specific area. While I don’t think WordPress should address every single need directly in Core, it should at least provide the reasonable means to do so via plugins.
      Regarding the Fields API, my hopes are not very high. The last time I looked at it, it was just a very tight procedural wrapper around the existing database schema, with little abstraction in place that would enable major changes to that schema.
      I had considered to directly add both multilingual capabilities and better permissions (at least add permission groups to the current users & roles) to the article. For proper multilingual support (having each content field be storable in several languages), I’m afraid that is simply too late and won’t ever get addressed, and the permissions system is something that should be included within point 5 to be adaptable.

      Re. 10 – Yes, completely agree. There is leadership within the cycle of one release, and the release leads do a tremendous job! What is missing is a long-term target to reach and the top-level leadership to tie the individual releases into a coherent whole that continually moves the project towards that target.

      Thanks for your two cents, Ralf, they are worth more than what their monetary value suggests…!Report

  5. Ahmad Awais on November 19, 2016 at 8:57 pm

    Great piece, Alain!

    While I am on vacations these days, I did really enjoy reading this one and kinda catching up on what’s going on. While Node.js release cycle is pretty interesting, I think it can have a bad impact on WP — why!? Coz. many beginner developers think WP is easy which is the prime reason they jump in. No one thinks about Node.js that way. I bet if you ask 100 people who are using Node for things like Gulp, Grunt, almost 80 won’t have an idea about the diff in several versions of Node and that which one should be used by whom.

    Anywho, let’s keep talking about this.Report

    • Alain Schlesser on November 21, 2016 at 7:55 am

      Thanks, Ahmad!

      Well, as you say yourself, beginner developers can use node.js just as well without knowing about these different versions. So while I agree that not everyone would be able to appreciate such a release cycle, I don’t think it would impact WordPress in a bad way. You can just still install whatever version is current and keep it auto-updated. But, enterprise users but have one more tool at their disposal to make WordPress the right fit.Report

      • Ahmad Awais on November 21, 2016 at 6:51 pm

        Maybe a WP Enterprise dev cycle just like there is WP VIP from Automattic would make more sense.Report

  6. Lisa Linn Allen on November 20, 2016 at 5:59 am

    So much all of this. First someone influential has to buy into the idea that the enterprise is a worthy target – I would love to see that happen.Report

    • Alain Schlesser on November 21, 2016 at 7:57 am

      Well, maybe it very intentionally isn’t. A clear roadmap indicating so would avoid a lot of redundant discussion then… ;)Report

  7. Luke Cavanagh on November 21, 2016 at 4:19 am
    • Alain Schlesser on November 21, 2016 at 8:00 am

      Thanks for the effort, Luke! That ticket was closed already, unfortunately. But I have to agree with Samuel Sidler, the Core team itself needs to decide that a long-term roadmap is needed and work on it from the inside. Everything else is just bound to fail anyway.Report

      • Luke Cavanagh on November 21, 2016 at 8:04 pm

        The meta ticket is just closed, until there is direction from core.Report

  8. Antony Agnel on November 21, 2016 at 2:38 pm

    Certification is really the need of the hour. As WordPress’ market share keeps increasing, we need more skilled people to contribute back to it to help aid in its development. Also, I liked the way how you used Lehman’s Laws of Software Evolution in the first point. Kudos.Report

    • Alain Schlesser on November 21, 2016 at 3:01 pm

      Yes, as far as I can tell, the demand for skilled WordPress developers currently far exceeds the offer.

      Thanks for your feedback, Antony!Report

  9. Jeremy Ross on November 21, 2016 at 9:53 pm

    This is a really great roadmap and it addresses a lot of the inconsistencies and work-arounds that I’ve had to deal with in WordPress lately. But I have become a WP dev in the most backwards way. I started just installing and customizing themes, then learned to copy/paste code from google search results, then learned basic PHP, then started learning OOP patterns and thinking like a software developer. I still have such a long ways to go.

    However, the wild-wild-west vibe of WordPress and the inclusiveness of the WordPress community provided me the opportunity to write really bad code and ask all of the stupid annoying questions that got to where I am today.

    The weaknesses in WordPress, in my opinion, are the very thing that makes it 26% of the Internet. The fact that you can dive in and have permission to be a crap programmer means a lot of people will do it. It doesn’t have an elitist community, and my fear would be, if we start having longer term plans, certifications, compliance policies and stronger leadership, yes, we’ll have a better piece of software, but it will break the spirit of WordPress and produce a decline in adoption rather than an increase.

    What you’ve presented here would absolutely make WordPress a better piece of software, I’m not sure that it would result in 51% of the market, though.Report

    • Mike Schinkel on November 22, 2016 at 12:08 am

      The weaknesses in WordPress, in my opinion, are the very thing that makes it 26% of the Internet.

      What you’ve presented here would absolutely make WordPress a better piece of software, I’m not sure that it would result in 51% of the market, though.

      THIS.

      @Jeremy Ross, so glad you posted the above so I did not have to write so much. But you nailed it.

      Not about WordPress but I explain many of the reasons why your comments are likely to be true in this blog post about Drupal 8. Not all my comments on Drupal 8 would apply to WordPress unless, for example, WordPress were to rearchitect and use Laravel — though that will never happen — the points about Visual Basic’s history firmly apply.Report

      • Richard on November 24, 2016 at 5:26 pm

        Read your older article,

        VB had numerous issues pre .NET that killed it but yes, towards business operations it had a very sizeable market segment.

        Here’s the thing. Nothing lasts forever.

        When large segments of market share appear money steps in to eventually dominate things with better mouse traps.

        There was a time when oodles of PHP based applications houses did well creating all sorts of differing web applications as commercial offerings. Most have now failed and some hang on. A good deal of them replaced by Drupal, WP, Jooma etc. These handful’s of open source projects that still move ahead. A good many of the promising one’s of past are in the wane as well.

        Right now the world of technology in the digital realms is continuing to march towards device unification in smart client devices. One of the biggest hitches in forward movements were the two predominant OS’s, Windows Server / Linux towards the Internet. If we take it offline, different as Windows tend’s be in Small, medium and enterprise biz but in enterprise hybrids are near necessity, both, Win OS and Linux. Yes, the Mac exists as well and has gained some ground but not significant ground. In the home different of course.

        What drives the technology are end folks. The home entertainment stuff just as in the past is generating more forward movement than anything else just as it did with PC Gaming, cept’ now, its console / mobile.

        Microsofts open sourcing .NET spells an end game for any players out there unwilling to embrace it towards the future. Many reasons but first and foremost comes the interoperability in device unification software driven that will continue plod ahead like a pyroclastic flow albeit slower.

        The PHP application frameworks are simply put not capable both in feature, resource usage, performance a match of .NET / Mono. PHP does not native CPU compile scripts to machine executables which is exactly what it should be doing.

        The lions share of coders across the globe have worked on applications for their employers and the web was considered independent resource. Many tools to effectively use it towards business and information. Thats shifting. Regulatory measures will be coming as well “For safety sake” forcing that shift.

        WordPress right now some are using not as a CMS per se but as a SaaS provider, an engine. The WP community see’s this as “See, we are still growing” when in fact what is displayed is again a weakness in the PHP community of proper solutions. Yet, in the Mono/.Net universe thats not the case. What drives this is knowledge. “I know WP so I am going to power this app with it”. They make their money (maybe) and ultimately will have to move towards better performance and the underlying tech stack.

        As device unification continues anything thats NOT in standards is out in the cold.

        I’ve saw Adobe’s offering in development for CMS or “Webtop Publishing” shall we call it? Simply put it makes anything most of us have ever toyed with as a Web based publishing platform look not only archaic but downright ancient. Atop that, its built atop solid modular scalable assets, its extensible virtual containers make things such as “plugins” seem again simply ancient.

        The example I saw of Adobe’s offering showed in 15 minutes one application suite creating a breaking news story from scratch including content curation occur in 15 minutes from nothing to live with a traditional (newspaper like staff). The same in any CMS I have ever used be they PHP, DNN, Alfresco etc etc EASILY take near two hours to do what happened in 15 minutes and require a whole blast of external tools.

        IMHO Automattic should be creating WebPress II atop Mono / .Net since it has the money to do so. By all means keep WP moving forwards and start getting the ardent developers to make moves towards learning C# in support of WebPress II.

        The Antimattic crowd always nips that the company has failed in everything but WP and even point to Envato who makes money hand over fist by taking advantage of it. The cheerleaders have created two groups when skilled multi-discipline developers speak of alienating any of them not being tribesman, that entire operation of “reporting” should be closed. It fails Automattic in just enormous fashion.

        WP has no path forward into whats coming. Thats the reality. Even atop the platform that is tomorrow it is orphaned in that its a CMS at the end of the day. People often point me at Facebook’s PHP success, its anomalous not the norm and its success is due to many aspects including time to market that happened much more so than its software stack.

        At the sametime there is something to be said for living. If I were Mattic I’d ride the wave and when it ends it ends. Live life, its finite. Can chase WP this and that or decide know what, “I am blessed” live it up. See the entire world. Enjoy it.Report

    • Dominik Schwind on November 23, 2016 at 2:28 pm

      Yeah, I was just about to say that. At the moment it is pretty much that ubiquitous because it is the easiest answer to the very common question “I want my own page on my own domain on this affordable hosting plan and I want to be able to edit the content. What can I use?”Report

  10. Richard on November 23, 2016 at 11:55 pm

    WordPress powers much of the Internet based on what options exist. The other two popular systems that existed when WP began getting a market share were Joomla and Drupal both of which are more difficult for the average person to cope with.

    The odd’s of WP continuing towards enterprise is quite slim simply due to underlying technology. You make excellent points in your article. Matters such as flexible workflows are simply abysmal, ease of roles and then some.

    Drag n drop presentation is the future. Simple web publishing is already there. Complex publishing is well underway by the likes of Adobe for example. Last year I was privileged to get a glimpse at the Adobe solution to enterprise publishing and its simply amazing. It makes Joomla, Drupal, WP look like DOS .vs. Windows. Essentially its desktop publishing online on steroids. While it can be a single individual solution its clearly targeted at businesses of pretty much any level. The presentation I saw (at Rochester Institute of Technology) showed a normal news (such as say the NY Times) workflow being coordinated and implemented. It very much mimic’s hand on news workflows through stored process flows.

    For example, a breaking news story could be brought public facing in literally less than 15 minutes complete with article, images, edited video and then some.

    There are other issues such as PHP itself and the general underlying aspects of the operating environment .vs. that of Mono / .NET and C#. Ease of scaling on and on. While PHP 7 is a WHOLE lot faster than PHP was it is still an order less efficient than say C# Core .NET on linux which clocks in 400% faster still.

    Interoperability in PHP applications is extraordinarily scant as are applications themselves. .NET has numerous solutions far beyond import/export or REST based API’s and roles management built in as coarse or granular as one chooses at the operating system level all the way up to the top.

    The biggest hurdle that entities such as Adobe face in competing against entities such as WP is profits. Adobe cant likely run free 5 years for example to anyone who wants use the technology to lay waste to competitors. However, the WP ecosystem is shifting more and more towards plugins that are crippled in lieu of paying for “Support” to have a non-crippled version which begs to say, “Are users that foolish?”

    That is to say, if a webmaster has a non-crippled version and wants support pay for it .vs. you only get a complete version if you buy support. That use to be called shareware. In the WP ecosystem its called “Support”.

    Take a look through the WP.org repository at crippleware comments more or less those who install the crippleware only to find when removing it garbage is left behind in the database.

    One thing WP Core should do yesterday is REQUIRE any plugin/theme author(s) to state ANY/ALL limitations in the crippleware .vs. commercial edition as a menu item AND other options in the repository as well as the costing.

    Some of them are just ridiculous, $79 a year for a video gallery for example. A single video game at $60 at your local gamestore has more engineering behind it than any video gallery on the planet more or less reoccurring payment. Then one looks at the source code to see that 80%+ of the code is other peoples work whom the plugin author never sent a plug nickel their way.

    WP Core needs (IMHO) look at the roots of its success and enforce the tradition of that. While they cant under varied GPL licenses dictate they can display to prospect webmasters seeking plugin’s or theme’s crippled .vs. not assets.

    Its simply ridiculous to have a plugin lets say that allows whatall, 10 collections of some data and require a webmaster pay $40 to get one without limits and moniker that under “support”. Its the same formula as shareware has had for years. Its a lie essentially.

    The shoutback at this is “Well after the support term of time ends you still have the full plugin or theme, you just do not get support or perhaps updates.” Again, no different than shareware.

    When you consider lets say Adobe comes forth with subscription plans (which word has it is the idea). For $50 a month you get your hosting and a non-crippled complete environment which are you going to choose?

    What makes WP wonderful are all the choices in plugins and theme’s and relative low costing.

    What will kill it is what your seeing happen now. Crippled assets that developers then upsell upon capitalizing on what is essentially a lie. Call crippleware what it is, a form of shareware and display to the prospect downloader what the limitations are and other alternatives giving the webmaster the choice of who to support and who to not support.Report

Leave a Comment