Bitnami interviewed one of Drupal’s core contributors, Larry Garfield, for an inside look into the future of Drupal. With over 1 million active users it's easy to understand why Drupal is one of our most popular PHP solutions for content management, and why this application keeps evolving.
If you are just getting started or already a big fan of Drupal, this interview will give you some great insight into how Drupal maintains their community and what the future looks like for this application.
In the interview, Larry explains:
- Who uses Drupal
- How to get involved
- What new features we should expect
After learning more about the project, you can launch Drupal to the cloud or deploy it locally with free installers, virtual machines and cloud templates from Bitnami. Get started in the cloud for free with a $200 credit from Microsoft Azure.
Stuart Langridge: These are the Bitnami Open Source Leaders Series of Interviews. I'm Stuart Langridge, and I'm talking to Larry Garfield, who's a long-time Drupal core contributor. He's web services initiative lead for Drupal 8 and he's basically the de facto Drupal ambassador to the PHP world. Hi, Larry. Welcome to the podcast.
Larry Garfield: Hello.
Stuart Langridge: So the first obvious question is what's Drupal?
Larry Garfield: Drupal is an open source content management platform written in PHP. It's an enterprise-grade piece of software, and it's been used by large institutions from the White House to MTV to Amnesty International, the king of Belgium and so on, but it also scales down to small nonprofit, small company/corner store type sites and everything in between. It aims to be the CMS for the entire market spectrum with an emphasis on content strategy and content modeling by thinking of the web as more than just a bunch of pages but as content management that you can then expose on the web. That's really where Drupal's strength lies.
Stuart Langridge: You've named a bunch of organizations that are using Drupal from the very large to the very small. Are you deliberately targeting everyone from the very large to the very small, or are there particular types of organizations that you think Drupal is best for?
Larry Garfield: Drupal, the community, is large enough that there's someone targeting every possible sector. Drupal is very successful, and some of its most successful markets are government and education. One in four universities in the U.S. use Drupal. Also, publishing loves Drupal. There are a lot of newspapers on Drupal that have been using it for a long time. In terms of a focus, I would say upper mid-range type of sites provide enough content that doesn’t allow for manual editing. If you have three dozen pages that need to be edited and want to have a common header on them, Drupal will do that and do it well, but it is somewhat overkill.
Drupal is really good once you start thinking in terms of 'I have information and content I want to expose', and 'I want to be able to expose it in different ways'. This could mean on a web site or on a mobile app, but it could also simply mean 'I want to be able to push a couple of buttons and say here is'. For example, a news article, and on this page is a list of news articles and on this page is a list of news articles in a sidebar beside something else. With Drupal, you can do all of that by pushing buttons rather than writing code. That's really Drupal's mission statements, where people should be able to build content-rich, content-driven sites without having to write code or with writing as little code as possible. There's still a lot of customization you can do with code to Drupal, but we try and put a lot of emphasis into the site builder experience for the person who's going to sit down and push buttons to architect a web site. That’s something where we feel Drupal is, if not unique, then certainly one of the leaders in that area of 'I want to build something powerful but I don't wanna write code to do so'.
Drupal is really good once you start thinking in terms of 'I have information and content I want to expose', and 'I want to be able to expose it in different ways'. This could mean on a web site or on a mobile app, but it could also simply mean 'I want to be able to push a couple of buttons and say here is'. For example, a news article, and on this page is a list of news articles and on this page is a list of news articles in a sidebar beside something else. With Drupal, you can do all of that by pushing buttons rather than writing code. That's really Drupal's mission statements, where people should be able to build content-rich, content-driven sites without having to write code or with writing as little code as possible. There's still a lot of customization you can do with code to Drupal, but we try and put a lot of emphasis into the site builder experience for the person who's going to sit down and push buttons to architect a web site. That’s something where we feel Drupal is, if not unique, then certainly one of the leaders in that area of 'I want to build something powerful but I don't wanna write code to do so'.
Stuart Langridge: One of the things I did want to know is the level of technical knowledge you need to run Drupal. You’ve talked about two different types of people – content editors and then the people who run Drupal itself, the system administrators. Or is the idea that you really don't need system administrators and you don't need technical knowledge to be a content editor?
Larry Garfield: I would say there's two different roles. This is something of an open discussion within Drupal of who is Drupal for and who is the target audience, and I would say there's a couple of different important audiences. One is the content editor who should be able to enter content easily without having to be very tech-savvy. They should understand content such as creating an event instead of an event page, and they should not have to understand what PHP is. They should be able to understand 'I have content and it breaks down this way', and 'I'm going to create this collection of content and display it'.
Then there's we call a site builder, who needs to understand Drupal. They need to understand Drupal buzzwords like node, entity, views, node cue, view modes, and things like that. They build the business rules around what the structure of that content is and where to display it. So, the site builder sets up a site and creates structure of these content types and the fields they're gonna have. And then, they can have a list of faculty content matching that matches their rules in this format. All of that without writing code. That's a site builder. Site builders should be able to build the business logic, hand it off to a content editor who can then just edit content, select things in the UI and not have to worry about all of the business logic that was built for them by the site builder.
On some sites, those can be the same people, which is totally fine if it is small. I would say for most of my clients those are different people. Usually, at my company, Palantir.net., a Drupal consulting firm, we are the site builders. They hire us and say 'Here's our 100,000-page site, here's the kinda stuff we need, and figure out how to model that in Drupal'. After, we'll go through and do the content strategy by looking at their needs and what they want to do and what their design direction is. Then, we model that in Drupal by maybe building a little custom code for it, and putting a theme on it. After they pour content into it, and as they create the content, it just fills in the list over here, the list over there, a sidebar here, and this page here and so forth. And that's really the workflow of building a Drupal site.
Then there's we call a site builder, who needs to understand Drupal. They need to understand Drupal buzzwords like node, entity, views, node cue, view modes, and things like that. They build the business rules around what the structure of that content is and where to display it. So, the site builder sets up a site and creates structure of these content types and the fields they're gonna have. And then, they can have a list of faculty content matching that matches their rules in this format. All of that without writing code. That's a site builder. Site builders should be able to build the business logic, hand it off to a content editor who can then just edit content, select things in the UI and not have to worry about all of the business logic that was built for them by the site builder.
On some sites, those can be the same people, which is totally fine if it is small. I would say for most of my clients those are different people. Usually, at my company, Palantir.net., a Drupal consulting firm, we are the site builders. They hire us and say 'Here's our 100,000-page site, here's the kinda stuff we need, and figure out how to model that in Drupal'. After, we'll go through and do the content strategy by looking at their needs and what they want to do and what their design direction is. Then, we model that in Drupal by maybe building a little custom code for it, and putting a theme on it. After they pour content into it, and as they create the content, it just fills in the list over here, the list over there, a sidebar here, and this page here and so forth. And that's really the workflow of building a Drupal site.
Stuart Langridge: So site builders build the structures into which all the content fits and the content editors actually put things in it.
Larry Garfield: Right. And it's two very different workflows, honestly. One of the challenges of Drupal is trying to support both of those people, and that's where a good site builder can also build up additional administration screens without writing code to model. For example, a content editor's going to want to have to deal with news, so the site builder gives them some nice targeted workflows just for that. Another content editor is handling the entire museum collection section of the site, and they're going to have a different set of tools exposed to them. Drupal can do that very easily, and can have different custom screens set up for them. With Drupal core plus the right contributive modules and the add-on modules, you can do that with little to no code in many cases.
Stuart Langridge: So below all that, you're obviously actually deploying Drupal to, web services or some kind of a cloud. What's the release strategy like? I did notice that you just released 6.34 and 7.34, and there's a Version 8 in beta. What's the deal with all the different versions?
Larry Garfield: Drupal traditionally has had a stance of each major version we release and we support for two major releases. So Drupal 6 is our legacy release right now and it's been out for a long time. It's stable, and there's very little movement there at all, but there's still security support for it. Do not start a new site on Drupal 6 right now, because it is there only for people who already have Drupal 6 sites. Drupal 7 is the new current stable version, and that also is not getting new feature developments. That's just getting active maintenance, but that's also what most people with add-on contrib modules are targeting.
And I should make a tangent here that Drupal core on its own for Drupal 7 earlier is not all that useful. It is the platform on which you build a site using Drupal's contributive add-on modules, of which there are thousands. And that's really how you build a powerful modern Drupal site. It is just architecturally a deliberate decision that the core package itself for Drupal 7 earlier is not a complete system. You build your complete system on top of that. The idea is that once Drupal 8 comes out, then Drupal 6 support ends. Each major version does change APIs, and that's been done for a long time. The idea being that in order to advance the platform and not carry around lots of legacy weight, we're willing to break APIs between major versions. Sometimes we break a lot of APIs between major versions because it's kinda like the opposite extreme from Windows ME where Microsoft carried around a lot of dead weight for a long time and ended up with this train wreck of legacy code that they had to spend the next decade purging themselves of. Drupal has typically taken the opposite stance that a major version is a new thing.
With Drupal 8, which is the current development version, we are changing a lot of things, especially at the release process. A lot of the core system has been heavily refactored, heavily rewritten to use modern PHP techniques and technology to embrace the PHP renaissance. We’ve had a lot of PHP development communities come together and really started building reusable components that can be shared between projects, and Drupal 8 is kind of the poster child of that transition. A big part of that is a transition to object-oriented, interface-driven development, which means we can now extend the system a lot more easily without having to break APIs. So, starting with Drupal 8, we're going to move to a more traditional semantic versioning model where there will be an 8.1 that has few traditions but no API breaks, and an 8.2 that has few traditions but no API breaks, an 8.3 and so on. With 8 – 8.01, 8.02, 8.1.1, 8.1.2 and so forth for bug fixes and security patches as usual. So that's kind of the development cycle.
People deploying sites today should use Drupal 7. We're looking at a release for Drupal 8 sometime in 2015, hopefully earlier rather than later. However, we are an open source project, so we can't control schedules that well. Once you get to the release candidate stage for Drupal 8, I would start looking at that as your deployment target. It's a much better system than Drupal 7. Drupal 7 is not bad, and it's got 2 percent of the web as a market share. However, Drupal 8 is a huge improvement in capability, in extensibility, in internal quality, better user experience, better developer experience, easier deployment and updates between dev staging and production, and better multilingual support. It's been a lot of work, but it is paying off.
And I should make a tangent here that Drupal core on its own for Drupal 7 earlier is not all that useful. It is the platform on which you build a site using Drupal's contributive add-on modules, of which there are thousands. And that's really how you build a powerful modern Drupal site. It is just architecturally a deliberate decision that the core package itself for Drupal 7 earlier is not a complete system. You build your complete system on top of that. The idea is that once Drupal 8 comes out, then Drupal 6 support ends. Each major version does change APIs, and that's been done for a long time. The idea being that in order to advance the platform and not carry around lots of legacy weight, we're willing to break APIs between major versions. Sometimes we break a lot of APIs between major versions because it's kinda like the opposite extreme from Windows ME where Microsoft carried around a lot of dead weight for a long time and ended up with this train wreck of legacy code that they had to spend the next decade purging themselves of. Drupal has typically taken the opposite stance that a major version is a new thing.
With Drupal 8, which is the current development version, we are changing a lot of things, especially at the release process. A lot of the core system has been heavily refactored, heavily rewritten to use modern PHP techniques and technology to embrace the PHP renaissance. We’ve had a lot of PHP development communities come together and really started building reusable components that can be shared between projects, and Drupal 8 is kind of the poster child of that transition. A big part of that is a transition to object-oriented, interface-driven development, which means we can now extend the system a lot more easily without having to break APIs. So, starting with Drupal 8, we're going to move to a more traditional semantic versioning model where there will be an 8.1 that has few traditions but no API breaks, and an 8.2 that has few traditions but no API breaks, an 8.3 and so on. With 8 – 8.01, 8.02, 8.1.1, 8.1.2 and so forth for bug fixes and security patches as usual. So that's kind of the development cycle.
People deploying sites today should use Drupal 7. We're looking at a release for Drupal 8 sometime in 2015, hopefully earlier rather than later. However, we are an open source project, so we can't control schedules that well. Once you get to the release candidate stage for Drupal 8, I would start looking at that as your deployment target. It's a much better system than Drupal 7. Drupal 7 is not bad, and it's got 2 percent of the web as a market share. However, Drupal 8 is a huge improvement in capability, in extensibility, in internal quality, better user experience, better developer experience, easier deployment and updates between dev staging and production, and better multilingual support. It's been a lot of work, but it is paying off.
Stuart Langridge: Once Drupal 8 comes out, are you expecting everyone to essentially over to it relatively quickly? Obviously Drupal 6 will be out of support, but can Drupal 6 users jump directly to Drupal 8 on release day? Do they have to walk through Drupal 7 first, or how does that work?
Larry Garfield: That's actually something else that's changed. Traditionally what we've done is provide an upgrade path for data, for content between major versions. Between Drupal 6 to Drupal 7, you have to update your code. If you have custom modules you've written, you have to update those, and those APIs may have changed, but there's an update path for all of data in your database, so you don't lose that.
The changes for Drupal 8 are large enough that providing the upgrade path within the system is just way too hard, but that does not mean that we're abandoning our old users. What we're doing instead is building migration tools. There have been Drupal migration tools for a long time as add-on modules from the arbitrary system into Drupal. That framework has been implemented in Drupal 8 – or in the process of being implemented in Drupal 8, so Drupal 6 users will be able to do a migration directly to a new Drupal 8 install.
The idea is that you’ll want to build your new Drupal 8 site because the architecture you'll want to use in Drupal 8 is different than it was in Drupal 6. You can do so by using tools that are provided. Migrate all of your content across from Drupal 6 as if it were just an arbitrary external third party system. From there, you can suck all your content in and do that incrementally as you go, so you can have a Drupal 6 site up and running and build a Drupal 8 site. Just keep running that in the background, and when you are ready, flip a switch and now the Drupal 8 site is what you're routing web requests to and you're done.
That process is mostly working at this point, I think. There's still active development on it. It's possible that that will not be there for 8.0.0 on release. If not, it should be there in 8.1 where I believe we're extending security support for Drupal 6 a little bit to help smooth that transition. Also, the Drupal 7 to Drupal 8 migration tool chain is a work in progress since Drupal 7 is still going to have active security support for several more years.
At Palantir, what we often do is tell people skip versions. So if you're on Drupal 7, if it works for you, stay there and wait for Drupal 9. If you're on Drupal 6, you'll want to jump to Drupal 8. We have clients who are on Drupal 5 who skip Drupal 6, and go straight to Drupal 7 because usually that's a couple of years difference. After a couple years, you probably want to revisit your site anyway. Most of our clients do, which is actually another important thing I forgot to mention. We are also looking at a six-month release cycle for the 8.1 and 8.2 releases for Drupal 8, so that's a much more predictable cycle there as well.
Stuart Langridge: Are you expecting people who get Drupal 8, either by migrating an existing site or setting up something new, to stay in touch with the Drupal 8 point releases as they come out?
Larry Garfield: Yes. Our security team is very active but also almost all volunteer. We are expecting to say for the 8.0 line that its security stops when 8.1 comes out. But 8.0 to 8.1 should be a very simple transition. There'll be a last security release at the same time, which would be 8.06, 8.05, and then after that, please upgrade to 8.1. We're not going to break things on you. You'll get some nice new features, but that's also where the security updates will be going forward.
Stuart Langridge: Drupal being a web application, you obviously do a lot of work with browsers. How does it work with the range of browsers that are out there in the world? I suspect it works relatively well on modern browsers, but are you putting in extra work to take advantage of features that modern browsers provide? Can I still happily administer Drupal in my IE 6 machines or how does that work?
Larry Garfield: That's another one of the changes in Drupal 8. Drupal 7 supports IE 6 and up. For Drupal 8, we decided we're following the lead of everybody else who has already done this and only targeting reasonably modern browsers. This means the current Firefox, current Chrome, current Opera, current Safari and Internet Explorer 9 and above.
It was actually an interesting discussion when we were debating which versions to target, and it basically came down to the fact that Drupal 8 is gonna have a several-year lifespan. Do we want to get laughed at in 2013, 2014, 2015 for dropping support for IE 8 or do we wanna get laughed at in 2017, 2019 for still supporting IE 8 at that point? We decided we'd rather get laughed at now, so Drupal 8 requires Internet Explorer 9 or above or the current versions of everything else, which there really aren't legacy versions of anymore. What that means is we can do things like use local storage, use data attributes, use HTML 5 natively, use mobile first design for all of the internal default themes and so on.
We are really trying to be a modern front-end system as well, so there's a lot of CSS3 running around in the system. One of my favorites in Drupal 7, is this thing called overlay, which puts your admin section into a modal dialog on the screen that you can navigate through separately and then close to go back to the page you were on. This was a couple thousand lines of JavaScript that nobody actually liked, wasn’t responsive and had accessibility problems, so didn't really work out. But then we realized that the actually need was that I wanted to administer stuff and then go back to my site where I was without having to play around with multiple tabs in my browser.
We are really trying to be a modern front-end system as well, so there's a lot of CSS3 running around in the system. One of my favorites in Drupal 7, is this thing called overlay, which puts your admin section into a modal dialog on the screen that you can navigate through separately and then close to go back to the page you were on. This was a couple thousand lines of JavaScript that nobody actually liked, wasn’t responsive and had accessibility problems, so didn't really work out. But then we realized that the actually need was that I wanted to administer stuff and then go back to my site where I was without having to play around with multiple tabs in my browser.
So we built a new admin toolbar that is fully responsive that has a back to site button. If you go into the admin section, you get this back to site button that takes you back to whatever last non-admin page you were on. It's about four lines and it uses local storage, fully responsive, accessible and everybody wins. This means that we got to throw out the overlay module that no one actually liked and take advantage of the local storage is here. Now it’s trivially easy to do a back button for all sort of context.
Stuart Langridge: Let's talk about the Drupal community here. You mentioned your enormous collection of extensions, add-on things. I know that Drupalcon is coming up, and there's one in Columbia and one in Los Angeles. There are user group events, 2,500 or something of them around the world every year. What's most interesting to the Drupal core team and to Drupal users about the Drupal community? What do I get as a Drupal user because it exists?
Larry Garfield: The community is, I would say, one of the three core pillars of what makes Drupal a good system. One is good strong content management because we focus on content management rather than on just building pages. One is extensibility since we design everything to be extensible as it's just part of our culture. And the third is that there's a huge community that is very active, very passionate, very engaged and extremely welcoming.
As a new Drupal contributor, if you show up and say, 'I have these skills, I want to help, what can I do?', there is a team of people who shepherd new people like that. So you will just open the IRC channel, and you will get pounced by people who want to help you learn how to contribute. I've never seen that in any other community. It means there are hundreds of agencies and thousands of freelancers, and it may be thousands of agencies and tens of thousands of freelancers around the world that you can go to.
As a new Drupal contributor, if you show up and say, 'I have these skills, I want to help, what can I do?', there is a team of people who shepherd new people like that. So you will just open the IRC channel, and you will get pounced by people who want to help you learn how to contribute. I've never seen that in any other community. It means there are hundreds of agencies and thousands of freelancers, and it may be thousands of agencies and tens of thousands of freelancers around the world that you can go to.
If you don't like an agency you're working with, there are others you can go to. If you don't like a hosting company you're working with, there are others you can go to. If you want to hire people yourself, there are people you can hire. There's actually a very huge demand for Drupal developers and being able to use more conventional tools in Drupal 8 is part of improving that, so it'll actually be easier to hire Drupal talent at that point.
If you are building a Drupal site, engage. Engage with the community. Don't just wander off into a corner. If you have an issue with a contrib module, post that issue, post a bug report, post a patch. That kind of engagement, to a large extent, just like any other open source project really, is how you pay for it. Drupal is GPL, so there is no licensing fee to use anything. You can just download and walk away. Whereas with any other open source project, the way you pay is by getting involved and supporting the development process and supporting the community that builds it. And it's still much cheaper than anything else. If you have developers of your own, take some time, let them learn the system, let them start talking to people in the community, talking to the maintainers of the modules that you are using, and you'll get direct personalized support that way. You'll get knowledge what we should be doing, so I don't know if there's anything unique in that regard. It's just an active open source project, therefore, you want to engage with the community.
If you are building a Drupal site, engage. Engage with the community. Don't just wander off into a corner. If you have an issue with a contrib module, post that issue, post a bug report, post a patch. That kind of engagement, to a large extent, just like any other open source project really, is how you pay for it. Drupal is GPL, so there is no licensing fee to use anything. You can just download and walk away. Whereas with any other open source project, the way you pay is by getting involved and supporting the development process and supporting the community that builds it. And it's still much cheaper than anything else. If you have developers of your own, take some time, let them learn the system, let them start talking to people in the community, talking to the maintainers of the modules that you are using, and you'll get direct personalized support that way. You'll get knowledge what we should be doing, so I don't know if there's anything unique in that regard. It's just an active open source project, therefore, you want to engage with the community.
The Drupal's community, in particular, is especially active, especially friendly, and especially engaged. I will also say especially diverse as open source projects go. Drupal, by our best estimates, is a little under 20 percent female participation, which sounds low, but is also ten times higher than most open source projects. That's another advantage that you get because with a more diverse community there are more diverse ideas and better quality output.
Stuart Langridge: Where's Drupal going next? Obviously the big target for 2015 is Drupal 8, but apart from the stuff that you've described already, what does Drupal 8 bring us at the high level, and what's coming after that? What are the plans for the next year, or the next five years?
Larry Garfield: So what does Drupal 8 bring? Drupal 8 brings is taking the best of the Drupal contributed world and building that into the system. For example, I talked about wanting to put a list of events at this URL ordered this way shown in this format. The tool you use for that in Drupal is called Views. It's one of the most popular if not the most popular add-on module to the extent that no one actually views it as an add-on anymore, so we just baked it into Drupal 8. We were then able to rip out a lot of the one-off code that was in the core and use that instead. We finally have a rich text editor built in, but it's not just an edit box like WordPress has. It's integrated into the front end too, so we do have edit and place support, so for small/quick edits that we call the Quick Edit tool. You go to a page, you click "Quick Edit”, correct some text on the page right there, hit save, and you're done. Just like the in-place editing on Flickr or Facebook. If you're actually doing content modeling, you'll want to be using the full edit interface, but it's really good for quick one-offs.
One of the largest problems with Drupal in the past has been deployment because Drupal 7 earlier stores its configuration in the database, because users are editing the configuration on a regular basis, so you need to be able to have that user editable. That made deployment between dev states and production more difficult, and there have been tools to work around that. For Drupal 8, they solved that problem for reals by baking that in, and we now have a really solid configuration API that includes export, import. Now you can do real configuration deployment with Drupal 8 that’s fairly straightforward.
We have built-in support for web services, so all of your content out of the box, is now available as web responses and using the HOL – hypertext operational language format. You can build a headless system in front of Drupal 8 with Angular or Ember or whatever your flavor of the week is. You can build a mobile app that talks to Drupal 8. You can build a desktop app that talks to it. It's really designed to be more robust for what people keep using Drupal as, which is as a nexus to talk to different systems. Most of the many projects I've built at Palantir.net have been integrations with a museum's catalog, integrations with a university's course management system, and that kind of integration of multiple systems is very common in Drupal, and so that gets even stronger in Drupal 8.
One of the largest problems with Drupal in the past has been deployment because Drupal 7 earlier stores its configuration in the database, because users are editing the configuration on a regular basis, so you need to be able to have that user editable. That made deployment between dev states and production more difficult, and there have been tools to work around that. For Drupal 8, they solved that problem for reals by baking that in, and we now have a really solid configuration API that includes export, import. Now you can do real configuration deployment with Drupal 8 that’s fairly straightforward.
We have built-in support for web services, so all of your content out of the box, is now available as web responses and using the HOL – hypertext operational language format. You can build a headless system in front of Drupal 8 with Angular or Ember or whatever your flavor of the week is. You can build a mobile app that talks to Drupal 8. You can build a desktop app that talks to it. It's really designed to be more robust for what people keep using Drupal as, which is as a nexus to talk to different systems. Most of the many projects I've built at Palantir.net have been integrations with a museum's catalog, integrations with a university's course management system, and that kind of integration of multiple systems is very common in Drupal, and so that gets even stronger in Drupal 8.
So really Drupal 8 is on the user level; Drupal 8 is bringing together the best of breed from the Drupal ecosystem into a much more cohesive platform, and it's really that transition from system to platform that's happening with Drupal 8. Also, just being a much more robust out-of-the-box experience for building a modern, robust content-driven experience. At the developer level, Drupal 8 is a much bigger revolution and brings much more stable code, much more familiar code. Let's be honest, Drupal 7 earlier had a very unique and idiomatic API architecture, and by your giggling, I take it that you've worked with it.
Stuart Langridge: I like the description. It was tactfully done.
Larry Garfield: Thank you. For Drupal 8, we have brought in over a dozen different third-party libraries and rebuilt the system around those, so we're using the Symphony core pipeline from a Symphony framework. We're using these end feed library for RSS and atom parsing. We're using Guzzle, which is an HTP client, so if you want to connect to one of those third-party systems to do an integration, it's a lot easier now, it's a lot more robust, you have a lot more capabilities just out of the box. Drupal 8 has really been at the forefront of getting rid of the “not invented here” attitude that's plagued the entire PHP world for a decade, and we were replacing it with “proudly invented elsewhere” because everybody loves pie.
Stuart Langridge: That PHP renaissance idea that we can now build reusable components, and more importantly, find existing reusable components and then reuse them, that's an important part of Drupal's new approach, yes?
Larry Garfield: Absolutely, that's a transition that's happened in the PHP world, kind of concurrently with Drupal 8's development. Drupal 8 did not cause that transition, but I usually say it's been a major part of that transition. It's kind of the poster child for it. The argument that I've made in presentations before is: if Drupal, of all projects, can make this transition from a quirky idiomatic proprietary architecture and API to a modern shared architecture using common tools, using familiar patterns, which then makes life easier for developers to build more robust systems, anyone can.
And yes, it's a big transition, but it's important, and, from the looks of it, a successful transition. The result being that it should be a lot easier for new developers or experienced developers to just pick up Drupal 8 and run with it and then extend it in ways we never thought of. As a developer building tools for other people, when someone can use a tool I built in a way that I never expected, that's success, and I expect that to happen a lot more with Drupal 8 than with earlier versions. It happened a lot with earlier versions too, but I expect it to happen even more with Drupal 8 where people will be building types of sites or types of add-on modules that I didn't even occur to me would make sense to do, but oh, look, there it is because the system is robust enough to support that and the architectural style is familiar enough that someone who used Symfony, Zend, or any modern system can just dive in and pick it up with relative ease.
Good story there, actually. I was giving a Drupal 8 training at a conference last year, and one of the people in the audience wasn't even a PHP developer-he was a C-Sharp developer. But Java, PHP, C++, C-Sharp, they all have a very similar object-oriented model and mindset. So, I was walking through services and dependency injection and all these things that are new for traditional Drupal developers, and he says “I got this, no problem, whatever, it's a little bit of syntax, fine”. This army of corporate Java and C-Sharp developers can now work on Drupal 8, too, without a ton of retraining. They don't have to completely start from ground zero. That's a huge influx of potential Drupal talent that companies using Drupal probably already have. Also, people who want to escape their Java doldrums job can transition over to Drupal 8 a lot more easily and do all kinds of things that we didn't think of to help feed the demand for more Drupal talent for more Drupal sites. It really is a game-changing transition and is a very good game-changing transition.
Good story there, actually. I was giving a Drupal 8 training at a conference last year, and one of the people in the audience wasn't even a PHP developer-he was a C-Sharp developer. But Java, PHP, C++, C-Sharp, they all have a very similar object-oriented model and mindset. So, I was walking through services and dependency injection and all these things that are new for traditional Drupal developers, and he says “I got this, no problem, whatever, it's a little bit of syntax, fine”. This army of corporate Java and C-Sharp developers can now work on Drupal 8, too, without a ton of retraining. They don't have to completely start from ground zero. That's a huge influx of potential Drupal talent that companies using Drupal probably already have. Also, people who want to escape their Java doldrums job can transition over to Drupal 8 a lot more easily and do all kinds of things that we didn't think of to help feed the demand for more Drupal talent for more Drupal sites. It really is a game-changing transition and is a very good game-changing transition.
Stuart Langridge: It will be great to see it released.
Larry Garfield: Yes.
Stuart Langridge: So thank you very much for talking to us, Larry Garfield of the Drupal project.
Larry Garfield: Thank you.