Drupal 6 end of life when Drupal 8 is released… or not?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
christefano's picture

At the Boston Drupal meetup that was at Acquia this month, several presentations were focused on "what's new in Drupal 8" from the view of several people who now work at Acquia. I loved it. There were other presentations, as well (including one of my own!), and I really enjoyed seeing the Boston Drupal group again after many months.

During the questions and answers part of the meetup, I asked Dries if he was considering naming a security maintainer for Drupal 6 when Drupal 8 is released. (In case you didn't know, support for Drupal 6 will be discontinued by the Drupal core and security teams. See the handbook page on backwards compatibility at https://drupal.org/node/65922 for more, including Dries' original statement on the subject in 2006.)

Dries noted that this question hadn't come up before and that he'd think about it. There was a brief discussion about what it would take, and with some back-of-the-envelope calculations it was suggested by a few members of the meetup (including xjm, who led the VDC initiative to get Views into Drupal 8 core), that this might cost around US$11,000.

I say "might", because this was a ballpark guess based on the VDC initiative, which may not be a good basis for budgeting what having a Drupal 6 security maintainer would cost. Even then, VDC was timeboxed and having a Drupal 6 security maintainer may or may not be feasible for more than a year or two.

I've been saying for a long time that Drupal 6 is the "Windows XP" of Drupal. I predict that years from now there will still be sites running on Drupal 6, just like there are millions of Windows XP machines out there today (as an aside, Net Applications says Windows XP currently has around 39% global market shareshudder).

Questions for our community

• Is this a problem that's not worth solving? After all, site owners should know that the Drupal core and security teams don't support Drupal two versions back, right? Right?

 • What will happen to all those Drupal 6 sites that are out there and are difficult to upgrade due to significant amounts of custom code?

 • Will the original developers of those sites who have already moved on to newer projects come back to help maintain those Drupal 6 sites?

 • Will there be a Drupalocalypse as new vulnerabilities are discovered and Drupal 6 sites are hacked en masse?

 • Will companies in the Drupal marketplace aggressively step forward to help maintain and / or upgrade them?

A forum for discussion

A few months ago I proposed a group named Site Audits and Rescue Projects so that our community has a forum for this conversation and community-driven solutions over the next few years. I've cross-posted this discussion from that group with hope that we can get the conversation going.

To learn more about that group, see http://groups.drupal.org/site-audits-and-rescue-projects and join up at http://groups.drupal.org/og/subscribe/267948

Comments

Contrib

Heine's picture

Modules are a common source of vulnerabilities in most sites I've seen, more so than core.

Extending D6 support would require buy-in from module maintainers unless the security maintainer is going to create patches and releases themselves. I wasn't at the meeting; did this get discussed?

Disclaimer: I'm involved in plans to provide extended Drupal 6 security support (core, contrib).

Not really

NancyDru's picture

Module maintainers always have the freedom to support whatever releases they want. There are a handful that still support 5.x. Many have given up on 6.x already

So contrib support has nothing to do with core.

Contrib maintainers may have some heartburn from continuing security team activity, but can always elect to have their 6.x releases unpublished.

Er :) Some misinfo here

xjm's picture

Dries noted that this question hadn't come up before and that he'd think about it. There was a brief discussion about what it would take, and with some back-of-the-envelope calculations it was suggested by a few members of the meetup (including xjm, who led the VDC initiative to get Views into Drupal 8 core), that this might cost around US$11,000.

I say "might", because this was a ballpark guess based on the VDC initiative, which may not be a good basis for budgeting what having a Drupal 6 security maintainer would cost. Even then, VDC was timeboxed and having a Drupal 6 security maintainer may or may not be feasible for more than a year or two.

First, a correction: It's not accurate to say I led VDC. :) For the past eight months, the initiative has been led by a team of four people: myself, dawehner, timplunkett, and damiankloip. (They write a lot more code than I do, and I write more blog posts than they do.) Also, merlinofchaos is the one who originally founded the initiative, formed the team, and did the initial fundraising.

Onto the actual question. I don't recall whether someone said a D6 security maintainer would cost $11K or who it was, but it wasn't me. What I do remember discussing is what VDC was able to raise, and how:

  • $13k from a community chipin on the Views project page.
  • $17k total from two major sponsors (one of which was Acquia).
  • Significant donated employee time from Zivtech, New Digital Partnership, and erdfisch. It's hard to put a dollar value on this, but all three were sponsoring a senior developer for as much as 25%-50% of their time. I'd estimate this was probably the equivalent of $30-$50K over the course of eight months.
  • Various other contributions from individuals, companies, and events to cover sprint and travel costs, about $10k total.

So that's a figure of about $70-$90k if you total it up. Comparing that to the cost of a D6 security maintainer is a bit apples to oranges IMO. (What I do remember webchick saying is that a community chipin would probably not work to fund it, because "the most popular module in the world was only able to raise $13K that way.")

Also, I'm not sure a core security maintainer would really meet the need, since it would do nothing to address security vulnerabilities in contrib.

All that said, I can confirm that Dries does have a to-do to consider this idea.

Right now, we have a Drupal 6

David_Rothstein's picture

Right now, we have a Drupal 6 core security maintainer, his name is Gábor, and as far as I know he gets paid $0 to do it :)

So I'm curious as well what it means to say that it would cost $11,000... Is the idea that we don't think anyone would volunteer for this going forward (especially given that Drupal 6 has already been supported for far longer than originally seemed likely), but $11,000 is what it would take to convince someone?

One essential question to answer would be how to coordinate this with Drupal 7 and Drupal 8. If a Drupal 6 backport of a particular patch happens to be complicated and take longer, would there be an expectation that the security team would hold up Drupal 7 and 8 security releases (either core or contrib) for it? Or would this strictly be something that is worked on in public, after any Drupal 7 and Drupal 8 fixes are already out?

For core: The job of ensuring

Dave Reid's picture

For core:

The job of ensuring that things get backported to Drupal 6 is much tougher with the lack of SimpleTests in core. Theoretically this will be an easier decision to make since we can see pretty much if something regresses with Drupal 7, but D7's end of life is a bit further away. I know personally I wouldn't want to be tasked with maintaining an EOL'd D6 without being paid/supported to do so. Likely minimal non-monetary support from the Drupal security team as well.

For contrib:
Up to maintainers, but likely will not have any security team support for security annoucements.

Another question worth asking is if contrib isn't supported via SAs, what usefulness is there in maintaining core with backports?

Another good question: by the time Drupal 6 is EOL'd, is the probability of finding a major vulnerability less? The community and researchers have had over five years to find major exploits, what is the chance that we'd still find another one?

Senior Drupal Developer for Lullabot | www.davereid.net | @davereid

Well, for example, I think

pwolanin's picture

Well, for example, I think there was a significant flaw in filter_xss() that was fixed in Drupal 5 & 6, but never in 4.7 since it was EOL, though obviously there were fewer eyes on the code then.

many fixes were backported

ericG's picture

At Openflows, when drupal 5 was released, we continued support for 4.6 by backporting any relevant patches. When 6 was released, we did the same for 4.7. We gave up when 7 was released and decided to not maintain support for 5 because we did not have the resources to keep on top of things.

you can find these patches at http://openflows.com/drupal/security/

Even if there is not going to be official continued support for 6, it would be nice if some space could be set aside on d.o or maybe a group on g.d.o so these patches could be easier for people to find. Back when we were handling the backports there was serious resistance to providing such a space so we hosted them ourselves.

LTS project on d.o

scottrigby's picture

@ericG: that's part of what http://drupal.org/project/lts is intended for :)

Short extension

effulgentsia's picture

I think there would be a lot of value in a short (e.g., 6 month) extension to D6's official EOL (official, as in yes, holding up public disclosure of D6 core and contrib vulnerabilities, even in the form of D7 and D8 fixes).

It would allow D6 site owners to migrate directly from 6 to 8 without needing to go via 7 first.

Even for that, we'd need to figure out if the security team, Gabor, other volunteers are willing to take on that workload, or if additional resources are required.

Beyond that though, I think it would be challenging/expensive to support properly.

I'm for a short extension.

mgifford's picture

Laura described the reality pretty well in this post:
http://pingv.com/blog/still-running-drupal-6-start-planning-your-upgrade...

I'm for a bit of an extension to Drupal 6's EOL simply because there's almost no site that you can take from Drupal 6 to Drupal 8 at the release of D8.

Looking back at D7, despite a sincere interest in upgrading core modules, it took months till you could reliably launch a D7 site and even now there are quite a few big modules that haven't put out a stable release. There's lots that needs to be done to better support the maintainer community.

Already I'm finding that D6 is loosing support in some of the modules we are using. There are just so many developers willing to put in time to maintain them. Just not enough benefits to ensure that maintaining a module is a top priority.

I brought up an idea to make it easier to upgrade to D8 here http://drupal.org/node/1532660 - though it does really rely on a bunch of infrastructure work to make it happen. Upgrades should be easier though.

A 6 month EOL extension will give some space for D6 users to jump to better supported versions of D8.

I'd love a 6-12 month extension of D6 support

grantkruger's picture

I agree completely. In the process of moving toward our own upgrade I have had a lot of conversations with a lot of developers and even heard the opinions of some core developers at the Portland DrupalCon, and I'd say that at least three fourths of the opinions I heard were that the complexity of upgrading from D6 to D7 is such that mostly they ended up doing redevelop-and-migrate instead of a true upgrade. This meant that it was a bigger task than hoped -- i.e. needed more time and money -- and skipping 7 and going straight to 8 was seen as the best option by most.

Given this growing consensus that materialized even during the core developers Q&A, it seems that we have a unique set of circumstances here where a large number of sites are considering being on an unsupported version of Drupal for some months after D8 is released, possibly longer than a year. For this reason I think it behooves us as a community to at least explore the option of extending D6 support for 6 months to a year after the release of D8.

As an aside, you can listen to that question come up during the DRIES & COMPANY Q&A panel at the Portland DrupalCon at about 52:15. There's no actual video, but when the first guy spoke up in favor of upgrading to D7 the panelists on either side of him began shaking their heads vigorously indicating complete disagreement, and there were a number of grumbles in the audience too.

Sala kahle,
Grant

I think it's important to

dalin's picture

I think it's important to consider what types of sites would most benefit from using D6 with extended security support, then work forward to figure out what that extended support should look like.

I think there are significant downsides for a site that chooses this route (most of which have already been mentioned):

  • Increased risk due to a lack of test coverage.
  • Increased risk due to fewer maintainer eyes on the problems.
  • Fewer sites going this route, therefore a smaller benefit from crowdsourcing any bugs that arise.
  • Difficulty in coordinating with more recent core releases.
  • Difficulty in coordinating Core <-> contrib.
  • more?

Therefore I think this route would be the wrong way to go for most medium/large sites. This route is more beneficial for

  • smaller sites
  • sites that are only concerned about script-kiddie/drive-by security attacks (and not targeted attacks).
  • sites that do not suffer a large monetary cost if issues arise during a security update (be it anything from minor bugs, to outages).
  • sites that have the resources to deal with bugs and outages if and when they arise (ex. they have a maintenance plan with a Drupal shop).

Therefore I think any extended D6 support should be:

  • Opt-in. It would probably have to be a separate stream outside of standard Core releases.
  • Public. Given the limited resources to manage the extended support, it would need to be done in a manner that makes it easy for people to contribute.
  • Not hold up D7/D8 security releases.

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

real problems with Drupal 6 maintainership

Gábor Hojtsy's picture

As said above, not sure how do you envision contributed module maintenance. I think the real problems are flaws in any contributed modules (as said earlier) as well as the lack of testability.

The #1 contributing reason that Drupal 6 did not have a non-security release in a long time is that (a) we know huge important sites are dependent on it (b) the patches proposed are not widely tested and often brought to RTBC lightly. We introduced several regressions earlier in the Drupal 6 point releases. So the real cost is somewhere around testing and validating that patches work and somehow separating the weeds from the crop. That is crowdsourscable and with some updates to the Drupal 6 queue we could validate if it even works. (Currently there is no process to tell RTBC issues that are well tested apart from lightheartedly RTBC-ed issues). So as far as I see the main blocker for Drupal 6 core fixes is the lack of testability and lack of human testing compared to the dangers possibly caused. Those actually interested in Drupal 6 going forward should IMHO keep this in their primary focus.

As a non-professional

MatthijsG's picture

As a non-professional maintaining some sites (NGO, private), some thoughts on this.

The problem are the modules. However, not only the security, but the availability. A lot of Drupal 6-modules aren't even available or having an alternative in Drupal 7. And yes, i know, don't use obscure or little modules. But - as example - take Storm (Project Managment in Dr7): it is still in development.

The last weeks i made an overview of the modules-list of my Dr6-sites and their alternatives. I let the little, obscure ones go. But several times i didn't find any good alternative for even Dr7.

IMHO, the release-cycle is going to quick. Dr6 is now mature, Dr7 not yet. Is dr7 some kind of Vista? And when is Dr8 mature? When Dr10 is coming out ..?

What if, the problem aren't the modules but the gap between users and core-developers? Once builded a decent site, you already have to plan an upgrade. In most cases this means rebuilding a site from the scratch.

Agreed, the release-cycle is going way too quick

Bob Newby's picture

Given Dries' firm and obstinate commitment to flying in the face of the enterprise software industry's standard of providing at least 3-or-more years of backwards compatibility, there is absolutely no doubt in my mind that the release cycles for major Drupal releases come far too frequently. Also, that the ideological "We don't believe in backwards compatibility" drumbeat applies across both core and contrib simply compounds the problem, exponentially.

My perspective is that of a Drupal customer. As anecdotal evidence to support my view, I just finished about 15 months of work developing my business' site (in D7). It has just been launched, and my one-person operation is shifting its portfolio from one emphasizing development and testing to one emphasizing customer acquisition and support.

With that as background, I am pleased that D8 will at long last provide sanity for Drupal configuration management. Drupal's pre-D8 storage of configuration in the DB was the first major problem I noted when I evaluated it. This fundamental and very expensive shortcoming stood out because of my in-depth background in the Java Enterprise and related open source arena, engineering large multi-tier systems in a startup environment. In that realm, for very good reason the standard is to maintain functionality release-to-release but to mark it as deprecated if indeed it should and will be supplanted by newer architecture and implementation at some point in the future. The system works.

So, on the one hand D8 is a major advance because of its promise to relieve a major pain point -- portability of a site's configuration.

On the other hand, D8 does not relieve the second major pain point -- lack of backwards compatibility across the board of core and contrib. With my site, I can foresee a nightmare on the contributed modules front if I were to explore porting it from D7 to D8. Why?

One reason is because the site currently utilizes a total of 343 modules, only 30 of which are from core. How many of those do you imagine will ever make it to D8?

The other reason, and the third major pain point with Drupal, is that my business simply cannot afford the expenditure of money and time to try to keep pace with a fast-moving machine that is constantly changing its architecture and its parts, all the while flaunting its disdain for backwards compatibility. This is disrespect, to be candid, for legacy customers.

It is like buying an automobile and discovering 18 months later that it needs a major overhaul to be able to use the fuels that are now available, since the old fuels are not -- and to be able to drive on a roadway system that no longer accommodates my automobile without putting a large and unexpected additional investment into it.

That my 2 cents, IMHO -- from the perspective of a Drupal customer.

I can only imagine how very challenging life is for all the sincere, hard-working contrib module developers and maintainers who are faced with the same parameters.

We often note that founders, especially successful ones, have a susceptibility to arrogance and stubbornness -- including in the face of the realities staring them in the face. I believe this is the case with Drupal, and that the current process for setting Drupal's trajectory is approaching an inevitable breaking point.

Bob

--

P.S. Perhaps I should add that I have already experienced the significant challenge of migrating my business' original D6 site to D7. I know of what I speak.

Dries mentioned during his

dsnopek's picture

Dries mentioned during his keynote a few months ago at Drupalcan Portland that the core team is considering providing backwards compatibility for Drupal 8 in Drupal 9. We'll see if that comes to fruition.

However, the reason this isn't done currently, is not that Dries and the other core developers think that backwards compatibility is a bad idea! It's simply a lot of extra work. And the majority of Drupal development is still done by volunteers in their free time.

Anyway, I can sympathize with you that Drupal migrations are very difficult. I have done several for my personal sites and for clients.

As Drupal becomes more and more of a business, maybe we will see more of the properties of enterprise software seep in, like backwards compatibility for N-1 versions. However, it's really a question of resources: the time and money necessary to accomplish that.

I encourage you to contribute in whatever way you are able in order to make backwards compatibility a reality! :-)

Best regards,
David.

No thanks

NancyDru's picture

How much code is still in Windows (or Linux) to support 16 bit, or even 8 bit, code?

I've been in IT for over 40 years and have seen so much code bloat that resulted from backwards compatibility. I really don't want Drupal turning into that.

Yes, I've been through many upgrades - I started with 4.7.8. Yes, they are difficult. As a module maintainer, yes, upgrades are a nightmare. But I am glad that all that baggage is gone.

Heh, I agree that backwards

dsnopek's picture

Heh, I agree that backwards compatibility forever would definitely lead to bloat and performance problems and all sorts of other issues. :-)

However, I think version N-1 backward compatibility is a reasonable tradeoff and could be very good for our community. FYI, what I mean by N-1, is that Drupal 8 modules could somehow work in Drupal 9, using deprecated APIs. But D8 modules couldn't work in D10 - the deprecated API would be removed by then.

Anyway, this does add considerable work for Drupal core developers and they already have more work than they can handle! So, it might not be practical. But I think it's worth considering, because it would solve some really serious problems, like have been mentioned here.

The biggest problem is that

Richard Damon's picture

The biggest problem is that with Drupal, it seems that APIs don't always "disappear" but change how they are used. To implement this sort of "deprecated API", at least in a way that is reasonably verifiable, the development process needs to change so that any api point that becomes incompatible with a previous version MUST be given a new name. New names may be hard to find, so we may end up with API/Function names with version numbers in them, and then just because the function was added in say version 9, and so has a 9 in it, should it become a 10 in version to (with a trivial forwarding function for the version 9 version), or do we live with with Drupal 12 having "current" functions with the numbers 9, 10, 11 and 12 in them depending on the function.

One, in my opinion, ideal way to provide these obsolete API entry points, would be to have in Drupal 9, and core module called Drupal 8 which provides these, so that any module that list listed as being dependent of Drupal 8 core, can have this dependency automatically applied when loaded into D9.

I think that dependency

dsnopek's picture

I think that dependency injection (like is available in Drupal 8) would make it so that version numbering function names wouldn't be necessary (at least for anything that can be dependency injected, which in Drupal 8 still won't be everything).

However, these are all technical problems! If we have the resources, we can solve any technical problem. The real underlying problem is getting the extra resources (more developers, plus more time and money for existing developers) to actually work on them.

(FYI: if you're curious about what dependency injection is, there's the Wikipedia article which is good: http://en.wikipedia.org/wiki/Dependency_injection - and here is the shortest and most overly simplistic description ever: without dependency injection, we directly call globals like theme(...), for example. With dependency injection the theme system is an object that gets passed to you or registered somewhere, so now you have $theme_system->theme(...). This way we could swap out what theme system gets used. Please forgive the brevity but I hope that makes sense. This means D8 modules could be passed a D8-backcompat theme system object, and D9 modules could be passed the new one. And here's the issue to make the theme system into a service in Drupal 8...)

Drupal 6

gerontas's picture

This thread started as a discussion about D6 - isn't it going a bit off topic?

As someone who has been struggling, as yet unsuccessfully, for many months with a difficult D6-D7 migration I really can't see myself ever using D8. I just don't have the time left (translate my user name from Greek to understand).

So retaining D6 is important to me to allow someone to inherit my sites in a safe and secure condition.

Having old versions of Drupal

Richard Damon's picture

Having old versions of Drupal being supported "forever" isn't going to happen, so any site built with Drupal will eventually become "unsupported".

For a site that is going to become fairly "static", being unsupported isn't as much of an issue. There is the risk that security flaws will be fine that will need to be fixed, and those fixes won't be provided as fast, if at all, it may be up to the operator to back-port the fixes (if necessary) to the older, unsupported, version. There is the hope that there shouldn't be many of these lurking in the code by the time the core becomes unsupported. User modules are different, they may not be used as much to knock out all the vulnerabilities, but also contributed modules don't fall under this rule. Some contributed modules may become unsupported well before the core they are based on goes unsupported if the author abandons it and no replacement maintainer is found, and the maintainer may choose to support it long after the core is unsupported.

I think that the current policy on support is, in part, based on the idea that "real sites" need to be periodically reviewed and updated anyway, and when doing this refresh, it makes sense to use that as an opportunity to convert to a more recent version of Drupal (Others may view this idea as a web developer employment policy, but then many of the people developing Drupal ARE web developers). Normally it shouldn't be too hard to update your own custom code, the bigger issue is if you are using a contributed module that hasn't been updated.

I personally feel that more important than how far back will versions be "supported", is providing the support needed to help module writers keep their modules working with the newer versions. I don't know if the D6 - D7 conversion was unusually bad, but I do find a number of modules that could be useful that haven't moved to D7, and this is often given as a reason that it is "hard" to move a site from D6 to D7. If there was something unusual about this change, then it might be a reason to extend support for D6.

need to be periodically

MatthijsG's picture

need to be periodically reviewed and updated anyway
The problem is not that a site should be updated, but the frequency for updating. The cycle is going to fast for a lot of people here.
Just fine for pro's, but there are a lot of hobbyist and semi-pro's around here.

First remember that just

Richard Damon's picture

First remember that just because D8 comes out and D6 (as currently planned) becomes "unsupported" doesn't mean that sites built with D6 will stop working. I am sure there are still some D5 and maybe even D4 sites out there.

The primary meaning of being unsupported is that the security team will not hold up releasing security updates to wait for a D6 patch to fix the exploits found, and maybe even that the main team won't make creating a patch for D6 core an important item. It will become incumbent on users of D6 sites to read teh security alerts, see if any of them apply to them (and for simple sites this is unlikely), and if needed work out a patch for it.

I don't think there has been any talk about preventing D6 module writers from providing improvements/security patches for modules, there just won't be the pressure currently applied to do so.

long term support

Gábor Hojtsy's picture

Given Dries' firm and obstinate commitment to flying in the face of the enterprise software industry's standard of providing at least 3-or-more years of backwards compatibility, there is absolutely no doubt in my mind that the release cycles for major Drupal releases come far too frequently.

Where should we count those 3 years from? Drupal 6.0 was released 5 (five) and a half years ago at this point (https://drupal.org/drupal-6.0), and is still supported and fully backwards compatible! At the point when Drupal 8 will be released, Drupal 6 will be over 6 years old. There was also 3 years between 6.0 and 7.0 released (https://drupal.org/drupal-7-released) and there is going to be at least 3 years between 7.0 and 8.0 as well.

faster than industry

krlucas's picture

I suspect Dries' "obstinate commitment to flying in the face of the enterprise software industry's standard" is a recognition that things are moving faster than the supposed "enterprise software industry's standard".

Dries shepards a CMS project at a moment in time when people consider native phone apps passe.

I welcome the fast pace and challenge the "enterprise" to keep up.

MakeOnlineShop's picture

I do not understand why after years of security fix anything still need to be maintained...

While Core is likely fairly

Richard Damon's picture

While Core is likely fairly well beaten on for major vulnerabilities, it isn't out of the realm of possibility that someone might find one still. Much more at risk are the contributed modules.

i love to use Drupal 6, maybe

minhthanhjam's picture

i love to use Drupal 6, maybe i have to change core ...

Xem blog của tớ, hoặc ủng hộ tớ bằng việc click chuyển nhà ...

Would you be willing to pay

Heine's picture

Would you be willing to pay for a security upgrades subscription for Drupal 6 core and contributed modules?

Pay for security updates

gerontas's picture

Yes - if the price was reasonable I think I would.

support an effort, yes. pay for the code, no

ericG's picture

I would be willing to provide some funding into a pool of money that could be used to help support a group of people extending the life of d6.

But if you're asking anyone that might need those updates to pay, I would not recommend the organizations that I work with go along with that model.

sorta

ericG's picture

I might be willing to pay, but if I did I would then use the rights guaranteed to me under the GPL and redistribute those changes for free

Definitely would pay

brpubs's picture

I have several nonprofit-organization clients in Drupal 6 installations with ap. 50-150 contrib modules as well as a fair amount of custom code. I expect the cost to them of an annual subscription for security upgrades to D6, before finally migrating in a couple of years to a stable version of D8, would be much more affordable than the cost of a migration to D7, followed by a subsequent migration to D8.

Given that such a thing does

krlucas's picture

Given that such a thing does not exist, exactly what would you expect it "cost to them of an annual subscription for security upgrades to D6". Or more to the point, how much is it worth to them? Sounds like it's only worth the cost of upgrading to D7.

My guess is that they would

brpubs's picture

My guess is that they would happily pay $500-$1000/year if that bought them a couple of years before having to do a major upgrade. Much more than that, and they'd probably opt for the immediate upgrade instead.

the problem with this discussion

ericG's picture

is that the questions about how it would work have been ignored.

The big question is, how would such a service work in regards to the GPL.

If you run a subscription service and distribute the updates only to those that pay you, the GPL gives each of those people the rights to redistribute those updates to anyone and everyone they want to. You can not write a legally binding agreement that states otherwise without violating the GPL.

You could run a hosting operation/software as a service and not actually distribute the code -- hide behind the SaaS loophole in the GPLv2. That however would require anyone in need of this service to move their hosting to your servers, which would be a huge problem for many organizations. As well you create a single point of attack and single point of failure for drupal 6 sites. There will certainly be a delay between release of patches for 7/8 and backporting them for 6 -- in that window, you would have created a visible and wide target for server/site exploit/hacking.

It would only be viable if you take a community-centric approach -- ask for people to donate into a fund that would be used to support the backport project and have that project release code for anyone.

I would pay also !

MakeOnlineShop's picture

I would pay also !

if you pay or not..it makes

eule's picture

if you pay or not..it makes drupal not better! i have now try´d 4 years on drupal, i begun with d6 and work now on finding bugs in d8. anyway all the stuff suxxs and i need to concentrate on my project and not on drupal itself. dries is going and found some pay companies like acquia to help the big players not us! Acquia is not helping the whole community /no modules / nothing its all frezzy and always a step behind. i change to wordpress and concentrate me on my project to rule google rankings! Automattic is helping the Wordpress Community.

Greets from Germany
Prepaid Tarifvergleich

Cost of upgrade

gerontas's picture

https://groups.drupal.org/node/291243#comment-961108

Sounds like it's only worth the cost of upgrading to D7

A real-life example.
I have been working on a D6-D7 upgrade for nearly 6 months. The process has been a nightmare. As a designer/site builder who has been working with Drupal since D5, I am pretty good at handling anything that does not require too much coding but problems with various contrib modules have caused significant blocks.
I now have an upgraded, and re-configured version of the site but transferring content from the live D6 version is beyond my skills. The project has now gone to a development company and it will cost around 10k euros. The client is a charity with very limited funding - I work for nothing because I choose to, being semi-retired.
I am sure that there are many others like me whose clients will prefer to pay an annual fee rather than pay for an upgrade now.
I have to say that the process of upgrading a complex site is vastly underestimated by some comments here.
It will interesting to seeing how Backdrop develops for upgrades - maybe it will become a better alternative and it's certainly targeted at Drupal users like me.

MakeOnlineShop's picture

It can be done if people stop thinking too much about useless things.

When time will come we just have to find someone who can do the job and he will tell how much he wants.

Then all the ones who want to update their D6 will pay.

Nothing else to care, it is just ridiculous to update to each new version of Drupal when we don't need the functions, it seems that we are enough here to try to explain this point ?

This topic is now being

David_Rothstein's picture

This topic is now being discussed in the core issue queue: https://drupal.org/node/2136029

Thanks for the link, David!

christefano's picture

Thanks for the link, David! Your comment is how I found out about the issue in the Drupal core issue queue.

This topic is also being discussed in a few more places:

  
Seeking input from contrib maintainers on extending Drupal 6 support past Drupal 8's release
   https://groups.drupal.org/node/419838

   Extending support for Drupal 6?
   https://groups.drupal.org/node/422878

https://drupal.org/node/22885

mlhess's picture

https://drupal.org/node/2288521 is the Drupal core team, key module maintainers, and representatives of the Drupal security team's response to this. I am closing this thread as a result.

If you have other comments, please feel free to centralize them at the above URL.

Boston

Group categories

More Specifically

Group events

Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week