I'm not gonna say forking is always the answer, or that it doesn't sometimes suck for the project as a whole when some people go one direction and some people go another, but I'm inclined to agree with the spirit of your comment that the ability to do so is a feature of OSS, not a bug.
This is a blog post written from one side (and a side I'm generally more sympathetic to) but no doubt when it is a major break between two factions, especially "founders" versus "maintainers" there are obviously two sides to the story, and the great thing is that one side doesn't always have to "win"
I came here to say this. This is the strength of the OSS model! There are a lot of ways that I believe OSS to be flawed (mainly fragmentation) but I'm not a dev and I'm not fixing it so I don't complain. But when I see things like this it makes me realize that there are huge upsides to Open Source licenses that make this possible.
Another case in point: CentOS and its new forks that are emerging.
You are expecting that both projects will thrive? Maybe. I'm not familiar with the product, so I couldn't say what the chances are, but it doesn't seem obvious to me in this scenario.
Whatever the intentions of any party the result is a OSS codebase splitting in two because they don't agree on the future of the project. That is exactly what is supposed to happen when that problem arises.
This is completely user-hostile and bordering on malware now. Though by your insistence of saying "OSS" I have a feeling you and GP don't actually care about software users, only developers.
How? Users [0] are free to either go with October's new direction or switch to WinterCMS, which seems to be fully compatible and a minimal change as of now. Thanks to this, users can now actually choose which way they prefer, instead of being forced in either direction!
[0] As in "developers using the CMS"; for actual users of projects based on the CMS, absolutely nothing changes.
Not every user monitors every single goings on with their software. There is also no mention of the software becoming proprietary on the October CMS website. Users shouldn't have to keep tabs on their free software for fear of it becoming proprietary due to a hostile takeover.
Are you talking about the fork or the original project? I agree the original project's move is a bit user hostile as it now requires people to pay immediately if they want to continue receiving updates. However, I don't see how this can be 'bordering on malware'
That being said, it is the right of the maintainers to fork the software as allowed by the Open Source license the original code was under. Users now have the choice of paying the original company or using the free version with a new name. I fail to see how this is user-hostile.
As someone who doesn't own software I buy from major companies, but continues to collectively own old versions of October CMS, I don't feel much malware. There's still a good deal of actual software here.
How is it a hostile takeover? One group has decided to continue development in a different direction. Others have decided they want to continue on the current path.
For some context: October CMS, a popular PHP Content Management System (CMS), has switched from open source to a proprietary paid model [1]. Winter CMS is a fork of the October CMS codebase to continue development of the CMS as a open source project.
The new pricing model for October CMS is cheap, but no longer open source:
- $9 per project
- $150 for unlimited projects
For comparison, Craft CMS, a popular commercial CMS also written in PHP, charge $299 for a licence for a single project.
This characterization of Craft is incorrect. Single-user “solo” projects are free, which would make it less expensive than OctoberCMS. [1] Additionally, OctoberCMS charges $97 as an add-on for support for its projects, something that comes with the $299 pro charge for CraftCMS.
It’s more agency projects that have that cost; additionally, Craft receives fees from paid plugins that have their own separate support infrastructure.
I personally use Craft for my website and chose it over OctoberCMS, though I had given October a close look when I made the transition two and a half years ago.
Problems and support are somebody else's business.
For example, I don't want to be IT support for my company's WordPress installation.
I am willing to pay $100 per month so that I can tell the VP of Marketing "Please go talk to the nice people at <Wordpress Provider> about why the two buttons in that theme don't align to the same right margin. Tell them to send me an email if something needs analyzed on our side. KTHXBYE."
I also don't want to have to navigate the blizzard of AWS required in order to implement something that won't fall over when 3 canaries and pigeon decide to bang on it--let alone if HN features it.
From experience most of the time it’s a smooth talking sales manager from a commercial CMS company going in and selling a dog to corporate IT with promises of security, scalability and “cost efficiency”.
I’ve been on the delivery end of numerous contracts like this over the years. The early big red flag is when you as an organisation are asked to send multiple developers on £xk per day training courses out of your own pocket so they can become “certified”, with the promises of lucrative long term contracts. Ultimately this always ends badly in my experience.
I'm assuming you're talking about CMS in this "space", which is to say likely used by small to medium sized companies. Others have spoken to that already.
That said, just to make sure you're aware, some companies pay hundreds of thousands if not millions of dollars (I don't know first hand about millions, but I know hundreds of thousands is easy and I'd easily guess million+ isn't unheard of) annually just in licensing for "enterprise" CMS.
In the case of Craft, paying for a better starting point for the content model and editing experience we want to provide. It saves time, in other words.
I’m not really answering your question here, but the best PHP CMS IMHO is Processwire, bar none, and I’ve used pretty much everything under the sun over the last 10+ years. Nothing else gets out the way and let’s you get on with the job in such an elegant way. I like their model as well, they essentially support their development through useful and elegant commercial plugins for things like caching, form builder, pro drafts, etc. The caching module is really worth every penny and then some.
It’s got a beautifully simple API and templating system that really lets you tackle and manage projects how you want to tackle them.
We’ve had production sites with thousands and sometimes tens of thousands of daily hits running off it for nearly a decade and had pretty much zero problems with it that I can remember. I’m confused why more people don’t use it. Sometimes I wonder if people like to make their lives difficult and use the latest shiny new thing just so they can use the latest shiny new thing.
We’ve even utilised it in non traditional ways as well, due to its flexibility - for instance we developed a few games (UE4 and Unity) for clients where we set up and managed various game properties for objects, enemy behaviour, etc. that games could then easily pull in dynamically as JSON allowing a quick and easy way for non developers to play with underlying game variables while play testing with no real programming experience. The simple tree hierarchy system, supplemented with things like repeaters, standard fields and in built selector functionality really makes it easy for anybody to get a handle on it in under ten minutes and feel at ease.
We’ve integrated it with horrendously bad client SSO systems with minimal effort as well, to speak of it’s somewhat fringe abilities.
The community is great as well, no politics and very active.
Disclosure: I’ve got no commercial interests in it, other than it’s made day to day life much easier and I’ll sing it’s praises at any opportunity.
TBH, I probably would have approached this differently. When we’ve had big datasets, we’ve spun them out into another database entirely and just used Processwire for routing/API/business logic/hooks/security/etc. and hand cranked some DB queries as needed for the underlying data layer. Amazing to see what they did though.
I had never heard of Processwire and it does look interesting.
I have worked primarily in Drupal or just directly in either Symfony or Laravel. Drupal 8 has a pretty sophisticated cache API and reading through the ProCache module description it sounds pretty similar (except that it appears to lack cache tags?).
Anyway, I certainly wouldn’t call Drupal or WordPress “the latest new thing” and in my experience at least Drupal does a solid job of getting out of your way as well.
I hadn't heard of it either and I did what I thought was a comprehensive review of PHP-based CMS platforms a few years ago for a project. This may answer your question of not understanding why more people don't use it.
Craft CMS has super flexible content modeling capabilities, GraphQL, i18n, a nice permissions system to put content behind a login, database migrations, multi-environment config, and can be extended since it's built atop Yii2 (an obscure but solid MVC framework). There are no themes, you bring your own markup. It has a CLI for common tasks.
You'd need to install several plugins to pull this off in WordPress, some of them paid (ACF Pro, etc.). And it's messy because the plugins weren't made to work together. Craft also supports Postgres in addition to MysQL/MariaDB, so that's another difference if you like or need PG.
It's more similar in scope to Drupal, but I find the developer and authoring experience much more elegant in Craft. Businesses are happy to pay $299. Both systems use Twig as their templating layer.
For reference, content management systems that target the mid-market and enterprise charge $XX,000 and up for licenses. See Sitecore or whatever Adobe is shilling these days.
There are hundreds of CMS options out there, lots of interesting approaches to choose from. Strapi and other headless JS-driven options are the current rage.
Source: I'm in the Craft pro network but have built 50+ WordPress sites as well. Prior to that I used ExpressionEngine, Textpattern, and Movable Type. Been around the block!
Disclosure: I'm a Winter CMS maintainer and former October CMS maintainer.
I wrote the "Features for Developers" page (https://wintercms.com/features/for-developers) on the Winter CMS site, which pretty much summarises my thoughts on the advantages of Winter CMS development.
I was using October CMS for years before I became a maintainer, and the thing that hooked me was the plugin architecture. It is incredibly simple to extend nearly every facet of the CMS to do what I want for my clients.
I've developed (and still do) develop WordPress sites, and I find trying to "extend" or customise some plugins to be like pulling teeth if they're not using the hook system correctly.
The fact it's built on, and supports most of the API of, Laravel is a bonus to me too.
I've dabbled a little in Drupal but don't have enough experience to give a good comparison in between those two.
I'm a little confused. Of the commits linked which seem to be the "breaking changes", two seem to be entirely documentation updates that are 90% changing the title casing.
The remainder seem to be around updating the pipeline/other files to specify support for php 7.2-7.4 instead of 7.4+8.0 and a bunch of other documentation (phpdoc) changes.
October 2.0 was based off of the code base as of a year ago, so everything that was added to the project in the past year was removed in 2.0. As far as breaking changes in the 1.0 & 1.1 branches go the links are mostly talking about the docs changes that indicated the removal of the recent changes; but there are some that actually cause problems for current projects that aren't upgrading, such as the removal of the wikimedia-merge-plugin which is required for plugins to load their dependencies smoothly.
Fancy user and tiny contributor of October and now Winter.
I've been really disappointed when I hear the split of the project, then I finally understand both decisions here:
- October became paid to generate more money than only fees from the marketplace
- Winter will keep the project open source and hope that the marketplace and donations will be sufficient to make the project live long.
What's made me decide on which side I wanted to be was not the fact that the platform is paid or free, but more the fact that only one project will now consider their customers as developers and potential contributors.
On the October's side, you'll now just pay for a program that you'll run on your server as is, you could still develop custom plugins but the new features will now only be developed by the two creators (including one that I've never had the chance to discuss with or even read in two years of contributions). You now just can propose new features and hope that the developers will agree to develop them without any due date.
On the Winter's side there are 4 friendly developers, a world-wide active community and they've always been open to any contributions, including new features. The maintainers are focused on adding new features meanwhile asking for beginners' feedbacks to ease the introduction of new community members (and potential future contributors).
My thoughts is that October as of today is one step higher of Winter because they released a new fresh backend with some new (only front-end) features secretly developed by the creators without even telling it to the maintainers but Winter is already way more active into the development of new features due to the fact they can be added by anyone from the community.
I expect both project to live but the community of both projects will now include different kind of members, October's one will be full of customers, Winter's one will be full of contributors.
Please don't understand this as an offense. We have a lot of open source php cms systems already (e.g., drupal, typo3, joomla, silverstripe, ezpublish, ...). Is there anything incredible that october or winter cms has to offer to the world, which is not already provided by competitive projects?
Compared to Drupal/Joomla/WordPress, I find October CMS faster, more powerful and easier to work with (Laravel)—you just have to try it yourself and see. After watching Rapid Application Development with Builder: https://vimeo.com/154415433 a few years ago and creating a plugin myself, it clicked and I was hooked.
The main selling point of October is that it is based on Laravel/symfony. For PHP developers who are already familiar with Laravel/symfony, that is a big advantage over other box software. I understand that Drupal began using symfony with v8 as well. The Drupal team also clearly sees the advantage of using existing, time-tested, and robust technologies.
Yes absolutely understandable! Although, if I look at the "Projects using Symfony" website, it seems most popular CMS systems are using at least the components (https://symfony.com/projects)...
Going paid is their fair right, there's nothing wrong with that. On the other hand, forking the project and immediately shitting on the years of work and community building of the upstream with toxic blog posts seems very childish.
I'd rather support a closed source project than a community that actively promotes toxic behaviour.
MIT isn't a copyleft license, they are free to take it closed source and all future changes can be proprietary. What they aren't able to do is "change" the existing license, and for example, sue WinterCMS for forking the project.
Good for Winter CMS for continuing development of the OSS version.
This is an example of the system working.