via make.wordpress.org => original post link
The plugin directory is great, but many plugins are controlled by a single dev or company, and often end up going a direction of a premium or pro version, sometimes even removing functionality that used to be in a plugin and pushing it into the pro version. This can also create an incentive to put something into a SaaS service that is easily done in a more distributed fashion locally to the site. Even accepting donations can create some weird incentives for how to divide those among a number of contributors.
WordPress itself thrives because it’s a collaborative effort of many people with many varied interests, but coming together to create something that is explicitly open source, free, and available to all. We need to evolve the plugin directory to make it easier to accept code and documentation contributions. (We’re pretty good with translation contributions already.) Also I think we should build on the successful history of canonical plugins like MP6, Gutenberg, and REST API to have more community-developed plugins, called canonical because they will be the official first-choice recommendation by core and w.org for an area, that share in the ethos and approach of WordPress itself but to a more niche area that might not be right for core.
We are reaching a point where core needs to be more editorial and say “no” to features coming in as ad hoc as they sometimes do, and my hope is that more Make teams use this as an opportunity to influence the future of WordPress through a plugin-first approach that gives them the luxury of faster development and release cycles (instead of three times per year), less review overhead, and and path to come into core if the plugin becomes a runaway success. I am very conscious that when people are aiming to have something in core, a “no” or “not now” can be frustrating and sometimes create artificial pressure to put something in before it’s ready, as I believe happened with the REST API in WP 4.4.