At Drupalcon Denver, I approached Dries with the idea of putting Views into Drupal core for the Drupal 8 release. The idea was met very positively, and I've begun the work of putting together a team and resources and the things required to do this. Obviously, it's a big job, on the scale of initiatives like Mobile, CMI, WSCCI, etc.

This initiative will be called VDC, or Views in Drupal Core. The goal of this initiative is to put Views as we know it into Drupal core and properly integrate it so that everything is seamless. The fantastic UX work that Acquia funded last year already works very well with the core style, and we can continue to build on that to make it simply part of the Drupal experience.

For many years, large portions of the community have asked repeatedly why Views isn’t in core. Many of those answers are fading: Core’s processes are now capable of handling large projects. Views’ development needs have slowed as it has matured and gotten more feature-filled. It’s well known that Views and CCK, together, catapulted Drupal from having tens of thousands of installed sites to hundreds of thousands of installed sites by significantly reducing the amount of work needed to build complex functionality. CCK is in core now, but Views is not.

The problem, of course, is that such a big project requires resources. It requires money and it requires time. There are several dependencies that need to either be moved from CTools into core, or redone. The export system has to be reconciled with CMI, and there is effort on a plugin framework for core in development that Views would prefer to be able to take advantage of. The entire object system then needs to be moved around to match the new PSR-0 standards, large chunks of code need to be upgraded to meet core coding standards, and then we need to vastly increase the test coverage so that it is as well-covered as current core. We could also, as part of the port, fix a few minor architectural issues that have been annoying to work with.

I've been assembling a small team to do the work, primarily of people who are very familiar with Views and/or Drupal 8, and they are all people I think very highly of. Everyone on the team is dedicated to volunteering as much time as we can, but working on a project on the equivalent nights and weekends won’t be enough.

Currently the team is comprised of (in addition to me, of course):

  • Daniel Wehner (dawehner, dereine), Views’ co-maintainer (who is rapidly catching up to me on commit counts).
  • Tim Plunkett, a developer at Zivtech and an active Views Bug Squad member.
  • Jess M (xjm), the primary driver behind Core Mentoring Hours and major force in the Drupal patch review and acceptance process.
  • Others to be added as appropriate.

I've asked Acquia’s Office of the CTO (Dries Buytaert, Angie Byron, Michael Meyers, and Moshe Weitzman) to help out with the logistics of acquiring these resources. Acquia will be helping because their entire business model is built on a healthy Drupal, but this project is not Acquia’s responsibility; they will contribute to the project alongside the broader Drupal community. So, I am turning to the community to help contribute resources as well, to ensure that this project is a success, and that we can turn this into something that will benefit Drupal and make the Drupal community proud.

  1. Hosting and/or funding of sprints.
    I believe a lot of the best work will be done when we can get some of the team together to work through the hard problems and tedious problems and really focus on getting things done.
  2. Dedicating resources.
    Additional development resources or project management resources that have time granted from one of the shops could definitely be valuable. There's a lot of work that will be necessary to adapt Views to Drupal 8.
  3. Contributing financially.
    While some of the team I've assembled already have paid time to work on the project, not everyone on the team has the backing of an employer with a vested interest in the community. And while all of us intend to volunteer as much time as we can, funding would be very helpful for making it possible to complete the project by feature freeze.

We are at an early stage and we're still working out what we think our overall budget will be, so I don’t have any hard target numbers to share yet, but we’re looking to fund a team of several developers for the rest of the year, plus project management, plus several code sprints. It will likely require more than a hundred thousand dollars when all is said and done.

The first question anyone should be asking is, “Why should I contribute resources?"

The most obvious benefit to the community is that no matter what happens, this work is going to have to happen on Views for Drupal 8, whether or not it goes into core. In Drupal 7, even with a pretty concerted effort, it took close to a year to get Views really ready to use, and that included a significant investment by Acquia to upgrade the UX. But, Views is a big project, and we’re limited in our ability to get people together on our own. A significant organization and a team with dedicated time will change the dynamic of how and when things are able to get finished.

What if we could make Drupal 8 usable on production sites within months of its release, rather than a year after? Drupal 7 was released in January 2011 and saw very small numbers of installations until July 2011, when the numbers started to go upward. It wasn’t until February of this year that Drupal 7 actually passed Drupal 6 in adoption. And for that 6 months between Drupal 7’s release and Drupal 7’s initial adoption, Drupal’s install base actually flattened.

My personal, unscientific, theory is that having the single most important contributed module in Drupal in core itself would reduce that six-month period by at least half. Drupal 8 would be more usable and more marketable out of the box, and full Views integration into Drupal core would make it even easier to truly start treating Drupal as a CMS framework, something that many of us would like but have a lot of trouble actually implementing without the power of Views. Views in core could additionally help improve the pluggability of core’s architecture, not just in Views-related features, but elsewhere.

Given the improvements that Drupal 8 is likely to have over Drupal 7, closing that window seems valuable to everyone who has Drupal as an important part of their business model.

The second question that would be asked, then, is “How do I contribute resources?"

If you want to contribute developer time or project management time, just hook me up! Tell me how much time (and from whom) I can rely on. We are likely to need some ongoing resources, and we are also going to want short-term resources at sprints when we start doing mass conversions of smaller pieces of code. Developer resources are more likely to be useful later in the summer or fall after the heavy lifting is done; in the early stages there are fewer development tasks and more planning tasks and just getting the system ported to work with Drupal 8, and answering fundamental questions such as how we’ll convert to CMI and the like.

If you want to donate funds, either for time or for travel to sprints, there are a few ways. For larger organizations that might be willing to commit a significant value, such as Drupal shops or companies using Drupal, I’m actively working out logistical details, which will be detailed in a follow-up post. I can also do contracts and invoicing if I need to, but that might not be the best use of my time. We still need to work out the whos and hows on that; for now, the best thing to do is to talk to me directly. You can get in touch with me through my contact form.

For smaller amounts, I have set up a chipin, which you should see prominently featured in the sidebar. That will handle people who want to give a few bucks here to help the effort, without having to deal with invoicing and other paperwork. Any money given to the chipin will go directly to me, and chances are I’ll be passing that right along to the team.

So! I’m excited about making Drupal 8 ship with one of the single most important pieces of functionality out of the box, as well as adding “real-world" testing of the CMI and plugins systems in Drupal 8 well before release. This will be a tremendous win for not just developers, but everyone in the Drupal community.

If you want to keep tabs on the progress of the initiative, or help us out, we’re working in the 8.x branches of the CTools and Views modules, where you can see the work we started at the Twin Cities Drupal Camp, which will continue throughout the summer. I (and in my humble opinion the entire Drupal Community) would greatly appreciate any support you can provide!


Wow!! This is exciting news. Sign me up! I'm happy to help in anyway I can. :)

This is fantastic news! Congratulations and huge, huge thanks to the team!

What a great venture. I think we've shied away from this project just because it's such a huge undertaking and the Views UI was always a little hinky in old versions. With the UI drastically improved in Views 3 and Earl & Co. making the push, the prospects of this initiative are bright.

Just please don't rewrite the whole thing in the process (a la Fields in Core). :D

A lot of rewriting will be required just for CMI and plugins but it will not be a ground up rewrite. I think we can do this in stages and it will work. Crossing fingers.

That would be really awesome!
You should post that to drupal planet for reaching more people

Great news! I'll be around to lend a hand!

In case this campaign and effort works out, then we need to extend the feature freeze and shift the deadline for D8.

I'm a bit concerned on whether we'll be able to find sufficient developer resources. Most of the usual suspects in this (views/ctools/plugins-related) field are extremely busy with the existing core initiatives already, which is all voluntary time already and I'm afraid that those developers and their Drupal shops (if any) can't scale any further due to $dayjob work and obligations. Of course, this could possibly be remedied by exploring creative funding ideas.

Also wanted to especially say thanks for the very concise, straight to the point, and very well written post.

The whole point is that the funding will make those resources available.

I *believe* that if we bust a hump, we can have this ready enough by code freeze, but I do expect that might need to ask for a code freeze exception from Dries. We may not necessarily. We shall see. I am kind of hoping that we do less bikeshedding and more cooperative architecting on some of the trickier bits. Maybe I'm optimistic there, but that's why we have xjm. She's good at that!


While I think there is a huge benefit to seeing views in core, I have two concerns:

1. IMHO, Views is what it is today because it is outside of core. It has been allowed to have a faster release cycle and more feature additions. If it had been core it would have been limited to bug fixes. You mentioned that, "Views’ development needs have slowed as it has matured and gotten more feature-filled.", however, moving it to core means that we won't see any more features added between major versions of drupal. I am sure this can be solved in contrib, but would like to hear your thoughts on this, Earl?

2. Also IMHO, Views is what it is today largely due to you, Earl (Although there has been a lot of help from many members of the community). Therefore, when views go into core, who is going to maintain it? There was or still is a big backlash from the core dev community about making core bigger and more complex. Who is going to take on the ongoing maintenance of this?

Please also make it possible to donate small amounts to this effort. I am not a large dev shop, so investing thousands of dollars is not in the budget, but I would be happy to chip in what I can and I am sure many others can help $20 at a time.

1) Views is more or less feature complete and has been going fine with me spending less attention on it than ever before for about a year.
2) The community will maintain it like everything else, but I'm not leaving or anything. Daniel and I both intend to stick around and make sure that it is maintained.

The chipin (widget to right -- uses flash so, uh, if you don't have flash it might be harder) lets you donate any amount. Though smaller amounts are less because of payment processing fees. (2.9% + .30 per transaction, FWIW).

While pondering this a bit more, I came up with a few more issues:

3. What were some hard lessons learned from moving a major contrib project, like CCK, into core? My personal experience with this is that due to the limited timeframe to do it, several major features were left out. e.g. field permissions, field collection etc. I have a feeling we can learn a lot here and try not to make the same mistakes CCK/fields did

4. Modules that expanded upon CCK in 6 needed to work against a moving target when it was rewritten as fields in 7. This IMO contributed to the low adoption rate you identified in your post. I fear that this will happen again in D8 resulting in a similar low adotion rate. I am sure we will not see the benefit of earlier adoption rate moving views into core until D9

As great as I personally find this, one thing needs to be considered:
Further maintenance and bug-squashing would go into the hands of core contributors.
One issue that should be adressed in Drupal 8 was that the burden on core developers - that are by nature different people from working in contrib - can hardly handle the workload for maintaining Drupal 7 anymore.
Looking at the Views Issue Queue gives a picture of what would be added to the pile.

What is a compelling argument is that Core has to wait for Views anyway to be of any use, so it does not make a great difference if it is in core or contrib, core adoption depends on it anyway.

If all this can be sorted out: go for it!

Those issues are going into the system whether they're in core or in Views. In core there are actually more eyeballs.

Plus, in Views, the real problem are support issues, where we actually answer them. In core no one really does. We will have to address that. But the actual patch & bug queues are much more manageable. Unlike in core, where they're still fairly gnarly.

It seems that what is needed to prepare Views for Drupal 8 sooner, whether in core or not, is more resources. But it seems to me that pushing to get Views ready to go INTO core may well draw more resources to the project and get it ready faster. In any event, I don't think Drupal 8 release would be held back some months just waiting for Views to be ready. If Views does not quite get finished in time, it would simply be left out, perhaps to go into core in Drupal 9.... So I don't see any downside really myself.

Add new comment