Premium Version

You're certainly free to do whatever you want with your modules, as long as you are following the licenses and practices that govern Drupal as a whole.

However, I, for one, would not. Seeing what happens to other "Freemium" modules in the Drupal sphere, and the utter cesspool that WordPress's ecosystem is with the same, it's not something I encourage here.

There are other ways to support yourself, including sponsorships etc within the community. I am not sure what you're hoping to get out of it, mind you.

Just my own opinion on the matter.

Thanks, @Michael, for your honest feedback.

I am bringing up this idea as a survey for the Drupal community, specifically targeting the users of this module.

First, a contributed Drupal module is the result of the collective efforts of many community members, including coding, testing, and idea contributions. Generally speaking, I don’t think only the module maintainers deserve financial support, as many open-source projects rely on broader community contributions. This is why the current version will continue to use the MIT license.

Secondly, this raises a significant question for the community: what is the sustainable way to ensure the continued success of a Drupal module? This involves not only keeping up with security updates but also adding new features. This issue isn’t unique to this module; many popular Drupal modules have been in minimal maintenance mode for years. Some modules may appear active, but if you closely examine their issue queues, you’ll realise they need more engineering hours to be properly maintained.

I have no issue with open source Devs generating an income from their work. What is disappointing in this case is that community members have provided patches to allow an upgrade to v6 but they have been not been accepted in order to have that functionality as part of a premium version.

There is value in the other premium features that you list that you could build that into a separate premium sub module whilst allowing this module to at least support the latest version of fullcalendar without a fee.

If the issue is that you don't want to maintain the free version any further or do not have the time to commit to the task, then I ask that you seek a new maintainer to take over the project. I don't have a history of maintaining Drupal modules however I am willing to assist if it allows this module to remain free for the community.

@Nick Perkins, I don't know how many contribute module has you every maintained or contributed to the community. Let me tell you what I have done for this module, excluding other modules I have contribute to the community where I have spent thousands unpaid hours.
1. Review the patch provided by others. This work includes security review and functionality review. When a maintainer release a version that is covered by Drupal security policy, the maintainer is responsible for making sure that version is safe. The most of users of a Drupal contribute module don''t have that knowledge. They simply rely on and trust the module maintainer.

2. Investigate and fix the bugs caused by a patch or new feature provided by others after releasing. Accept a new feature, particularly the one is fundamental changed from the bottom, is not the end of the story, but is a begin of a new journey. Accept a new feature without knowing how it works and no plan to maintain it. That is not the way how I maintain a Drupal contribute module.

Back to your suggestion. Yes, I would like to have someone join to help this module as a co-maintainer. In order to have a good hand to help to make the job easier, not the opposite, I need a person who has the knowledge and experience on maintaining a popular Drupal module which has large feature request queue. I need to know the person's plan on this module. I need to know how many hours that person will contribute to this module regularly.

True, there is a merge request right there. If you are interested in maintaining this module or V6 version. How about starting from reviewing the merge request. I put the link here.
Please let me know how you are going to review this merge request. What things are you going to check? What test are you going to conduct?
If you just want that feature, but not interested in reviewing and testing it. That is totally fine. Then the questions above are given to those who is willing to do it.

Again, if you just want that patch for your own custom version of this module, you can patch it in your own project. But put it into next release version of a contribute module, there are a lots work behind that.

The 6.x branch was created for catching up the latest major version of the Fullcalendar.js. It will be open and remain as long as anyone want it or contribute to it.

But a release of it which is covered by the Drupal security policy won't happen. Making it clear here is to inform anyone who use 6.x branch for their own projects that they need to make their own plan based on the fact.

Choosing not to address the seemingly confrontational nature of the responses here by the maintainer, but I would point to the DCOC → to remind folks that they do apply and be mindful of others who choose to participate.

Blocking a Drupal Security Policy (DSP) validation for new and maintained versions of a dependant library behind a "paywall" might not be in keeping with recommended practices within the DSP or even good maintainership. I'd be very curious for the DSP folks to weigh in here on what would be considered best practices here.

Having previously tried to use this module, I ended up switching to FC v6 via a custom implementation and have noticed the implementation of v5 and v6 are very different.

I would be more inclined to believe that the task related to upgrading to v6 properly is a major effort that the maintainer doesn't have the time or resources to undertake. Which is understandable, however, this comes across as a bit poor-taste to make this a hill to die on. Having two major versions of a module, one covered by DSP and any future (major) versions not, comes across as confusing and reduces confidence in the overall project.

@Michael O'Hara, free feel to report this module or me as the maintainer to the Drupal Association or wherever you want.

This module has been put into 'Minimally maintained' for a while. That means non-commitment to any major version in the future at all. I have no idea what you are talking about. You can keep complaining no future major version release of a 'Maintenance fixes only' module.

As the point I made at #4, I bring in this discussion is about to discuss in what way that is a sustainable for a Drupal module moving forward. What I am looking at is beyond this Drupal module.

@mingsong "Again, if you just want that patch for your own custom version of this module, you can patch it in your own project"

The issue I see with that is that it is then a stranded fork, and everyone will need to manually pull in upstream updates etc into it, there's no means to coordinate issues regarding it that may come up in the future, etc.

I don't need any of the other functionality above, but it'd be nice to have the latest version of the library in a build that isn't stuck in time. If it's a reasonable one off fee that's something that would probably be worth it.

I do wonder how many people would use the paid version, and if having it forked off would impact the amount of community patches and people to test them etc.

IMO just having a new branch with the latest version of the fullcal library as a public branch, then selling a module with specific more advanced functionality seems the best way to go, especially if the work has already essentially been done. As you say, this is minimally maintained, so there shouldn't be a ton of new features and functionality coming in on top of that.

If someone with experience running modules comes and validates the MR for FullCal v6 and pulls in any related patches since, would that be enough to just have a new branch here?

IMO just having a new branch with the latest version of the fullcal library as a public branch

The answer from #7

The 6.x branch was created for catching up the latest major version of the Fullcalendar.js. It will be open and remain as long as anyone want it or contribute to it.

Again, like any other Drupal module, anyone is more than welcome to contribute. In this case, the 6.x branch is open to anyone who want to contribute to that version which is compatible with the latest Fullcalendar.js. It is totally free to use 6.x.

The premium version of this module is not based on 6.x branch, which is totally refactored from 5.x.

To those whom is interested in Fullcalendar.js 6, there are many other Drupal modules that have already supported it. Please give those modules a go before you considered the premium version here.

Again, like any other Drupal module, anyone is more than welcome to contribute. In this case, the 6.x branch is open to anyone who want to contribute to that version which is compatible with the latest Fullcalendar.js. It is totally free to use 6.x.

It'll never have tagged releases or show up on the project page. I suppose pinning specific commits in composer is an option.

To those whom is interested in Fullcalendar.js 6, there are many other Drupal modules that have already supported it. Please give those modules a go before you considered the premium version here.

Sure, I'll give https://www.drupal.org/project/fullcalendar → a try.

Good points. Agree.