231: So how is it working with Drupal 8 every day, Michael Schmid?

Michael Schmid, Group CTO at Amazee, sat down in my Cologne office in March 2016 with the idea of comparing the promise of Drupal 8 to the real life experience of him and his teams. The conclusion? It's already great and will keep getting better. With so many Drupal 8 projects now underway, I expect to be hearing a lot more of this sentiment in the near future! Below is a full transcript of our conversation.

Interview video - 41 min.

Guest dossier


Section headers:

  • Welcome to my Cologne Office!
  • The history of Amazee Labs
  • Too many features is too many features
  • From Drupal product to Drupal services
  • April Fools
  • Drupal 8 Delivery Boot Camp
  • Boiling it down: Focus
  • Drupal 8, the product
  • Less contrib, more core
  • And it all comes together ...
  • Working with Drupal 8 now and in the future
  • More devs, more community, out-of-the-box

Welcome to my Cologne Office!

jam: We are sitting in my office in Cologne, the office that I share with the Coder-Themer wonder twins, Campbell Vertesi and Adam Juran.

Michael: Do they actually fight like during the days sometimes?

jam: So, I’m kind of like the office dad and I literally used to walk-in and catch them practicing Kung Fu, karate fighting stuff, and I got really upset with them, and so, they never do it when I’m around.

Michael: So, they have a Jam-Signal somewhere?

jam: I don’t know, but it was – I literally walked to the office sometime. They’d be like So, yes. I don’t know. I wasn’t cool with it. Anyway, this couch in the office is kind of turning into the podcast couch. I’ve spoken with a few people here. Campbell and I did a podcast with the PHP Unit maintainer, Sebastian Bergmann, who doesn’t live too far away. I had the HR vice president from Hootsuite here which was really, really cool talking about putting open source methodologies in thinking into HR which is really very interesting.

The history of Amazee Labs

Now, I have Michael Schmid, CTO of the Amazee group.

Michael: Correct.

jam: Which today comprises three global offices. Zurich, Austin, Cape Town plus a company called Amazee Metrics. How many people worked for Amazee Labs nowadays?

Michael: Altogether, I think it’s 34/35, something like that.

jam: Okay. That’s an interesting size.

Michael: It’s a good size, yes. So, one of the things that we say is that we don’t want to grow too big in each location. So, we want to keep the locations rather smaller. So there’s like number of 18/19 people because we feel that’s a really nice size that is still the team. Everybody knows each other, we can sit together at the table, but again, we want to grow as a whole company so that’s why we have different locations. So in total, we have more than 18 people. We have like 33 all over the world.

jam: Right, and if you have three locations, then these locations can grow to 60 people and then you’re going to have to open more offices.

Michael: Correct, yes.

jam: Cool. Now, Amazee amazingly has been around for just about 10 years.

Michael: Correct. Next year is it’s 10-year anniversary, yes.

jam: And you didn’t start as a digital agency at all.

Michael: Not at all.

Too many features is too many features

jam: Back when I first heard of you, somebody told me there is this Drupal site called amazee.com and you can use it for fundraising or something. Now, cast your minds back 10 years ago, that there wasn’t Kickstarter and there wasn’t IndieGoGo, right?

Michael: No.

jam: What was Amazee.com for?

Michael: So, the main idea was to provide a platform for people to organize their groups and projects online. Like Kickstarter didn’t exist. Facebook groups didn’t exist and other ... Base Camp, I think was around, but not used for the things that they use it today. So, the idea was to have a platform where people, if they have an idea, they can create a project page, can invite people to their page, and they can share or communicate, and organize themselves. You had the blog, you had the newsfeed, you had the picture gallery, you had file sharing, you had private messaging, you had a forum. It was all the tools we used today in different platforms, all on one. And also, we had fundraising. So, a lot of people thought that we are a fundraiser, but for us, the fundraising was just another piece on the right side of a project page that you can also enable it if you want, and yes. So, that’s what we started with.

jam: That’s an awful lot of functionality in one place.

Michael: Yes, I made once a list of all functionalities, and I probably ended up at like 55 features that the website had.

jam: Now, Amazee.com as a platform is not around anymore. What was great about it and what doomed it to fail?

Michael: What was great about it is that we had an investor that gave a massive money into it and we could really sit down and implement whatever we wanted, and anybody that brought up an idea like, “Couldn’t you do that?” And “Let’s not do that.” And “You know what? We can also combine that.” We implemented it, like we made a lot of people happy. Like basically, everybody was the product manager of the website. If somebody brought an idea, we implemented it, and that was great because we had a small group of people that used it. We had really good connections with these people. They came into the office and told us what they want to use it for. That was awesome. The problem was at the same time, we had so many features that it was really hard to explain what it was. Still, I cannot explain it to you right now in one sentence.

jam: Okay. So, it was not elevator pitchable?

Michael: No, not at all. It was hard to use because you had so many different functionalities. Also, the problem was, a lot of people used it for completely different things. So, marketing it was really hard. Selling it was really hard.

jam: So, it sounds like it’s kind of the difference sort of between Drupal when you first turn it on which can be anything and some software as a service thing where I go log in and I’ve got a user journey that goes from A to B to C to Done in a very focused way.

Michael: Correct, yes. And so, that’s also the reason why it doesn’t exist anymore. We had so many features on it and it was so hard to maintain them. It was really hard to make them really, really nice from usability point of view and because in the beginning, we didn’t give a lot of shit about usability which was implemented. We had a checkbox at the bottom right that you have to click first before you can click the one above ... like all these horrible usability mistakes. So, we had a lot of features and then at one point, we ran out of money like we had an investor. He gave us money and at one point, you will have it all in used, but we’re never able to make our own money. So, the idea was to have premium accounts where people pay per month and advertising, and we barely made any money.

From Drupal product to Drupal services

jam: So, this was in Drupal 5.

Michael: Yes.

jam: And Amazee is still doing Amazee. Global Enterprises, Inc. is still doing Drupal.

Michael: Yes.

jam: So, you had a chance, it sounds like to really learn Drupal and get a lot of things wrong. What was the transition into becoming Amazee Labs and doing Drupal – what’s the old saying? “Doing Drupal like it’s our job?”

Michael: Yes. So, we had a platform and we didn’t make enough money to sustain ourselves as a company. So, we were really thinking and the first idea was to cut down features, to implement better features and make them. So, we threw out half of all the functionality and implemented that better, but again, it was just we didn’t have enough time. So, at the same time, other companies came to us and said, “Hey, we really like the tool that you’ve built. Can we have it, but with our logo on top?” So, we started doing White Labelling Solutions. At the beginning, we were like, “No, no, no. We don’t want to do that. It’s not our focus. It's not our business model. We just learned we have to focus ...” But it was the only way to make money. So, we did that.

jam: Focus on paying your rent.

Michael: Yes. So, we did three projects, White Labelling Solutions, so-called, where people can do or we build websites, the same functionality, different theme. Maybe a slightly different functionality in terms of like how some things behaved and yes, the problem was, after the third site, the request of the clients were bigger, and bigger, and bigger. And so, “Can you change the front page? Can you do that? Please remove that, but add that thing. We need integration of that,” and at the same time, the Drupal community went on. Drupal 6 came out. A lot of modules were much better and we still stuck in Drupal 5. Upgrading the whole thing to six looked impossible, and then we realized, “Hey, the community is so far now, we can do everything with Drupal 6. We don’t have to use our own tool that we implement. We don’t have to use the White Labelling again anymore. We can just use Drupal, what it is out of the box with all the contrib. modules. So, we did the first project there and somehow it was much better because of the tools. We’re more advanced. It was easier to work with and so, we just kept doing that. So, we implemented more and more things with a completely fresh Drupal version.

jam: So, at that point, tell me between then and now, why did you stick with Drupal?

Michael: It was the thing that we’ve done. There was not a question of ... It was working. We made our clients happy. I mean, it has a lot of Drupalisms. I mean, Drupal 6 like if you try to – there was no object oriented code, it was everything was completely different than any other PHP tool out there, but we were small. We had a really good knowledge about it and we were really happy because especially at that point, the whole side building part, that you can set up the site without actually needing to code. That was for me was a really cool tool that you can use in a lot of different ways and if you need to change something, you just go in there and change it. And so, that was never a question if you wanted to switch, whatever. We were really happy with the tool that we had.

April Fools

jam: April Fool’s Day 2014, what happened?

Michael: Yes, correct. So, Drupal 8 was in Alpha 6 or so at that point and we’re talking about like, “Hey, what do we want to do for April Fool’s Day?” So, one idea that we had is, “Let’s relaunch our website in Drupal 8.” And so, we did it, but we did it in the Bartik theme. So, we set up a Drupal 8 site. We copied all the content over from this Drupal 7 site and we just launched in Bartik. AmazeeLabs.com completely blue, Bartik.

jam: So, like that classic ugly old Drupal -

Michael: As classic as it gets.

jam: As Drupal as it gets as well.

Michael: Yes, as Drupal as it gets and we launched and nobody got it. Everybody wrote us saying like, “Hey, there is something wrong because the wrong theme is loaded.” Because nobody’s using Bartik for their sites.

jam: Also as Amazee’s quite known for doing nice design, so, you’d never actually do that.

Michael: No, nobody would, yes. And so, everybody was so like, “Hey.” Like people wrote me, “You know, I had the problem, the same like in my eye. I try to myself and yes, it loads Bartik all the time.” So, go to drupal.org and there’s an issue that explains you why Bartik is loaded, and we were like, “No, no. It’s all good. We were just super happy, it’s Drupal 8. Yay.” It was Drupal 8 like it was all good. And, yes. Second April, we announced, “Yes, sorry it was only for April Fools.” But what we actually started already in February 2014, we started to implement our site in Drupal 8 already with a proper theme. So, end of April 2014, we launched our Drupal 8 – AmazeeLabs.com in Drupal 8, alpha 6-something with a proper theme and also multilingual.

Drupal 8 Delivery Boot Camp

jam: Now, that made it one of the first 3, 4, 5, 10 public Drupal 8 websites and it’s been online in Drupal 8 since then.

Michael: Yes.

jam: We were talking before about how that ended up preparing your company, your team to hit the ground running. So essentially, you had a kind of a Drupal 8 boot camp ...

Michael: Something like that, yes.

jam: .. Going on from early 2014. Almost two years before Drupal 8.0 hit. What are the kind of things that you and your team had to do to keep the site in Drupal 8 and keep up with the releases that were going on?

Michael: So, that was a really big worry from the beginning because we knew there will be no upgrade path and what I was really hoping when I took the decision with the team that we want to do it in 8 is that yes, there will be pain in upgrading it because most of it you have to re-implement or you re-implement a new one then you make your own migration script. That’s what we actually did. So, we migrated, I think four times and all the time, it took at least around 40 hours of work and we wrote big migration scripts and we published all of them because we said if anybody else is as crazy as we are, here is the code that we wrote.

jam: Right, but configuration at that point was still not all in Yaml files and then the Twig implementation wasn’t finalized at all and APIs were not even frozen.

Michael: No, it felt like – yes, and that is also the thing that I was really hoping for, is that when we have to upgrade, is that we have to go into a depthness of Drupal 8 to understand what really has changed that we learned more about it and that’s exactly what happened. My team told me that while working in the older versions and upgrading it, they learned so much about the inner workings of Drupal 8 that now they feel more comfortable in even now implementing production sites because ...

jam: Even if it’s at a level that they don’t touch on a daily basis?

Michael: Correct.

jam: Is that because they understand why the system is like it is now?

Michael: Yes. So like now, if you see a White Screen of Death in Drupal 8, that’s like, “Now, I have to use a step debugger and what to figure out.” For my team, that was part of the upgrading, like basic upgrading is just, “Okay. Put the new code. Start the site. WSOD. Okay. Step debugger. Step, step, step, step, step, fixing. Next, next bug,” it’s just something the whole situation of failing or of handling a tool and trying to figure out what is ...

jam: So, they’ve lived in it?

Michael: Yes, they embrace the situation ... and now, the team is not afraid of even now like the thing probably we have now with alpha versions of contrib modules all the time. You install it, Boom! White page. That’s not something bad because we know, we have tools to go into the code, step debugging and in profiling and figuring out what’s happening, and also a lot of things – they’re the same things or broken all the time. Like the beginning, like the whole menu system broke or changed. Breaking changes in the menu system. All contrib modules are broken. If you fix one, you know how to fix the other one. So, it’s just like we learned a lot of things and also what I really like is we were up-to-date of what is happening in the community. The community took a lot of decisions and all of these decisions affect us now and for people that just started doing Drupal 8 right now, they’re confronted with all these changes, and a lot of the changes you don’t know why, but for us, because we were part of it, we understood because we had to work with them. You read through the issue queues. You go. You read the change notice and you understand, “Oh, that’s why this is like that.” And so, now when we implemented, we know why things are like that and you understand them more and you embrace them more, and you like them more because you know why things have changed.

jam: How much did that let you contribute to Drupal 8 along the way?

Michael: So, one of the things that I realized is with just doing it, we contributed a lot like just the people can say, “Hey! There are already production sites live!" helped a lot because people started to believe in it and I had a lot of people that just came to me and said like, “I would never have done it, but it’s good that you’ve done it because you showed it’s possible.” I gave presentations like DrupalCon Austin that I showed, “Hey, you can build production sites.” And a lot of people walk out of there and said, “I got to do it now because you showed me it’s possible.” And so, that was one contribution that I only realized later on that was one.

One of them that we totally did whenever we found a bug, whenever we found a contrib module that was broken and we fixed it, we contributed patches. So, it was a lot of tiny pieces of patches that – but a lot them. Let’s say like – because one other thing that I see a bit of the Drupal 8, how we implement it before - actually, somebody’s going to use it in real life. A lot of cases, you never figure out. Like I was part of the multilingual team and I was thinking, okay, we figured everything out, and then you start the first site and then you realize, “Wait. What do I do if that blog post is in English, but not in German, but in French?” So like all these cases that you never thought about and we ran into all of them.

One other thing is also the whole experience of a person starting to use it like I’m really sorry, but for everybody that – there was a breaking change couple of days before the go-live which where we changed the "staging" directory of CMI to "sync" directory and we threw away the "active" directory because that was one thing. For the people in the CMI team, who are brilliant ... I mean, I love them that they implemented CMI, but they’re so deep into the system. For them, it was completely clear why the whole thing was called staging. My developers started using it and they saw a "staging" folder and they said like, “So, is that the folder where the configuration for the staging site goes?” It’s not, but I had five people asking me the same question in three days because they all started using Drupal, and they realized, “Oh, wow. There is a problem.” If we don’t change that now, we will have thousands of people all over the world. So, we had the possibility to give it to new people that didn’t use it before and ask them how does it feel in using it, and that’s like, that’s a really strange stuff and the good stuff is we could still fix it.

jam: So, that was actually getting it out in the wild early, helped make it a better production system later?

Michael: Correct, yes.

Boiling it down: Focus

jam: Now, as a business person, as a digital agency, you, I’m sure – so, first of all, your first experience, you were your own worst client.

Michael: Correct.

jam: Because you asked for every feature in the world and you gave it to yourself.

Michael: Yes.

jam: How does that inform your conversations with clients today?

Michael: A lot. We have so many clients that come to us and say like, “I want to have a combination of - but why never implement in somebody with Flickr and Facebook, and let’s add some Amazon in there, and then a sprinkle of Azure.” If somebody would build that, that would be the best tool.

jam: "I have the killer business model!"

Michael: Correct. Facebook and Flickr, or I don’t know, and I mean, there used to be a lot of discussions that I explain, but now we have an actual case. We can show them, “Look. This is the amount of money that we spend ourselves and it was a lot of money that we spent ourselves."" And it was a lot of money that we burned with Amazee.com. And we can tell them from firsthand experience and then they somehow trust you more because they see you, “Okay. You went through it.” And you explain them all the pain that we went through with it and then they really start to listen to you and believe you that if you just focus on one thing, if you do that really well, then you can add another feature, and then you can add another feature because one thing that I painfully learned with Amazee.com, we had a lot of features. All of them are kind of broken. We looked which of the features are actually used. And we said, “Okay. These five features are only used by a super, super, super tiny amount of percentage of people.” And we kicked them out, but you get e-mails, angry e-mails from maybe that single person that used it. And so, you feel really bad because you made somebody unhappy. If you implement five features first, that person would have never had that experience of, “You took away something from me.” So, implement five features first. Make them really good and then add a second or add a sixth, a seventh and then eighth, and that’s all so much better from a marketing point because you can go out and say, “Hey, we added another feature.” [That's better than, "We're really sorry," if you removed the feature.

jam: So, focus is important.

Michael: Focus is ultra important.

jam: Talk about your functionality formula for clients. "I want these 30 things! Go!"

Michael: Yes, whenever we see like a feature set and especially if the budget is tight. I mean, feature creep and a tight budget. You tell them it’s not possible. So, what we start to use at Amazee was: remove every feature until it starts to hurt. Like where you feel comfortable and say like, “Yes, what’s okay.”

jam: So, this is with a client and you get them to the point where they can’t possibly cut anything out.

Michael: Yes. So, you go there and it’s already hard. Then you tell them now we cut again by half.

jam: "You’re allowed to have half of this."

Michael: Yes, and it’s a really painful process, but if they understand and that’s so good about the web, how the IT, you can add new things at anytime. You can swap out new things. It’s not like a house where you can say, “Okay. Now, I don’t like the basement. Let’s change it.” That’s not possible in the house. I mean, it is, but it’s going to be really, really, hard to just leave the house, change it ... In the web, that’s not how it works. And so, we can change things on the way. We can learn from experiences and we can add new things, we can remove stuff. So, the more focus you have from the beginning, the earlier you will go live, the earlier you will have real user feedback, and the earlier you will be sure that in the direction that we go, is that actually the correct direction or not.

jam: Right, because it could be the direction that you think that the project or the product is going to go is not where people actually take.

Michael: No, not at all.

jam: And if you give them too much chance to go and do whatever they want with your 55 features, then you will upset them when you eventually pivot away from that.

Michael: Correct, and also, you will never be able to launch 55 functionalities in a really good usability and functionality.

jam: Right, and the way that I explain this to people essentially is the majority of people spend the majority of their time now on the internet on their pocket super computer, right?

Michael: Yes.

jam: And on the phone screen, I’m going to be able to fit in three things for you, right? So, what is your business really about? What is it? So, what are the three things that people need to be able to see and understand about you, the first time they go to your site? Because it’s much easier to add than to take away.

Michael: Correct, yes.

Drupal 8, the product

jam: So, that’s cool. Now, I have this feeling that Drupal 8 is the most "productized" Drupal and that it does give us an incredibly useful focused feature set out of the box compared to any previous version of Drupal where we had poll module and blog module, and things that were useful to a certain subset of people, but you couldn’t turn them off, they had to be there. I have a feeling that Drupal 8’s really focused now. What do you think about that?

Michael: Yes, one thing that we had to learn when we started two years ago, there was no contrib module at all, but there was Views in Core, and there were like entity references. And all these things were there. So, a lot of things we realized, okay, we have to work with the existing tools and that forced us to rethink how we do stuff. A lot of times, in seven, "There’s a module for that!" We all say that and you install it, but actually you could have implemented with the tools that are already there. You don’t need the module for that, and so, that’s where I really like Drupal 8 that it’s like that the tools that are in there allow you to do a lot of great things without adding more contrib modules to it.

jam: And just the fact that every data object is an entity and every entity is fieldable--and fields are also entities so they’re fieldable, right? You have a universal set of CRUD operations, a universal way of addressing and manipulating them ...

Michael: And that’s focused ...

jam: A user and a comment, and a node and whatever it does are all equal citizens, right?

Michael: Correct and for me, that’s the focus like we focused on unifying things. Where in 7, you had to learn, okay, the Menu API works’ different than the user and the node and taxonomy ...

jam: But this allows you to take this basic building set of the single download that works really well and take it much, much further than any other Drupal was able to go.

Michael: Correct, and we had so many experiences where we said like, “No, that’s not possible. We need the contrib module for it.” And then it just took an hour sitting on a white screen or on a white board together with the team and started brainstorming. I realized suddenly, “Hey, we can actually with the block system, the entity references, and nodes and content types and custom blocks. You can do it and that was one thing that I really felt confident, still feel confident in implementing big Drupal 8 sites right now even though the contrib modules are maybe not there yet.

jam: Do you think that we’ll need fewer contrib modules in the end for Drupal 8 because the core is more capable?

Michael: I, 100% believe that and if I look at the size of sites that we build right now in 8, now it’s either like middle sized, they’re not only the small ones. We go to the middle ones. We’re not really building the really, really big ones, but if I compare the middle size, amount of contrib modules compared to the same what I would need in 7? Yes, it’s probably a third of contrib modules.

Less contrib, more core

jam: So, but the best example of your case in a country with four official languages, right? Everything you build in Switzerland essentially has to be multilingual with at least two languages probably three or four.

Michael: Four, sometimes five. Yes.

jam: So, multilingual is really important and in Drupal 7 to build a really properly localized, translatable website. You needed 27, 30 modules?

Michael: Something around that.

jam: And then it was really, really hard and they were built in different times in different ways, and it was a lot of work, right? Now, you don’t need any contrib modules because you can turn on four modules in core.

Michael: Correct.

jam: How was that experience working with multilingual? Like how much time do you say with multilingual projects now would you say?

Michael: I wouldn’t say we save a lot of time yet because we added some new things in there that are unknown like config translation did not exist in Drupal 7. So that is like ... to understand the workings of that ... and there’s only entity translation which is now called content translation, but it's the entity translation of Drupal 7 ... I think three or four years ago, we decided we’re only going to use the entity translation for Drupal 7, but still it's a bit different. So overall, I would definitely say it’s much better experience in terms of how many modules you need to install, how many different things are, but there are still new stuff that we have to understand. So we’re still spending a lot of time in understanding. Also, one other problem is that contrib modules, they’re maybe not so multilingual-aware like we just had big issues with Paragraphs and how you translate them. It works though, but it’s just more like how to learn, how to understand, how it works and stuff like that.

jam: So, you’re still in the learning curve for really wrapping your heads around the possibilities that it offers you and you’d say the core systems work great, contrib is still catching up, and module developers need to understand and acknowledge these possibilities and build them in?

Michael: Yes. Well, we try as core to basically make it at as transparent as possible for every module developer, but still there are things especially like Paragraphs which loads entities for you based on another entity, and you just need to make sure that like the whole, the translation objects or the language objects are passed in. So, it’s not a bit of understanding exactly how it works, it’s just using the APIs correct, and that’s a bit of a process that happens a lot, but if you figured that all out, I would totally believe that in the future, probably in the next six months or so, we’ll be twice as fast in doing multilingual sites and stuff like that.

jam: Fantastic. Of course, paragraph as a module is a perfect example of this – now, in Drupal 8 that everything is an entity and fieldable and fieldable and fieldable because it’s just an entity with a bunch of thing packed into it as references now?

Michael: Correct.

jam: Yes, I haven't looked at the code for the Drupal 7 version. I don’t even know how they would have - that’s exciting.

And it all comes together ...

Michael: Yes, and there’s other things like one really fun one is I had multiple people in the team that used metatags for Drupal 7. Drupal 7, you install it, and it’s all there. Drupal 8, there’s nothing there. We install the module, empty, and you go to the content type and, “Where do I put the metatag?” And you see like it was like, “Hey, look. I installed metatags and ...” And the fun is actually if you go to the configuration page, it only shows you one field and it’s called phone number. There’s special reason there is that, but people are like, “No, the module is broken, whatever. That doesn’t work.” And then they search more and they realized metatags are now a field.

jam: Yes.

Michael: And if people, if they look at that and you see their mind like, poof! like they realize, “Oh, it’s a field so I can metatag users and I can metatag notes, I can make metatag ...” Then, that’s like the point where people understand like all these puzzle pieces like flowing around and suddenly they’re connected and then they are really strong.

jam: Damien is the maintainer of metatags, right?

Michael: I think so, yes.

jam: He and I were talking and he was ... At the point when we’re talking about it. they were working on getting the module really, really solid, and then they were actually going to put in a lot more default tags for people to find, but I guess it’s not quite there yet.

Michael: They are really heavy working on it right now. I mean, we use paragraphs for everything right now.

jam: No, no. Metatag.

Michael: Oh, sorry. We used metatag on every site because you need it everywhere like a website without metatags, I mean, yes, I think you miss a lot of the things out if you’re not properly giving metatags to search engines and crawlers and stuff like that.

Working with Drupal 8 now and in the future

jam: So, I think the final end, biggest question on my mind about Drupal 8 now. We’re in the early 2016. It’s been out for five or six months. It looks like it’s starting to pick up. Contrib is starting to catch up. Lots and lots of modules are being migrated to Drupal 8. See my Drupal 8 module for the week blog post series, please on dev.acquia.com. I’m having a lot of fun doing it. It feels like we’re in a good place. It feels like Drupal 8 is the technology that we were hoping for, that it’s still relevant ... How does it feel for you? What do you see in our future and most of all how is it working with Drupal 8 on a day to day basis for clients?

Michael: It feels like the things that everybody was waiting for. Everybody was desperately waiting for that. On one point, it was really good that we implemented all the things that it took so long. On the other side, it was really painful, but that is all over now. It’s out there. Use it, and try it, and it really feels something that in the days of working, it feels complete, it feels really good, and everybody is happy in terms of like – backend developers are really happy about how the whole system works on the PHP level. Frontend developers are super happy about the Twig and now, we see all these new modules coming up like BigPipe and RefressLess that now just recently came out. I mean, when I saw that, that’s like mind blown, and I think there will be so many more modules.

jam: I thought that cache tagging was insane. I thought that BigPipe was insane, RefreshLess, I didn’t even know that we could ...

Michael: Yes, and I believe, I honestly believe there will be so many more things coming out that we are surprised in how less code you have to write to implement a specific functionality because you just have to change how it works a bit, and then you have a complete new functionality or people coming out with really cool tools, or modules, or plug ins or whatever it is on how to use existing system. I think we did not reach peak of what you can really do with this system that we’ve built.

jam: I don’t think we’re anywhere near, best practices, or knowing even the potential of what we’ve got.

Michael: Yes. So, how it is right now to work with it? It’s not there like if you pick up Drupal 7 and you just [do it all]. The contrib modules are still not there. Not all of them are there and some of them are failing, but again, I feel that’s a good thing. It’s good that you have to sometimes go out of you comfort zone and it gets better. Now, you have to tackle through. You have to figure out how things work, but in the end, you’re learning on that way. You’re still learning. You’re improving and that’s really important, contribute back. If you realized something is broken and doesn’t work, just don’t fix it for yourself. Tell at least your teammates and also tell the world. Write a blog post, write a patch, or whatever it is. If we all do that, we help each other and make it faster, and we will be there where we are right now with Drupal 7 that all the modules just work together and you have no broken contrib ... We will be there in the next six months.

jam: That fast?

Michael: Yes, I believe so.

jam: And comparing that to previous releases, I find it really interesting that we talk with community people now who actually never saw a major release before and I see some of the things that people are complaining about. I’m like, “You weren’t here when Drupal 6 came out.” And we didn’t have any Views module for eight or nine months because Views 1 wasn't ported and Views 2 wasn’t ready. Every Drupal 5 site worth its salt was built with Views, Panels, CCK, right? And then Drupal 6 kind of just ... nobody could do it ... it felt terrible. Drupal 7 took a year for contrib to really catch up, but Drupal 8 is, right from the beginning, is fully tested. It’s very, very stable and it’s got incredible stuff out of the box. All of the authoring experience, all the multilingual stuff, everything’s entities ... So actually in terms of data structures or whatever, there’s an awful lot there.

More devs, more community, out-of-the-box

Michael: Yes, and one of the things that was really [reassuring] for me that we went the right path. I was sitting in DrupalCon Barcelona at the sprint table and there was a guy working there and sprinting and I was working there. At one point, he asked me a question. Like he came to me and he was like, “Can I ask you a Drupal question because you look like somebody that knows Drupal?” and I was like ...

jam: Wait... See this face? It looks like he knows about Drupal.

Michael:So, now I was asking “Wait, so you came to the sprints?” And I don’t remember the question, but with the question asked, he asked me something completely like about standard Drupal thing and I was asking him like, “Wait. Where are you coming from? Who are you? And he said, “I’m a Symfony developer. I came to the Symfony tracks and there I heard they have a Sprint.” This morning I opened the first time Drupal 8 and he wrote a patch that went into core two days later.

jam: Wow!

Michael: And I was talking about that in the past that we will have the possibility to add new people out of the blue that know PHP and they will be able to contribute and work in Drupal 8 and in front of me, I saw it.

jam: Immediately.

Michael: And I asked him like, “Hey, how does it feel?” Like in terms of how crazy it is because we talked all about this Drupalisms and how Drupal 7 has like this learning curve that actually you will fall down two or three times before you make it, and he said, “Well, it’s a different flavor of PHP.” But all of them are different flavors, but overall, he can read through it. He can read the APIs. He can understand it and that was something that I said, “Wow. That’s going to be so great for us, for the community.” And I cannot wait to see what’s going to come out of that.

jam: And I can say that the PHP where people are really, really curious about us and Campbell Vertesi and I, for example, have been out there trying to convince PHP people, “Please don’t write another custom CMS application for your big project. Just drop Drupal 8 in there. Front end or not, whatever. It’s got so much great content management tools, stuff in it and you can just drop it in and use it, and it really works.” That’s so exciting. It’s so exciting. Hey, man, it’s great. Thank you for stopping by today.

Michael: You’re very welcome.

jam: It’s been really, really good to talk with you.

Michael: Thank you. It was a pleasure.