Spare a thought for contrib

I thought all the Symfony devs were supposed to come over and help us.

i think because open source involves free community contribution, then it requires a lot more planning and designing ahead than commercial closed source projects do
someone needs to orchestrate the whole process, and that someone needs to rely on scientific engineering and not popular opinion

It is definitely true again that growing up with Drupal 8 itself makes it much easier to take the changes. So you get accustomed to changes as they happen. That is how I learnt new Drupal 8 things, and there are always areas where I did not yet work, so I don't know the best practices yet.

Most developers working with Drupal 8 decided taking the changes throughout the cycle would be more expensive for them compared to taking it all in at once. There is some value to that too, since they did not need to learn and accommodate to interim states. However, there is no denying it will be lots of things at once.

I think what can help there are the usual things essentially.

1. Docs. I wrote docs for new systems like configuration context and overrides and configuration schemas with "beginners" in mind in such areas. We do need more people write more docs for things as pieces evolve. Books might help later, but those are not even in writing yet, since Drupal 8 is still so much in flux. (Or if they are in writing, that is way too early, and such books will not be useful for 8.0).

2. Examples. Early ported modules as well as simple things can serve as examples. You can look at existing Drupal 8 modules like http://drupal.org/project/config_translation. Note that these not necessarily follow all best practices yet. Eg. many Drupal 8 modules use hook_menu as before while we figure out how to migrate to more best practices. As of now, many Drupal 7 ways still work, you can define, document and use hooks, etc. It is hard to tell what will be left when Drupal 8 comes out, joining the learning process now is still valuable :)

3. Tools. I think tools that have been available before like coder_upgrade will face an uphill battle now. Converting module hooks to PSR-0 classes outright automatically is pretty much impossible, so I fully agree it is much harder to write tools for Drupal 8 that could serve this purpose. I'm not envious of people who will work on coder_upgrade although I'm sure they will find some tricky solutions for some of the conversions.

Summary is you cannot really avoid learning a lot. Getting involved earlier helps cut down the investment into smaller incremental steps. Attempting to port simpler modules now is already a very good idea.

The missing piece in these conversations is always the same: Backward compatibility isn't a feature. Forward compatibility is. Drupal 7 and earlier didn't have it, and architecturally it was impossible to add. Drupal 8 is a massive, radical departure... but for the first time we have the potential to actually have forward compatibility: http://www.garfieldtech.com/blog/backward-compatibility

Is this going to be a problem? Yup. Is it going to be painful? Yup. Is it necessary? Yup.

Does this pain now at least offer the potential for us to have less pain in the future, finally, by adopting techniques and approaches that have been long-understood to be better for dealing with exactly this situation? Yup.

That's what happens when we lag in PHP 4 land for long...

Where did you get the information for most Drupal 8 work being funded? A lot more is than previous releases, but mine for example isn't and I very much doubt that 'most' is accurate.

but there are "only" 6228 Drupal 7 modules and not all of these will require that much re-working to make them Drupal 8 compatible (I hope).

I agree with the sentiment, but using hyperbole detracts from the credibility of the argument. Certainly there's plenty of work to be done in contrib but it isn't 400 times the amount of work done in core.

That said, if you factor in the total amount of effort required to understand and re-skill in a new Drupal architecture that maybe balances things out.

The statement / question article was a great way to make these points in a subtle yet powerful manner.

I think the issues that you raise are real and will make a big impact on the future of Drupal.

To me, there are a few "quick win" solutions that will help a lot:
- Supporting Drupal 6 for a substantial period of time after Drupal 8 is released (security fixes only)
- A big push to get modules upgraded, with (most importantly) support and tutorials for common upgrade pains (an even bigger effort than the D7CX movement).

Overall, we need to ease the pain of those who are upgrading, which will in turn help justify the "no backwards compatibility" policy that aids innovation in new core releases.

Contrib is not the be all and end all of Drupal module. An awful lot of sites would have rolled their own custom modules and themes. Even if all of contrib is upgraded with a painless upgrade path, every site that has such a module must invest in re writing their own code if they want to upgrade.

If they have to do that, it will at the very least mean that they will investigate other options, and some may be less work for them to move to.

While it is good to be forward looking, it may cost you a lot of your existing user base.

You said: "Most of their time is funded, although perhaps not sufficiently, through various sources." -- Uh. Where did you hear that?? Because it's quite false. I know of exactly nine people who've gotten paid for part of their time to work on D8 regularly, plus the four-person Spark team at Acquia who are working on authoring improvements for D7 and contributing them forward to D8 as well. Drupal 8 probably has at least 1000 contributors. I don't know how 1% of developers having some funding (mostly through their own fundraising) can possibly qualify as "most".