Shackling a free market: WordPress canonical plugins

In matters of criminal investigation, intent can be proven by certain actions. However, in these cases, there is a jury to be convinced and a victim to be vindicated. Thankfully, when it comes to disputes in the tech community, one need not try to prove intentions through actions. One need only ask. Following the remarks from yesterday’s WordCamp Atlanta, where a trial balloon was placed in front of the world—this is the internet; everything local is global—about “canonical” or “endorsed” or “core” plugins, I must ask the WordPress lead devs, all the way up to Matt himself: why?

I’m not a plugin developer, nor a theme developer, or a pure front-end designer. I honestly don’t know what to label the gestalt of my skills, but I do good work. Part of that good work is being able to select which plugins work for my project requirements. While I truly appreciate the good intentions of the WordPress leadership in bundling plugins together and endorsing them, but I have my fears on its effects on the plugin marketplace.

It’s libre in more ways than one. Let’s keep it that way.

The current state of the marketplace follows the standard distribution of players based on power laws. Right now, very good plugins with even better promotion and marketing dominate the marketplace. Is there a better plugin for a given application? Yes, but for reasons beyond the control of the WordPress leadership, they don’t get as much exposure. These reasons vary. The developer may be an asshole. Updates may not be frequent enough to keep up with WordPress’ own development cycle. The plugin may be very esoteric in application. Whatever the reason, this hypothetical “better” plugin lives and dies without the interference of the leadership. The only thing more American than the WordPress plugin and theme marketplace is apple pie.

Releasing canonical plugins and themes, while making it easy for end-users and new adopters, interferes with that dynamic. Today, If I were to release Richmond—the theme running this blog—into the wild, I will have to compete with the awesomeness of Studiopress and Woothemes. If the WordPress Project were to include a theme similar to mine, not only do I have to compete with everyone else, I’d have to compete with God Himself.

“Canonical” “anything” is a takeover of a market that doesn’t need it.

I’ve always defended the WordPress Project and especially Matt himself from accusations of others that he’d rather not let anyone else make money off of this. Mark Jaquith is proof positive that one can make plenty of hard-earned cash from playing within the rules of the open source game. However, these “official” add-ons are a deathblow to innovators, because WordPress’ expansion has evolved the market into a consumer one.

The bar to entry is low: it’s easy to set up a blog, find cheap hosting, map a domain name, etc. The users, however, have gotten lazy. When only 75% of users at a WordCamp are using the latest versions, we have a problem. Using a simple extrapolation—of course, not a statistically perfect method—of that number, assume 15% of the market is running outdated, insecure versions of the software. That’s a huge problem, considering the number of WordPres blogs out there. While I strongly believe that it’s one’s responsiblity to maintain and update a site, that assumed number is that of irresponsible blog-owners who present a danger not just to the reputation of the WordPress community but to the general online health of all online people.

These same lazy people are the ones who won’t be bothered to pick a plugin based on how it performs. They’ll reach for the closest solution accessible and go with it. In today’s plugin/theme marketplace, the market leaders may not be the best of best of the very darned best, but they come close. In tomorrow’s canonical marketplace, the majority of users won’t be bothered to move beyond that which is canonical. Why would they, when those selfsame plugins and themes carry not just the approval that a theme is safe, but that it’s endorsed by and is considered “official” by the WordPress leadership itself?

Leave us to squabble amongst ourselves.

God Himself limits the miracles He performs, because He has given us the ability to affect our world because of our will. The free market of plugins and themes is a beautiful thing. It forces the likes of Studiopress and Woothemes to innovate ahead of the market, or lose their edge. It forces me to refine my projects or lose relevance. The miracle of canonical plugins would end this. Perhaps not overnight, but it will. I implore the decision-makers at the WordPress Project: this is not change we need, nor is it change we can believe in. I understand that the opinions of end-users are important, but this still is a community-driven project, and a canonical marketplace—or better yet, a Command Economy—would have us fighting for the favor of the leadership, and not our clientele. That’s not a marketplace; that’s a clique.

Ma.tt responds:

Hey Jay! I’m always happy when you write about WordPress. :)

First a disclaimer: I’m probably one of the biggest free market nuts you know. In fact in college I focused on economics and political science/philosophy.

That said, I didn’t finish, and let’s be honest I wasn’t the most studious guy in the world. Maybe I missed something important. Although I’ve thought about this issue endlessly, including most of the issues raised here, there are some things brought up in the comments that I haven’t thought about before. More importantly, you could be right.

That’s why we’re doing this whole thing as an experiment; not the Large Hadron Collider type that could potentially destroy the universe, but more incrementally with just three initial plugins.

The first, health check, is one that’s entirely new, a collaboration between some existing core folks and some new contributors. The second is existing core functionality, post by email, that we’re taking into a plugin to make core lighter, faster, and less bloated. Hopefully it will improve significantly too because we’ve got some really cool new code from it being donated from the WP.com side. The third, PodPress, is an existing plugin that is very popular in the community and provides important functionality but has effectively been abandoned, so we’re going to adopt it and modernize it so people who rely on that plugin aren’t stuck on old versions of WP.

Something new, something old, something borrowed… something blue? Yep: Kubrick. :)

Now if in the course of working on these three plugins it looks like we’re going to cause the end of WordPress as we know it, we’ll change course. It’s not that big a deal, and we’ll figure something else out. The only dangerous course of action is doing nothing at all.

85 thoughts on “Shackling a free market: WordPress canonical plugins”

  1. Excellent post Jay.
    We don’t really know very much about which plugins will be canonical. I think some plugin called healthcheck is the first one out.
    People have expressed fear that WordPress will loose user because themes and plugins go commercial.
    Personally I think it is far more likely that WordPress will loose its upcomming developer base with the introduction of more canonical plugins.
    WordPress and its leadership has basically started competing with the rest of the developers that does not visit the Dev Chat on thursdays.

  2. I can tell you a really, really good reason why.

    Most plugins *SUCK*.

    Seriously, the quality of most plugins is abysmal. They’re constructed by amateur coders, in their spare time, not looked after, rarely upgraded, virtually unsupported… Almost all plugins are this way. Only a small few exist that are up to any sort of coding standard. Yes, the big and popular plugins are generally okay, but the rest of them are crap.

    And WordPress users have a lousy track record at determining good plugins from bad ones.

    Every upgrade of WordPress that happens there are old, bad, plugins which break the upgrade for anybody using them. No matter how many times we tell people to disable their plugins, nobody ever does. The automatic upgrader doesn’t even do it (it can’t, honestly, if it disabled the plugins then it could break loads more sites). So here you have Joe User who clicks the upgrade button, and then his site breaks because he’s now running an incompatible plugin.

    Does he blame the plugin? Hah!

    He blames WordPress. He goes online and complains about a shoddy product. He complains on the support forums, on websites, on Facebook. And then somebody comes along and says “hey, delete that old crap plugin you have”, and his site magically works again. And that’s when the user shuts up and goes on with his life, not correcting his own words. The damage to the reputation of WordPress is done.

    We need Core Plugins because *we need plugins that don’t suck*. We need a base of plugins, each with multiple authors, well-supported, many eyes examining their code. Yes, you can do that now, but the purpose is to encourage that sort of thing.

    When I wanted to get Facebook Connect working on my website, I looked for a plugin. I downloaded about 10 of them that purported to do it. All of them were universally awful. Badly written, badly documented, hard to understand, used weird hooks and incorrect ways of doing things… I had to write my own plugin to do things the right way (more or less, I learned what “the right way” was while doing it).

    We need plugin authors that know what they’re doing to teach the ones that don’t. Instead of having 30 barely working Twitter plugins, why can’t we have one Twitter plugin that does what is needed, in the correct manner, and which everybody can contribute to and look at? We have that with the WordPress core, there’s 140+ people who contributed to WordPress in this last release alone. Why can’t we have that kind of development effort (perhaps smaller scale) for a really good Podcasting plugin? Or a Twitter plugin? Or a Facebook plugin? Or *ANY* plugin?

    Yes, market forces are great, but market forces only work when it is possible to tell which product is superior. The product that works for now, in the short term, is not necessarily the better product, and shoddy plugins are giving WordPress a bad name.

  3. Actually I’d tend to agree with Jay on this one. While most of the plugins suck, they should live & die on their own merit.

    Automattic makes up the core of the WordPress dev team & I personally would rather keep them out of controlling the plugin & theme markets.

    Quality plugins that fill a need are quickly picked up and promoted by those of us that use them. If a plugin sucks & breaks things, people are usually made aware of it quite quickly. If the developer won’t fix it, someone forks it.

    I’d rather that type of marketplace than one of top down control or at least very heavy influence.

  4. Rethink the plugin directory and its design and bad plugins can more easily be detected.
    Setting up walls is not the answer. I don’t like gatekeeping in open source be it WikiPedia or WordPress.

    Heck since WP.org collects everyones plugin info already WP can notify the users that plugin A or B has not been verified to work with this version so suggest disabling it before upgrading or something.

  5. Core plugins are not about shackling a free market.

    There are about encourage people to collaborate and work together for a better solution.

    The large community of WordPress users does not benefit from having 10s of mediocre plugins all attempting to achieve the same thing.

    The would benefit much more if these ten developers got together and worked on one extremely good plugin.

    Open source software succeeds when it has a community of developers and users and this community has ‘ownership’ of the code.

    Core plugins are all about the Lead devs fostering community developed and supported plugins.

    This includes improving the “infrastructure” provided to make it easier for teams to collaborate on plugins and people to get involved providing patches for plugins which add features or fix bugs.

  6. There is no reason what so ever to label the plugins Peter.
    You are going at it totally wrong really. Foster a community instead of labeling its results. What if some people work together on a plugin outside of WordPress.org control sphere, is their collaborative effort any less than a wp sanctioned one? Can’t people not govern by a lead dev write decent code?

    And this obsession with lead devs all the time is starting to get very annoying. Its sounding more and more like if you ain’t a lead dev on WordPress you can’t write decent PHP code for WP. Its not written like that but it gives that impression at least to me.

  7. I understand and appreciate what you’re saying, but I still strongly don’t agree. I understand that most plugins are badly written, many don’t work, and people are overwhelmed by the number of choices, even so I don’t see this as the right course of action.

    Say there are 100 Twitter plugins. Contrary to what you said, they aren’t all trying to achieve the same purpose. Still, many don’t work, don’t work well, are inefficient, may be dropped at some point, and there are a lot of them. With a core Twitter plugin, my concern is that developers of other Twitter plugins will no longer have the motivation and innovation to continue. THE Twitter plugin will hopefully be well written, never abandoned, and will make it easy for someone looking for a Twitter plugin to not have to decide between their choice of the other 100. However, as the other Twitter plugins fade away, you lose whatever functionality they had that doesn’t make the cut into the core Twitter plugin, and we lose the future functionality they would have had.

    I feel that we should discuss other potential options before jumping towards the core plugins route. There are ways we can clean up or reorganize the repository, increase communication among developers, etc.

    Most of the top plugin/theme developers are in communication already, to ensure that our plugins/themes work well together. I’d think an official way of doing that would be a good start, rather than having core plugins.

  8. Westi, you assume that most plugin developers WANT to work together. Most are content to work on their own project, it’s their baby and they want to develop it the way they want to develop it. Does that make it wrong?

    Here is the issue with canonical plugins… the label.

    I have no problem with canonical plugins from the team development perspective. If a bunch of great developers want to get together and product a kickass plugin, go for it. Users will love it.

    However, once it gets special designation it gives it an advantage that the single developer plugin doesn’t have. In the eyes of the average user the plugins labeled “canonical” are instantly going to be special. Anything not labeled “canonical” is going to be questioned or deemed inferior outright for no other reason.

    Thats wrong.

    Am I missing something? Is the WordPress development community broken? I wasn’t aware it was. There are LOTS of bad plugins. YES. But you know what? There are LOTS of good plugins too. You have to take the bad with the good because this is after all an open community where anyone can develop a plugin or a theme.

    I would hate to see canonical plugins end up pissing off large numbers of plugin developers who can’t compete with, or get run out of the market by a canonical plugin.

    Without the large number of developers creating new plugins (and themes) everyday… WordPress would not be as cool as it is. Please, don’t piss them off. I like variety and I like choices.

    I don’t like one option. Don’t chase the other options away.

  9. I do have to thank everyone for engaging in very civil debate on this matter. Obviously I share the opinions of Carl, Michael and Andreas (EDIT: yes, and Ben). Put a little more bluntly, canonical plugins really seems like using a chainsaw for plastic surgery and I stand by my conclusion that the WordPress leadership turn to the community to police each other’s plugins.

  10. I need to reiterate that i’m not against the idea of a bunch of really great developers coming together and creating a plugin. Thats fine, if it results in a great plugin for the user… thats a good thing.

    I’m against giving them special treatment and a special label/designation. The idea of anointing those plugins as superior simply because of who created it.

    As soon as you label one as “canonical” or “core” or “this” or “that”… they are going to question why other plugins don’t have that label. Those other plugins are going to be discounted and deemed inferior by the average uninformed user. Thats just how people are.

    Let the community decide which plugin they like best. Don’t force feed them.

    It seems like they are trying to fix something that isn’t broken.

    You want to know what is broken? The repository itself. Get rid of plugins that are no longer being supported or actively developed. If the plugin isn’t being kept up to date, get rid of it.

    I think there time would be better spent finding ways to make the repository better so it can feature and highlight GREAT plugins that already exist and less time finding ways to compete with those existing plugins.

  11. Speaking for purely personal experience, I think Carl makes an extremely valid point with “you assume that most plugin developers WANT to work together”.

    Whilst it does, of course, make me out as a rather anti-social beast, I’m afraid that when it comes to coding I like to work alone and pretty much OWN the project I’m working on. It’s my code and I know it intimately, it would take me a lot longer to implement something when I have to also learn how (and more importantly) why a particular piece of functionality was coded in the way it was.

  12. Of course there is nothing stopping us labelling ALL of our plugins Canonical as well. Whilst we may not get them listed on wp.org, it may give the user a choice about which “canonical” twitter plugin they want to use 🙂

  13. Carl, you say:

    You want to know what is broken? The repository itself. Get rid of plugins that are no longer being supported or actively developed. If the plugin isn’t being kept up to date, get rid of it.

    That’s exactly the surgery I was refering to. “Plastic surgery” makes it seem surperficial, but it’s also a delicate procedure that requires plenty of care. I love similes.

    Barry: it would be deliciously anarchist for independent devs to call their plugins “Canonical.” 😉

  14. I’m definitely in agreement with Jay here. I’d much rather see plugins exist in a free marketplace, both the good and bad ones and let users make their own choices without undue influence from the top. What is so very “broken” in the plugin community right now that we need Automattic to come in intervene? Why assume that most users need to be hand-held and herded towards the “canonical” plugins? Hell, the abundance of choices, both good and bad are what make WordPress so attractive. I’m sure there are ways the repository can be better used to educate users & help them choose more wisely. I would make the rating system more prominent and add actual user reviews rather than just linking to the forums to start.

    I really don’t like the “gatekeeping” stance here or the implication that only “canonical” or endorsed plugins are properly written or safe to use. Nor the implication that independent developers are somehow second class and need to take a back seat to some “team” effort. Automattic should stay out of the mix, let the market work and if they must do something, find a way to help the users be better informed with their choices.

  15. People are generally lazy. They will go with the easiest solution, and they expect the world. Canonical plugins are going to be nothing but trouble. Giving lazy WordPress users a grouping of plugins that are easy to find, and automatically “trusted”. If they don’t work, who will support them?

    In the end, I think this, like many other moves WordPress has made recently, only serve to continue to lower the bar of online publishing so that everyone can do it, and when everything can do something, it stops being special and meaningful.

    Canonical plugins (and bundled/default themes each year) are nothing more than a way for WordPress to centralize the power and community surrounding the project, and cut out any of the “unapproved” resources that are out there innovating.

    Developers will leave (I hope). Designers will move on (please let this happen) and WordPress, like many mature projects will become fat, and frustrate all of their original user base, rather than the large percentage that are currently frustrated with it.

    I am forever hopeful that the best talent that is held within the WordPress community will move to blogging and CMS projects that are more welcoming of their desires, efforts, and attention, and once those developers and designers move, so will a community of users.

    Otto – Plugins do have quality issues, but great software should help save users from themselves, ESPECIALLY if they are targetting the lowest level of computer users. If you aim your product at someone that barely knows how to use a mouse, then it is YOUR fault when something doesn’t work for them.

    WordPress could do a better job, within its own code, to check for potential faults and save users from themselves, WITHOUT going the canonical plugin route.

    When someone installs a bad application on their Windows computer, and Microsoft Windows starts having issues, people blame Windows, and rightly so. They targetted every computer user, and so they must now be held accountable for the dummies among them. So what did they do? They created a system (though basic) to say to users “are you sure you want to install this?” They’ve worked hard to try to deal with these issues. They don’t say “well, you shouldn’t have installed that application” because blaming users for their mistakes never fixes anything. It just creates animosity.

    I agree that we do need better ranking, comments, tracking and teaching when it comes to WordPress plugins, but if Canonical comes along, what would be the benefit to the average person to learn or to train? Eventually, and I know this is the case, people new to blogging will stick to ONLY using Canonical plugins because there will be an inherit safety feeling, and an understanding, as more people use it, that there will be more potential support.

    The one thing I love about WordPress is that no matter what feature I want, I can get it, and even better, if I try one plugin, and don’t like the features, user interface, or even something as simple as the graphics they’ve chosen for social media sites, I can download and try another.

    When you said it would be nice if we had one great twitter plugin rather than 30 barely working ones, you are creating a system where every user is forced to the exact same user interface, features, and graphics. If you don’t like it, too bad, and that’s not the open source world I’d like to live in. It sounds distinctly not-open sourced.

    You mention having masses of people creating a podcasting plugin or any plugin, yet you don’t mention that adding more people can create other issues. Who decides what features should exist? Who decides when a release goes out? Who decides anything? The structure is not in place like it is with individuals, friends or companies.

    If I don’t like what you are doing with a canonical plugin and decide to fork it, then what happens? Our plugins start out the same, but because you are now an inner circle friend in the WordPress world, yours gets the Canonical stamp and mine does not? If they both get the Canonical stamp, then we have to potentially divide the workforce.

    I think information is the real key, and I think WordPress has done a few great things to help. Letting us check on Extend if a Plugin works with a specific version, being able to see the latest WordPress forum threads about a plugin, as well as stats, release notes, and other details are all great strides in informing users on their options but we need to give the market more time to sort out how useful this information is. We also need more information being shared as an informed user base is an engaged and smart user base.

    Give them details on alternative plugins, give more ways to compare plugins, and maybe put an option for forcing feedback on deactiving a plugin (of course an option that can be turned off for users that never want to leave feedback).

    Create better search, better rankings, better sharing, and information and I think the market will do well without a Canonical stamp.

    Westi – I am all for people collaborating, but I don’t think giving those plugins a stamp that seperates them from the rest is wise. Just ask devs to foster community and release the plugins. If they are good, then they’ll do well on Extend. If they suck, then they won’t do well. It is stupid to promote them over others. One developer could come up with a plugin infinitely better than a Canonical plugin, but the Canonical one will get attention by virtue of being marked as Canonical.

    I have pretty much said what others here have said, but in my own words, and I hope by doing so to help open the eyes of a few more people. WordPress is going to fail if it keeps going down this route. It cuts off its key contributors from surviving in the marketplace. WordPress is losing its way.

  16. @ChrisHajer – Nothing prevents a GPL plugin from being incorporated into the core except the looming threat of bloatware.

    If they were to start incorporating more and more plugins into the core the core would become big and bloated. The support burden would go up, bugs would go up, it really wouldn’t be a good situation for WordPress or the community.

    Plugins have and will continue to be absorbed into the core when and if it makes sense. More specialized functionality and larger more advanced functionality doesn’t make sense to integrate into the core because WordPress is built around a plugin model where this type of functionality is added via a plugin.

    So the only thing preventing any plugin from being added to the core is common sense. Hopefully it stays that way.

  17. I guess a better question would have been “what happens after they take a GPL plugin and call it ‘canonical'”? I didn’t mean they’d incorporate it into core necessarily, just take test best plugin in whatever category, and that plugin is now CANONICAL/CORE (whatever it is called.) It’s still still a plugin, but now Automattic has deemed it “best”.

    I know in the past that Automattic has incorporated functionality that used to be available only in plugin form into the core (examples?), but this is not quite going that far (and thus avoiding bloat.)

  18. I’m always pleased to see David chime in with some well balanced feedback.

    Canonical plugins (and bundled/default themes each year) are nothing more than a way for WordPress to centralize the power and community surrounding the project, and cut out any of the “unapproved” resources that are out there innovating.

    I couldn’t agree more. It’s obvious that certain people don’t like others profiting from the platform. They’re simply trying a little slight of hand to distract people as they push other developers out of the way.

    I also agree with David in that “It sounds distinctly not-open sourced.” After all the preaching about open source, GPL, the spirit of this and that it feels like plain old strong arming and big business as usual.

    If WordPress is going to become nothing more than mind-numbing, run of the mill bloatware then I’ll be glad to move on and devote resources to some other project.

  19. As a developer of plugins, and a user of plugins, I’m both for and against this.

    Everyone above has stated all my major points, so I won’t elaborate. As more of a developer, I hope it doesn’t taper off the ease of contribution to the community and it’s impact. Right now plugins are all on a level playing field. With Core plugins this could shift the entire perception of non-core plugins by users / developers who are new to WordPress and don’t fully understand the concept of what a Core plugin is.

    Perhaps the better term to call these types of plugins would be “Sponsored” plugins, as they would officially be cultivated by the WordPress / Automattic team.

  20. ” It’s obvious that certain people don’t like others profiting from the platform. They’re simply trying a little slight of hand to distract people as they push other developers out of the way.”

    Kevin,

    I respect your opinion and appreciate that you care, but I think we should keep from making these types of accusations. Remember, plenty of non-Automattic employees have significant executive powers regarding WordPress.

    I sincerely believe that the Core plugins idea comes from the best of intentions, I just believe that it’s the absolute wrong thing to do. We all want to do what’s best for the users, and this isn’t it. I’m never for any idea that restricts freedoms and choices.
    We definitely need to improve the current repository and /extend system, but canonizing plugins takes us in a whole new direction.

    Contact Form 7 is one of the most popular plugins, out of 7000+, and the most popular forms plugin in the repository. This is because so many people use it, continue to download it, and recommend it to others. It’s certainly not perfect, but it’s the most popular for a reason. Should Automattic come out with the Core FormPress, people will tend not to use Contact Form 7, CForms II, Gravity Forms, etc.
    Then if their respective developers drop the plugins or spend less time developing and supporting them as a result, what happen if there’s another major security vulnerability in Contact Form 7 and nobody to fix it? What about when Carl decides it’s not worth it anymore to continue creating Gravity Forms and people have tons of forms they’ve created? Do they hope someone comes along to create an import script for their forms/data?

    I sincerely appreciate the motivations that went into the Core plugins solution, but I think it’s misguided. This will handicap innovation, and will unnaturally affect the free market we currently enjoy in the plugins world today.

  21. I appreciate the mention Michael, but everyone should keep in mind that Gravity Forms is a team effort that consists of myself, Kevin Flahaut and Alex Cancado. It’s a team effort.

    See? Team plugin development already exists 🙂

  22. Michael,

    Thanks for the feedback. I appreciate your opinion as well.

    I didn’t really accuse Automattic or any one party of anything. Over time though, it’s become painfully obvious that there are certain groups and influential individuals that don’t believe in the monetization of WordPress plugins, themes, etc. They’re naturally going to use their influence to promote their agenda.. under whatever guise they can.

    If they can use the “canonical plugin” idea to slowly force other developers out of the game, they’ll most certainly have a go at it. It’s politics as usual.

    People can choose to hide their heads in the sand and say it isn’t true, but it doesn’t make the 800 pound gorilla go away.

    As far as good intentions.. I agree. I don’t think that everyone is “out to get us” by any means. I’m sure there are some people who legitimately want to improve the platform and also agree with you that it’s the wrong move.

    Again, I can echo what most of the commenters said and agree that this isn’t the way to go for a multitude of reasons. What is the right thing to do? I’m not entirely sure but ostracizing the development community that has significantly contributed to the growth of WordPress isn’t the smart way to move forward.

  23. Some very good arguments against core plugins has been raised by the developers that the core plugins was meant to somewhat embrace.
    If those that is suppose to be involved with core plugins don’t like the idea of core plugins why go forward with it at all?

    We really need to get a lot of info on this matter. Peter made it sound like it was a done deal. I surely hope its not.

  24. There is one more reason why canonical plugins are colossally bad idea. Who will guarantee that these plugins will be coded well at all? Core WordPress team?

    Current core team needs to focus on the core, and not to take new tasks. They need to find new developers for this, new people to provide support. Why should anyone trust them to make better plugins from plugins already on the market? WordPress core is far from good, and we don’t see another group of developers working the same way on the plugins. Automattic will grow, and will hold many more elements of WordPress centralized, and that’s something that sounds less and less as open source and free community.

    Automattic and WordPress core team MUST drop any idea of labeling plugins and with that developers that made WordPress what it is now, and they NEED to focus on WordPress core and make it much better. Some parts of the WordPress are so outdated, so badly written that many times I needed to write functions of my own to replace core ones due to speed problems.

    WordPress has appalling post/page/taxonomy management that is useless for most larger websites, many admin panels still lack expanding capabilities. And they need to clean up plugins/themes repository from all old plugins, bad plugins, broken plugins and not advertise 8000 plugins when in reality only 2000 at the most should be part of it. They need to work on that, they must not meddle with something that should be left to the community. Don’t fix something that ain’t broken.

    Most of WP developers right now are working on plugins and with WP, and they make a living from that. But for most of us it will be easy to switch to another platform and infuse it with fresh blood and make good plugins for the platform that will welcome new developers, not working against them.

    To Automattic: FOCUS ON THE CORE, leave plugins and themes alone.

  25. While the products are inherently different, this tack is very similar to what Microsoft has done through the years in adding standard features to Windows–web browsers, media players, firewalls, and, recently, anti-virus.

    That said, that still has not stopped the number of alternatives available to the masses–although one could argue that the bundled web browser stagnated growth in that sector, but I would also blame a poor and bloated Netscape product at the time.

    Your points are well-made, but I think there is some value to “sanctioned” plugins while at the same time still having those that improve greatly upon those core plugins.

  26. Most WordPress users don’t have the knowledge necessary to choose a good plugin. If it works, they use it. If it doesn’t, they uninstall it. Things like security, longevity, and upgradability don’t come into play. And these are the things that are holding WordPress back and causing problems for WordPress users.

    There are a lot of people who don’t upgrade or are slow to upgrade. The number one reason for that is plugins. They’re afraid, with good reason, that their plugins are going to break with the upgrade. Plugin quality is variable, with most being really bad, some being okay, and few being excellent. People have issues when upgrading, and it makes them fearful about upgrades. They don’t upgrade, they get hacked. That’s a huge problem.

    We don’t want to kill or deprecate the plugin market or make it any less free. We want to promote collaboration in plugin development, and make it easier for people to choose a stable/secure plugin for some common functionality areas.

    One developer could come up with a plugin infinitely better than a Canonical plugin, but the Canonical one will get attention by virtue of being marked as Canonical.

    First: Core, not Canonical. We purposefully chose Core because its antonym isn’t derogatory.

    To this hypothetical developer, I’d encourage them to get involved with the Core plugin if they offer the same functionality. If their plugin offers different functionality, then they can do exactly what they’re doing now: differentiating with unique features.

    P.S. To everyone mentioning Automattic, you’re confused. We’re talking about WordPress. The majority of WordPress core contributors have nothing to do with Automattic, and core contributors are the people whose voices hold the most sway in decisions about WordPress.

  27. So, other than suggesting users are a bit “thick” and that plugins are the reasons for all of WordPress’s ills and the reason users aren’t upgrading (not 4 URGENT WP releases within a few weeks), it’s a done deal then? The “comnunity” don’t get a say?

  28. Call it core or canonical, or whatever you want. Such centralization leads to a very result where you will make most of WordPress users dependent on a single source for plugins that will be sanctioned by Core team (like it or not, Automattic), regardless of the ‘core plugins’s quality and support. Core team is trying to do something that’s not their job to do, and like it or not that is just plain wrong, and will create negative tensions between plugin developers and core developers who are sanctioned to get the Core/Canonical stick on their plugin. It reminds me of some very dark times that are complete opposite of the free software and open source.

    As many have suggested best solution to the problem is to clean up plugin repository (some good steps are already made with compatibility elements). Core team STICK TO THE CORE, and fix the problems, make changes we all need, don’t meddle with everything WordPress.

  29. And one more thing, let’s face it, but most of the problems with WordPress in the past year or so, are not caused by the plugins but with WordPress. If plugin is causing problems solution is usually simple: remove the plugin. You can’t replace WordPress. And each major release had many problems that should have been resolved before release, like the recent cron job problems with final 2.9 that broke many, many blogs and core team took good 2 or so weeks to release 2.9.1.

    And agian: Core team stick to the core, leave plugins alone.

  30. Mark,

    “We want to promote collaboration in plugin development”

    Surely there are other ways we can do this than have official “core” plugins.

    You mentioned several valid issues, but having Core plugins as fix-all solution doesn’t seem right. If the repository is full of broken or dated plugins, we can tackle that. If a major plugin isn’t compatible with a new version, we can handle that as well.

    “We don’t want to kill or deprecate the plugin market or make it any less free.” Most of us don’t think you want to deprecate the free plugin market, I believe this is being done with the best of intentions, even so, this will do exactly that. It will take away free choice from the user, who will tend to “choose” the core plugin over the alternatives.

  31. Exactly right Michael. There is no reason for core team to involve into plugins. They need just to improve plugin repository and to help community by removing obsolete plugins. Keeping thousands of worthless plugins just for the sake of free market is wrong, because with the core plugins they will do just opposite.

    And yes, 99% of users faced by the choice of sanction core plugin and other plugin with similar functionality will choose core one even if this one lacks some of the functionality because of false sense of security.

    Problem is that decision of releasing core plugins is made by handful of people that are part of the core team without any real discussion with the community making, and with all negative reactions from the rest of plugin developes they still don’t see that what they are going to do is plain and simply wrong.

  32. Mark it seems you try to kill a fly with a bulldozer.
    1: I posted this on wptavern: http://i46.tinypic.com/2q1ylbl.png As an argument against the whole too many Twitter plugins thing.

    2: If the plugins don’t work with WordPress WordPress should disable them. You can’t be sure that Core Plugins will never break anything or be maintained, secure etc.
    Redesign and rework the whole plugin management in WordPress. I’ve already suggested a step for this in earlier talks regarding the whole datasending/privacy mess but it would break plugins that didn’t play by the book you said.
    Heck you can probably make a report feature for plugin upgrading. “I upgraded and site went down these are my plugins” and send it to WP and then compare the data sent with other nonworking wp sites.

    3a: Collaboration can be accomplished without core plugins, sanctioning, core devs, lead devs or what ever. Collaboration is accomplished with better tools and better social networking for people and encouragement.
    3b: Plugin security/stability can be accomplished with better docs and tools that make it easier to test plugins. Also easier reporting for users when something goes wrong.

    [quote]
    First: Core, not Canonical. We purposefully chose Core because its antonym isn’t derogatory.
    [/quote]
    Really I thought it was the poll that chose it. So you’re saying you guys had no intention of following your own poll? 😉

    [quote]
    To this hypothetical developer, I’d encourage them to get involved with the Core plugin if they offer the same functionality. If their plugin offers different functionality, then they can do exactly what they’re doing now: differentiating with unique features.
    [/quote]
    Problem is Core will be considered the best. It is hard to compete with the official supplier.

    [quote]
    To everyone mentioning Automattic, you’re confused. We’re talking about WordPress.
    [/quote]
    Given the large involvement of Automattic in WordPress its not so hard to jump to these conclusions. There is no clean separation of WP and Automattic yet.

  33. Really I thought it was the poll that chose it. So you’re saying you guys had no intention of following your own poll?

    “Core” was my personal favorite, the runaway winner of the poll, and generally liked by the core devs. We weren’t going to blindly follow the poll… anyone who blindly trusts the results of an Internet poll is asking for trouble.

    Problem is Core will be considered the best. It is hard to compete with the official supplier.

    If your plugin does the same thing, then maybe yeah. If it’s a unique twist, then it’s not a 1:1 comparison. And if it’s close enough, why not just become a developer on the Core plugin?

    If the plugins don’t work with WordPress WordPress should disable them. You can’t be sure that Core Plugins will never break anything or be maintained, secure etc.

    Core Plugins will be maintained. That’s the point of having multiple developers on them. They will be secure because they’ll be under intense scrutiny by the community. Because they’ll be maintained, work that people do on them won’t be wasted (like it is if you send a patch to a plugin that isn’t actively maintained).

    Plugin security/stability can be accomplished with better docs and tools that make it easier to test plugins.

    That’s incredibly optimistic. It’s a free market. That includes the freedom to be mediocre. As long as they can be medicore, a large number will be.

    Redesign and rework the whole plugin management in WordPress.

    Collaboration is accomplished with better tools and better social networking for people and encouragement.

    These are also ongoing projects. Don’t think that Core plugins is the only path forward. We’re hoping that Core plugins will stand as examples that other plugins can emulate and strive for, with regard to code quality, security, collaboration, etc.

    Such centralization leads to a very result where you will make most of WordPress users dependent on a single source for plugins that will be sanctioned by Core team (like it or not, Automattic)

    It’s not a single source. The plugins will be developed by different teams of plugin developers. There were 140+ core contributors to the last WP release, and the vast majority have nothing to do with Automattic. It’s not going to be Automattic making these decisions.

    will create negative tensions between plugin developers and core developers who are sanctioned to get the Core/Canonical stick on their plugin.

    So join them. Or propose a new “area” for a Core plugin to cover. There are only 12 plugins that have more than 1% penetration right now… WordPress plugin developers are used to their plugins being unpopular. We’re giving them a chance to join forces and create an amazing (and likely very popular) plugin.

  34. Mark, all this is still far from convincing. You say that core plugins will be example code quality, where WordPress is far, far from that. If you already have over 100 core collaborators, why not start fixing things in WordPress first, before undertaking new plugins. Many areas of WP are badly in need of rewrite and cleanup and you all seams to avoid that and praise WordPress: Code is Poetry. Maybe it is, but not for WordPress.

    Last year and a half I have been developing GD Star Rating plugin, and now I have started to rewrite many elements from scratch to improve the code, speed it up and add new functionalities. I can admit that some part so that plugin need to be changes and improved. Why is so hard to admit that same needs to be done with WP, and than do it.

    Core developers need to take care of the code, and leave plugins to us, plugin developers. Few years ago when WP was starting, plugin developers were driving it further, expanding it. If it wasn’t for them, WP would never be what it is now. If you taking plugins from us is your way to say thanks, than WordPress is going through very dark period indeed. And 140 or 200 plugins to join the core team is still fraction of all developers. Expanding core team is not something that will work. Open source projects, free plugins work best with small team and individual developers.

    I am afraid about WordPress future if things progress (or better regress) like this. I am afraid of what team will take on next.

  35. Mark, so basically you’re saying either join the CORE movement or suffer the consequences?

    And please, drop the guise that Automattic doesn’t control WordPress. Everyone participating in this discussion is intelligent enough to see through that.

    You mention that it’s a free market but it becomes decidedly less free with you guys shoving the Core plugins down the communities throats like this.

    You’re opening the market to even more politics of who is buddies with someone on the dev team or who’s in good with Automattic and can get the Core label first. How is that going to be good for the community?

  36. Mark,

    I don’t doubt your intentions are good. I understand you want to produce the highest quality plugins possible. Thats understandable, and that is good for the community as long as it isn’t at the expense of the rest of the developers in the community.

    Not all plugin developers want to work as a team. Some are perfectly content plugging away on their own projects and they see it as a labor of love. There are A LOT of bad plugins in the repository but frankly there are a LOT of good plugins also.

    The concern here has nothing to do with great plugins being introduced. The concern is giving these core plugins a label so they are instantly elevated above all others… existing or new.

    Giving them a special designation “Core” and special promotion on WordPress.org which will come at the expense of other developers who have been contributing to the community with their own solutions… which will now be viewed as inferior simply because they aren’t “Core”.

    That is what will happen. The average, uninformed user is going to question anything that isn’t “Core”. Just because it’s not “Core” doesn’t mean it is inferior. But that is how they will be viewed.

    Thats the primary concern, at least from my perspective.

  37. Ben, Let’s keep this civil and relevant. Worn out Automattic accusations won’t get us anywhere. The point is to do what’s best for the WordPress project, users, and community, not to sling around tired accusations of corruption and impropriety from Automattic. (Mark is not an Automattic employee.)

    Carl, the issue shouldn’t be team vs individual plugins. Team doesn’t mean better, neither does individual. The issue is that by having officially sponsored plugins, users will deem others in the field inferior, resulting in less motivation by other developers and less innovation.

    I refer to my earlier Twitter example above.

  38. Yes Michael. Core team can be free to develop whatever they want, and many core members make plugins. But why they need to label them? That’s unfair part of all this, and they need to drop such classification and favoritism.

  39. Problem:
    It’s hard for people to find good plugins.

    Solutions:
    1. Improve the WP.org page. It’ll make it easier for users to find the plugins they want.

    2. Improve the “Plugins > Add new” page within WP itself — to reflect the WP.org plugins page.

    There is absolutely *no* need to bundle plugins into the download package. Save the bloat, and save the plugin developer community from enduring this favoritism.

  40. There is absolutely *no* need to bundle plugins into the download package.

    Nor has anybody suggested doing that. That is not what is meant by ‘core plugins’.

  41. It seems to me that those who are opposing Core Plugins believe that their implmentation will lead to some unintended consequences, while those who are promoting them do not.

    It is these unintended consequences that are the critical issue with implementation.

    I see no reason whatsoever to doubt that the intentions behind the idea are good, or to believe that there are some ulterior motives.

    That said, I believe the concern regarding unintended consequences is valid.

    Certainly, the *intent* of Core Plugins is not to stifle competition in the plugin development market; however, for the functionality encompassed by such Core Plugins, that is precisely what will happen, sooner or later, if Core Plugins are not implemented correctly.

    Certainly, the *intent* of Core Plugins is not to drive plugin developers out of what is currently a commercially viable market; however, for plugin developers dependent in part or in whole upon support contracts sourrounding their plugins, that is precisely what will happen, sooner or later, if Core Plugins are not implemented correctly.

    I’m sure there are other unintended consequences as well – and I think it would go a long way for the developers to hear from Mark et al how those unintended consequences are being anticipated and mitigated.

  42. Personally I see this as a much bigger issue Chip. It’s restricting (or shackling to borrow Jay’s title) the free market.

    Not to get too political on you, any time freedoms are given up it’s an issue, no matter how benevolent the intentions are.

    But really, I think this issue highlights a much bigger problem. WordPress.org is supposed to be COMMUNITY driven & a separate entity from Automattic, not one that is subjected to their agenda. We as a community shouldn’t care what Matt’s take is on the GPL because it shouldn’t drastically impact anyone’s lives.

    It’s obvious that a large portion of the plugin developer community is against this move, and yet the lead devs (the majority of whom are Automattic employees) are essentially saying “Join us or face the consequences.”

    I know Michael Torbert thinks this is just “tired accusations of corruption and impropriety from Automattic” but it’s really the heart of the matter.

    Either WordPress.org is a top down entity where the lead dev team controls the community, or it’s a community driven organization.

  43. @wpblogger:

    I’m pragmatic more than anything else.

    The plugins in question are GPL. So, technically speaking, the WP core devs can do whatever they want with them. Doing so does not somehow infringe upon or restrict the existing freedoms of either users or third-party developers.

    WordPress *is* a top-down entity. The community controls nothing, and in a lot of ways – including core development, has very little influence.

    I say both things entirely objectively, and without value judgement. That’s just the way things are currently.

    Up until now, that environment has led to an incredibly solid platform, and has not prevented or stifled a thriving third-party developer community.

    But, with the unintended consequences regarding core plugins, things very well could change.

  44. Hey Jay! I’m always happy when you write about WordPress. 🙂 Would you mind adding this comment as an update to the bottom of your post?

    First a disclaimer: I’m probably one of the biggest free market nuts you know. In fact in college I focused on economics and political science/philosophy.

    That said, I didn’t finish, and let’s be honest I wasn’t the most studious guy in the world. Maybe I missed something important. Although I’ve thought about this issue endlessly, including most of the issues raised here, there are some things brought up in the comments that I haven’t thought about before. More importantly, you could be right.

    That’s why we’re doing this whole thing as an experiment; not the Large Hadron Collider type that could potentially destroy the universe, but more incrementally with just three initial plugins.

    The first, health check, is one that’s entirely new, a collaboration between some existing core folks and some new contributors. The second is existing core functionality, post by email, that we’re taking into a plugin to make core lighter, faster, and less bloated. Hopefully it will improve significantly too because we’ve got some really cool new code from it being donated from the WP.com side. The third, PodPress, is an existing plugin that is very popular in the community and provides important functionality but has effectively been abandoned, so we’re going to adopt it and modernize it so people who rely on that plugin aren’t stuck on old versions of WP.

    Something new, something old, something borrowed… something blue? Yep: Kubrick. 🙂

    Now if in the course of working on these three plugins it looks like we’re going to cause the end of WordPress as we know it, we’ll change course. It’s not that big a deal, and we’ll figure something else out. The only dangerous course of action is doing nothing at all.

  45. Thanks for the reply Matt. Thanks for jumping into the discussion.

    I know some of the comments to this post have been extreme, and certainly many are an overreaction to the situation. From my perspective I don’t see anything wrong with the creation and release of the plugins by a team of developers working together. I’m sure it will result in some fantastic plugins.

    However, i’d just like to see it done in such a way that it doesn’t come at the expense of existing work.

    Once you start applying a label to these plugins, be it canonical, core, etc. and promoting them as such you are elevating them above the playing field. It will make it more difficult for single developer plugins to compete against core plugins because they will be at a disadvantage that they don’t have the fancy label.

    So why not just produce the plugins and release them like any other plugin. If they become the definitive plugin in their category let them do so based on merit, not based on them having a leg up because they were promoted and labeled as definitive.

  46. Matt,

    Thank you for responding. You’re constantly levelheaded in replying to issues.

    Core plugins that take over abandoned plugins (such as PodPress) or remove functionality from the core code to make it lighter, or add new functionality is one thing, but the way it’s been presented is that this is the solution for there being 7000+ plugins in the repository, most of which being badly written or just broken. Again, I reference my Twitter example. 🙂

    I strongly believe that this needs to be discussed more and in a more public manner than just a few dev chats, and needs to be better thought out and planned how it will work, with greater input from the extended community before moving ahead with it.

    Thanks again for addressing this here and for taking this seriously. 🙂

  47. Carl has single out the bottom line of this discussion: labeling the plugins. Core developers make plugins already, and they will do so in the future. But these plugins MUST NOT BE LABELED differently than any other plugins. No core or canonical or whatever new word you guys will came up with next. Release the plugins on the same terms as all the others and let them compete in the market. Don’t cripple the rest of the developers by slaping stickers on some plugins. And cleanup existing repository, that will make lifes of both users and developers easier.

    And, Matt, happy birthday!

Comments are closed.