October CMS as you know it is dead(wintercms.com)
wintercms.com
October CMS as you know it is dead
https://wintercms.com/blog/post/october-cms-you-know-it-dead
61 コメント
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"
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.
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.
What "system", besides a hostile takeover of a software project?
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.
[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.
It mentions their move to paid only on the homepage.
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.
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.
What is hostile? If they own the IP they can do whatever they want with it.
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.
[1] https://octobercms.com/blog/post/october-cms-moves-become-pa...
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.
[1] https://octobercms.com/blog/post/october-cms-moves-become-pa...
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.
[1]: https://craftcms.com/pricing
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.
[1]: https://craftcms.com/pricing
[1] previously, though with no discussion: https://news.ycombinator.com/item?id=26859554
Also originally submitted here https://news.ycombinator.com/item?id=26939729
It boggles my mind that someone pays for a CMS. Given the abundance of free options what are they paying for?
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.
I imagine that the CMS space is quite similar.
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.
I imagine that the CMS space is quite similar.
Yeah, but Wordpress is an open market, it's vast and very competitive. Other CMSes don't look attractive in that regard
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’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.
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.
I can only assume that a lot of work by salespeople was performed in every single such case?
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.
What are some advantages of these CMS compared against other free CMS solutions like WordPress/Drupal?
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.
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.
I'm a happy Processwire user since 2013. For me it took away the complexity and pain of creating customised sites with CMSes.
If you wake up one day and decide you want to shove 20 million proteins into a Processwire site as individual pages, the community will immediately jump in and help you do it: https://processwire.com/talk/topic/25444-creating-20-million...
If you wake up one day and decide you want to shove 20 million proteins into a Processwire site as individual pages, the community will immediately jump in and help you do it: https://processwire.com/talk/topic/25444-creating-20-million...
Wow. I’m kind of lost for words…
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.
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 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.
I only used it for small projects and can confirm that it's spectacular for that use-case as well.
Using it just as an API is also very nice.
Using it just as an API is also very nice.
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!
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!
Adobe charges 300k a year for a big setup, but they do handle cache without a hickup.
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 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.
Are you Luke? If so thanks for showing me that nifty British restaurant! We should grab a bite again once this whole pandemic thing is all over.
Hey Tony! Not sure who vanilla-almond is, but I'm the Luke Towers that wrote the post and leads the Winter CMS project :)
Definitely should grab a bite again, although unfortunately that restaurant has closed :( Hit me up on the HackRegina Slack some time!
Definitely should grab a bite again, although unfortunately that restaurant has closed :( Hit me up on the HackRegina Slack some time!
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.
What are the drastic breaking changes thusfar?
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.
What are the drastic breaking changes thusfar?
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.
And wait ... they create bugs in the 1.1.x branch with the 2.0.X and encourage users to migrate to avoid them :
"If we discover what broke it, happy to backport the fix, but it appears broken due to some introduced reason that I'm not aware of
...
Please test in v2.0 and let me know if it still happens. Thanks"
https://github.com/octobercms/october/issues/5560#issuecomme...
"If we discover what broke it, happy to backport the fix, but it appears broken due to some introduced reason that I'm not aware of
...
Please test in v2.0 and let me know if it still happens. Thanks"
https://github.com/octobercms/october/issues/5560#issuecomme...
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.
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)...
Movable Type did this in 2004 and was never heard from again. Their users fled to WordPress.
now there's a name I haven't heard in a long time...
Loved octoberCMS as it let me basically code my website structure and the complete* HTML directly from its admin interface.
*the actual complete HTML! No CMS cruft or anything added to my websites pages I dont want to be there.
If you are looking for a CMS and have some coding skills I think you’ll very much enjoy working with this one.
Will be looking into how to update my websites to WinterCMS then.
*the actual complete HTML! No CMS cruft or anything added to my websites pages I dont want to be there.
If you are looking for a CMS and have some coding skills I think you’ll very much enjoy working with this one.
Will be looking into how to update my websites to WinterCMS then.
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.
I'd rather support a closed source project than a community that actively promotes toxic behaviour.
We use October as the core of one of our internal products. I'm hoping the people working on it are aware of all of this :o
Not very smart to do this while they don't have much adoption.
Going closed source with something directly derived from MIT-licensed code contributed from the public seems... not very legal?
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.
Hooray for open source.
[deleted]
Good for Winter CMS for continuing development of the OSS version.
This is an example of the system working.