(very basic question) - Winter CMS vs October CMS

[KB-WEB-DEVELOPMENT]

Hi,

as someone who has paid for an October CMS single license and is slowly but firmly familiarizing himself with that CMS, I am
still puzzled as to what are exactly the advantages and disadvantages of October CMS over Winter CMS (and vice versa).

Thank you for your time.

K.

[LukeTowers]

@KB-WEB-DEVELOPMENT thanks for your interest! While the advantages & disadvantages of Winter vs October somewhat depend on the use-case, here are some initial ones that I can think of off the top of my head:

October CMS

Advantages:

• Funded by licensing core & marketplace revenue, paid full-time staff working on the platform
• Features driven by paying customers
• Marketplace is currently functional
• Tailor
• "Multisite" content support
• Nicer repeater widget
• Bootstrap 5 backend

Disadvantages

• Not free, not open source
• No support for running on Laravel Vapor
• No core support for Laravel Mix / Node / NPM
• Winter plugins unlikely to work on October

Winter CMS

Advantages

• Open source & free, backed by Frostbyte Foundation Inc., a non-profit
• Most October plugins work fine on Winter
• Features driven by community and requirements of the core maintainer team
• Core support for Laravel Mix, Node, NPM asset compilation
• First party support for AWS & Laravel Vapor (including streamed file uploads direct to S3) Winter.DriverAWS & Winter.Vapor along with many changes to the underlying framework to support those use cases
• More extensible via Plugin Forking, scoped dynamic class extension
• Snowboard.js vanilla JS framework
• Official VS Code extension
• Tailwind Backend
• Rich collection of first party plugins (Blocks, CloudFlare, Docs, the Driver plugins, Excel, Ignition, Notes, Matomo, PwnedPasswords, Ray, Redirect, Search, SEO, SSO, etc - with more always in development and a wide variety of community provided plugins)

Disadvantages

• Core team all works on it unpaid, so it can take longer between new versions (develop branch is always frequently updated though)
• Plugin marketplace not available yet (should be by the end of this year finally now that we have our new website and docs up and running though)

This is purely my own personal thoughts and opinions, so take it as you will, but I see Winter's progress being more focused on developers building products for users and October's progress being more focused on designers building websites. October seems to be focused on being a great Content Management System for agencies to use while my own personal vision for Winter is to be the world's best Content Management Framework that can power everything from basic marketing sites built by agencies to complex multi-tenant SaaS web applications with global reach.

Let me know if you have any other questions!

I'm curious to know, what use cases are you evaluating October vs Winter for? I always like to know what people are using / looking to use Winter for.

[bennothommo]

It's definitely difficult to be objective when, a) I'm a maintainer of Winter, and b) I have not used October since the fork and can only glean from certain announcements and what they still keep "open" source and what sneaks past their blocklists... but on top of what @LukeTowers posted above (of which I wholeheartedly agree with), some other metrics to consider:

• Version releases: October operates on semantic versioning, and they release versions much more frequently. They appear to be slightly more accepting of backwards compatibility breaks. Winter releases are much slower (following more like an "operating system" type of release) but generally providing more value and being backwards compatible is one of our core goals.
• Third-party plugins and themes: Given October has been available for much longer, their available plugins and themes for use are substantially higher than Winter's, and having the marketplace helps them tremendously too. While we have made some effort to ensure that October plugins work with Winter (or have a graceful transition path), the reverse is not the same.
• Communication: October's maintainers communicate in the dark. As far as I've seen, it's only through email and through some support system on their site, and besides their Features portal which only gives vague statuses, no one knows which direction development is going. Winter, on the flip side, is totally open and transparent. Big decisions are always discussed here and on our public Discord that everyone is welcome to participate in.

[josephcrowell]

A big difference that I've experienced with Winter is support for building web applications that go beyond a normal site:

With Winter's built in support for Laravel Mix, it's awfully easy to use libraries like Tailwind, React, Angular, Vue, etc. Node modules can be easily added to front end themes or even plugins. This game changer is something you won't find in October.

[AIC-BV]

The biggest difference (to me) is the exceptional team of maintainers always trying to help you, regardless how long it takes.
Whether you're struggling with a basic HTML question or having a (real or code related) relationship issue, they are always there for you.

[KB-WEB-DEVELOPMENT]

@LukeTowers , @bennothommo , @josephcrowell , @AIC-BV ,

Thank you all for your very helpful perspective and sorry for the delay.

To answer LukeTowers question, I am still evaluating October CMS and Winter CMS (versus Laravel) to build a basic web application which includes granular user access.

When I first discovered October CMS and now Winter CMS, I initially thought that developing my own plugins (and using existing ones)
would significantly cut down my coding time compared to using Laravel.

The more I read the documentation and watch tutorials, the more doubts I started to have.

And I still do.

Thanks.

K.

[LukeTowers]

@KB-WEB-DEVELOPMENT I'm curious, what are the main concerns you have? Winter CMS is very good at granular user access, I've several applications on Winter with highly complex user roles / permissions / access level requirements and was always able to achieve my desired end results.

[josephcrowell]

If you were going to build yourself a CMS in Laravel, that's already done here. Most packages you'll inevitably need to pull in including Symphony, Eloquent, etc are more optimized than what you'll get in base Laravel and the whole framework just seems snappier. So you're skipping a couple months of development and you have a team of highly experienced volunteers doing the maintenance to boot. Beyond that, what you'll be doing in this vs directly in Laravel is almost identical.

[AIC-BV]

Couldn't agree more.
My wife's collegues decided to write their own CMS system.
In my opinion thats a really bad idea.
Even if you have the budget, your own CMS will never have the same amount of features as (for example) WinterCMS. When you stop working there and someone else has to take over your work, chances are the CMS is doomed because there is no documentation or it does not have the features it should have.

You will write something of your own, true, but you also have to manage and extend it on a daily basis to support whatever the client needs. You will need to keep it up to date and have backwards compatibility or upgrade every website on your personal CMS system regularly. A CMS like WinterCMS has everything already built in which you could possibly need (or you can create it yourself really easy with a plugin of your own).

WinterCMS is easy to step in.
I write default HTML, (S)CSS, JS and PHP(/Laravel) code. These are basic programming languages. Anyone can step in and take over if they have the drive and motivation to do so. You can get really far with these basic programming languages using WinterCMS and the documentation. I have/had no Laravel knowledge at all and I made a succesful website that can basically do anything and has over 10 million euros revenue every year.

[LukeTowers]

I like to flip it around a bit and encourage people to build their own CMS, so long as that CMS is built on top of Winter 😜 😆. I see Winter as being a framework for people to build their own CMS (customized to their specific use cases).

[damsfx]

@KB-WEB-DEVELOPMENT
If you have any doubts... experiment!
Try making a basic site (front, backend, authentication and permissions) with Laravel and then with OCMS and WinterCMS, and see how much time you spend on each to accomplish a simple task.
This should give you a good understanding of the possibilities.
From my point of view, Laravel is for developers, WinterCMS is for developers AND designers.

To give you an overview, here are some of the projects I've carried out with WinterCMS:

• Complete festival management (programming, location, schedules, artists, etc.)
• Business software linked to website via APIs (used car sales)
• E-commerce stores
• Freelance schedule management (online booking and payment)
• Shelter management for animal rescue associations
• Library management
• Sports club management (members, matches, invitations, etc.)
• Restaurant management (meals, menus, etc.)
• School management (homework notebook, parent space, collaborative space for students, etc.)
• Town hall management (council minutes, deliberations, public files ...)
• and many other more general plugins

I've never yet come across a case where WinterCMS couldn't meet my customers' expectations.

I find @LukeTowers' answer very pertinent and full of honesty.
It reflects the spirit that drives WinterCMS, and it's what guided my choice not to stay with OCMS when the team decided to hold its user base hostage by changing the rules.

I could envy OCMS a faster release cycle, the use of blueprints (Tailor) or even a nicer widget repeater ... but I know that the Winter's team had to put in a lot of hard work to make WinterCMS what it is today.
Their work is very qualitative, serious and open to the community; it's a real pleasure to be able to participate (modestly) in the rise of this beautiful phoenix!
I know a lot of great things have come to WinterCMS, and more are still to come.