One of the disadvantages, balancing the many advantages, of a lean system, like Grav, that keeps a tight core and depends on plug-ins for some functionality is the plug-ins.
Features in the core are developed and maintained by the people who build the system. People who will be around as long as the system is and who are talented, professional developers—otherwise the product would never have existed in the first place.
Plug-ins, not created by the core developers, may well be created by the opposite: not around for long, not experienced developers, and not with the success of the base product at heart.
What’s a full stack (HTML/CSS/PHP/JavaScript) developer to do?
Time spent developing functionality via plug-ins is time not spent on client work. Depending on third-party plug-ins for important functionality can lead to a world of hurt—other people’s bugs, critical failures on client projects (think of a breaking Grav update and a plug-in abandoned by its developer), quirky non-standard (from the core platform’s point of view) configuration or behavior.
This is n ot a problem for Grav to solve, nor its it a criticism… There are a lot of other products that work the same way, some very popular code editors come to mind—Sublime Text, Atom, Textmate.
I did want to raise the issue and see how others manage important parts of their tools, be they editors, IDEs, or CMSs, that are plug-ins.
As you say this is not a question unique to Grav, this is something that every CMS or even, any extensible application has to face.
Two of the most well established and popular CMS platforms currently available, WordPress and Joomla follow this model and it has worked fantastically well. Joomla has nearly 9000 plugins, and WordPress has over 35,000 plugins!
Sure some of those plugins are of lesser quality than others, sure some are abandoned, but there are still many quality options available. Entire businesses have been built around providing those extensions and themes. RocketTheme is just one example, but there are hundreds if not thousands more.
Grav is a very young project, but we wanted to ensure that it could stand toe-to-toe with any other platform out there when it comes to extensibility. That is why we put so much effort into the plugin system, and also the GPM (Grav Package Manager). There is no other flat-CMS with anything like it, and frankly it’s already better than most mainstream CMS systems, and we have plans to improve it even further.
Also, the Grav team has already created quite an assortment of plugins to provide important functionality for Grav. Just because it’s not in the core, does not mean that the Grav team is not developing and supporting plugins. The primary reason we don’t dump everything in the core, is that these plugins are not always needed, and we would prefer to keep Grav with the essentials that everyone needs, and then provide plugins where functionality is required. This allows everyone to have as little or as much functionality as they need. Even projects like Joomla are slowly removing much of their core functionality (ie weblinks) because there are better 3rd party plugins available.
My hope is that because we’ve provided so many plugin examples, with solid documentation we have shown how easy and how powerful Grav plugins can be. And based on this, the Grav community will continue to build and provide quality plugins as that community grows in size. We have nearly 30 plugins already, compare that with more established projects such as Statamic (24 with many of those in Grav core) and Kirby (23 again some of those provided by Grav core).
I agree that Grav is a product with nothing but open road ahead and has already improved upon its key competitors, Statamic and Kirby. And I’m convinced enough that I’m moving my projects (few as they are) plus any future projects to Grav, if I don’t have the complexity involved to justify a database. A database is a “bag of hurt,” as Steve Jobs famously called the HD DVD formats.
For Grav, I’m looking forward to paid plug-ins coming, especially from RocketTheme. For one, Grav needs some income so that it can be sustainable. And two, a paid-for plug-in may well have better support and longer life from third-party developers. If I’m going to add key functionality via plug-in, I want to be able to depend on it. And I don’t want to be held back from gaining the advantages of future Grav versions, if moving Grav ahead breaks someone’s plug-in.
I wrote the start of this from frustration with the development of the Atom editor. It, too, is young but growing fast. And it, too is keeping its core lean. But its linter for SCSS broke somewhere around Atom v0.166.0 and hasn’t bee n fixed yet. It’s starting to look like its developer has abandoned it. Too bad, because with it in existence no one else saw the need to create such a linter. Now we have to wait for someone to notice that the last one is dead and start a new one.
The Markdown mode for Coda works only but so well. Its developer is too busy to make improvements now and there are no others as of yet.
I could go on.
The good news is that Grav is fresh, young and already attracting third-party developers.