Keeping on, keeping on schedule and with one microphone per person.
Gabarhojji, very old friend of mine and open source original.
Drupal Core maintainer several times.
And now talking about a really powerful contribution project in the Drupal community.
Roughly right?
Thank you, Jim. Yeah. Great. Hi everybody.
Thanks for coming. I think it's going to be interesting for everyone hopefully in some degree.
Because this is about open source leadership at scale.
As Jim said, I'm Gabarhojji.
And...
They called it one slide, Gabarhojji.
No, it's done. So I'm Gabarhojji.
My own made up title is Full Stack Community Organizer.
Which means that I can put on an event for you.
I can manage social media, design graphics, do a keynote,
build developer tools and like basically everything in between.
Write marketing copy and do everything in between.
So whatever is needed at the time.
So I've also been working with Drupal since 2003.
Much like Mathias with Type or 3 since 2003.
Just picked a different system.
But it's around the same time and I'm a Drupal core committer and did a bunch of stuff that are...
That helped in getting here where I am now.
But I'm more interested right now in where you are coming from.
Who's using Drupal for anything in the room?
Alright, some of you who have no idea what Drupal is.
Just here for the title because it was nice.
Okay, I didn't explain Drupal that much. That's great.
Who are you consider yourself primarily developers?
Okay, great.
Nice. So those were the main questions that I wanted to have so I can direct the talk properly for the audience.
So I got into open source from open content.
In the 1990s I went to high school.
And the high school got dial-in modems and we got on the internet.
And I was really interested in how we can publish stuff on the internet.
How we can put something on the internet.
And I decided to be the lazy teacher that reads five pages ahead and then teaches everybody else what they learned.
So I started looking at how is this done and started to go into documentation and started to translate the W3C standards into Hungarian.
And then the PHP documentation into Hungarian.
And then distributing that and then starting to look for news and articles and translate those.
Summarize and translate those into Hungarian and publish it for the Hungarian community.
And so it basically turned out to be a thing where I needed to set up a website to publish all of these things.
And I got together with a person in Vienna, Shandor Shromkuti, who I've never met ever in my life, ever since.
Now we work together very well online.
And we created this website called Vabla Bor that was hosting these things.
And I went on a side quest with the PHP community.
I became the lead of the PHP documentation and the lead of the PHP.net website in the beginning of the 2000s.
And growing this Hungarian community website as well.
But the Hungarian website grew out so much that we needed some kind of system to manage the community, to publish these things,
manage the forums that we've had and the meetups that we had.
And so we needed to have some system that managed this.
And that's where I found Drupal.
And Drupal was tiny and nice.
And this was the whole Drupal conference in 2005, all the attendees.
There's a certain person sitting there.
So it was a tiny community that was very tight-knit.
And we would get together.
The software was managed through a mailing list where you would post a patch to the mailing list.
And it was reviewed on the mailing list and then committed to CVS.
So it was very tight-knit and everything was reviewed by these few people.
And so it was very easy to join.
And I needed it for a Hungarian website.
So my main problems that I would go in and fix were usually about translatability into Hungarian.
Or I wanted to have the path aliases in Hungarian.
I wanted to have everything in Hungarian.
And I always bumped into bugs and I submitted bugs and they got fixed.
So I fixed them, then they got committed.
So that was basically the natural way to get into the community.
Small was easy to approach and they would receive those fixes very well.
Fast forward, ten years later, this was the Drupal conference ten years later,
there's people up there as well.
They're hard to notice.
So this is Drupal condomber.
So it's kind of hard to get started in this community.
Like who do you walk up to that I have this bug and please work with me on fixing this bug?
It doesn't work.
Like there's no way to do that.
Like, I don't know, it's hard.
It's like walking up to people on the street and like trying to convince them of something.
When I got in here, all of the buses, I think bus 71 was always full.
Like I waited for two or three buses.
All of them were full.
I decided to call an Uber yesterday.
And I was myself in the Uber.
So I walked up to the people waiting for the bus.
Like, how do you want to come with me?
And they were like, no.
Who are you?
Like that's the kind of feeling that you walk up to someone and like, no, who are you?
Like, why are you approaching me?
So I was alone in the Uber.
But when you have this tight small community, it's much easier to work with them.
So when we got to this point, it started to get very hard to manage what people are working on
and organize that and motivate that.
We kind of went by pretty long without more structural organization.
But around this time, the project lead, Drew Spreiter, decided to set up initiatives.
And so that initiatives could get back to this tight knit small feeling
and they could sit together and know each other and have a sense of community
in this much smaller scale.
And they could work together very well.
And when this started, I was approached to work on the multilingual initiative
because even 10 years after I joined, the multilingual was still a problem space
that had a lot of problems to be solved.
And so I was happy to accept that.
And so I started working on the multilingual initiative.
And everything was rosy and happy and I started working on things.
And then a bit later, something bad happened for me.
And the least I considered that was super bad that happened is that another initiative was announced.
The views in core initiative was announced.
And so multilingual was especially in Europe pretty important.
But views in Drupal is basically the, so if you don't know Drupal, that in that detail,
then views is basically a query builder based on Drupal's very rich structured data.
And it's also an output generator based on the query.
And you can choose how the output is generated.
And it can generate APIs and REST endpoints and lists and sliders and all kinds of things.
So basically it's a query builder and an output generator.
And views was four times more popular than any of the multilingual modules.
And they got funding from Sony and other companies.
So they had money.
They were four times more popular.
And they started to steal some of the people that were working on the multilingual initiative.
So I felt totally betrayed and I was super angry.
And I wrote this email to project leadership and core committers that this will jeopardize my initiative.
It will make my work super hard to do because they're going to steal the thunder
and will be very hard to do this going forward.
And now I'm here talking about how successful it was.
So we sort of resolved this.
But I was super angry and very jealous and also felt betrayed.
And I think what was interesting is I didn't get responses to my feelings there.
I did get responses to the facts that I stated and they were refuted.
But my feelings were not contested.
And I think what I realized after a while, after I had time to think about this,
is the problem that I had is I was thinking of Drupal as this small pie that we are eating from.
And if everybody's eating from the same pie, then it's kind of be over after a while
and you don't really have more to eat.
So if you steal my people, then I don't have people and I'm not going to have people.
And so I think that was the key understanding that I had is that I need to think about how to grow this pie.
And even though we had all of those thousands of people at the conference,
I think we still didn't have a good grasp on how we involved new contributors very well
and how we make them successful, which was even more important.
And my other problem that I had is I didn't have money.
And this realization that I need to grow the pie didn't make me have more money.
Some of the companies that were involved in the Multilingual Initiative had money
and they were investing into sponsoring some of their people.
But I didn't have money on the scale of 1,300 people.
Like, that was not possible to achieve.
So I need to figure out something else.
And so what I started to look at is how to make people happy.
Because they would come here if there's something in it for them.
They would join us if there's something in it for them.
And I did, I read a bunch of stuff and some of this clicked together afterwards
and it provides a great structure for this talk.
But some of this, I basically figured out on the go.
And so I think the best structure for this talk is these three words.
This is from Dan Pink's book called Drive,
which is one of the three books that I suggest you read on this topic.
So Dan Pink Drive.
And he highlights that people like working on things when they have autonomy.
So they decide for themselves.
They decide how they solve problems, who they solve problems with,
how they move forward, etc.
People strive if they have mastery so they can get better at things.
They improve.
They can try new things and improve in them and get challenged.
And they strive when there's a purpose of what they are working on.
And so if we can figure out, if we can correct the code on those three things,
then it works really well.
And I think we correct the code in the multilingual initiative and this is how we did it.
So I think the purpose is sort of easy,
at least for the people that were involved in my initiative.
They were primarily in Europe but also somewhat in Canada and somewhat in Northern US.
And they had personal needs for multilingual.
So obviously they had the purpose of solving their own problems.
But there was also some higher purpose, like if you just look at where Drupal is used,
the UNESCO uses multilingual Drupal to help with education and children and refugees and stuff like that.
The CERN uses multilingual Drupal to advance science.
Tesla is using multilingual Drupal to promote their technology.
And you can like configure your car through Drupal on the Tesla.com website.
Rathetti is using Drupal extensively and they invest money back in open source as well.
While we are in Brussels, it's hard to avoid the European Commission.
It's using Drupal super extensively.
This is in Hungarian, aropa.eu.
But they have 300 websites that are in Drupal.
Most of them are multilingual obviously in Europe.
It's hard to do anything without.
And they have more than 100 people on staff, developers on staff that are working on their Drupal websites.
So it's super extensive.
But I mean these companies can pay their way to solve their problems.
If you have 100 developers, even if multilingual is hard, you can solve that.
If you're a Tesla, multilingual is hard, you can solve that.
So that's not really what gave me purpose.
What gave me purpose is my high school's website where I started working on open content is running on Drupal.
Totally accidentally as I was not involved.
Totally randomly.
So this is the high school I went to.
So it can make a Hungarian Drupal website that's fully Hungarian and works very nicely.
It's not multilingual, but it's Hungarian.
So that gives me purpose.
If we can make it work in a way that the little websites can do it very easy that we succeeded.
So that was my purpose in here.
The autonomy part, I think, is much harder to solve if you come from a traditional open source developer background.
Because I think many people that start open source projects, they're great developers.
They have this idea of what they want to do.
They have this architecture in mind that they know how to get there and the steps to get there and they are building it.
And they want to have people along for the ride, but they don't want to have people to tell what the architecture should be and what the steps should be to implement, et cetera.
So to give autonomy, you need to agree or understand that you need to agree on the high level goals and get rid of your idea of micromanaging anything below that.
So you need to be comfortable with the idea that you define these high level goals and it's up to the team to figure out the rest.
And maybe it's not the same architecture that you wanted.
Maybe it's not going to be exactly on the timeline that you expected or the steps that you expected, but other people will implement it.
If you share the same goal, there's going to be shared ownership and they will implement it.
So I think this is hard for...
So this is one of the things that's been...
I've been trying to mentor initiative leads on in the Drupal community ever since because it's very hard to get from a developer background and have an idea of how this should be done.
And then give up that idea and work on organizing the whole thing instead of implementing the whole thing.
But to achieve some scale, you need to give that up.
The next one is, especially in the Drupal community, is to set up space because when you have this big thousands of people at the conference, there is no identity, there's no space, there's no feeling of community for the team that you have unless you set up the space.
So for example, what we did here is we have a chat room.
This used to be IRC now, it sounds like, that is shared in the team.
We use chat meetings and threads so that it's easy to get involved with multiple language backgrounds.
It's much harder to follow live audio meetings and video meetings when it's not your native language and it's very fast.
Chat meetings much easier to follow.
We had this identity that was created by one of the sponsor companies, because the logo of the multilingual initiative, we had stickers of this, we had t-shirts of this, etc.
When we went to events, we had tables where we set up a big sign that this is the multilingual initiative so people came in, they would recognize us, they would join us.
We were always there in the morning, by the way, that's a good trick, so that we were the default choice at the contribution room.
When people came in in the morning, they were like, oh, multilingual initiative, great.
So that allowed us to have this sense of small community that we need to achieve in this big community, to have a sense of belonging and to have a sense of connection,
and so that people stay and will have those personal connections that otherwise are not possible in this big community.
We also had our own website, which you may or may not need, but it was nice to have our goals set out there, and we basically pulled issues from the IssueQ and used tagging and labeling on issues to prioritize them and then display them nicely,
so we didn't need to do a bunch of work manually on the website itself.
Now then you have people, I think the next important thing is to have buddies, set up buddies for things.
At least in the Drupal community, there's always at least three people that you need for an issue to be committed.
There's somebody that works on the fix, there's somebody that reviews the fix, and then somebody that commits the fix.
So if you need three people to work on an issue, you need to set up those three people to be successful, like, that's not going to accidentally happen.
Like, if you walk into this keynote room, I have an issue, there's nobody going to listen to you.
So what we did is when new people came in and they were like, I want to help, we always assigned them to something that somebody else was already working on,
because then they had a buddy that was already invested in the issue that they came in to help with, so there was already shared understanding between those two people that they want to solve this problem.
And once we had that, we had these buddies that if one of them went away, we still had a solution for how do we move this along.
There was still one person left that could serve as a successor to the person that used to introduce the problem to the next person.
So it was pretty useful to keep things going because stuff happens to people.
Like, all the main people that I had in the initiative, something happened to them, and it was always useful to have buddies that shared the same goals.
And that was basically the only way to get stuff done in the Drupal community anyway.
So I think that was pretty much a key to our success.
And the next thing that I realized is we need to praise the smallest of results,
because people don't really recognize that they are going towards a goal and they are achieving something towards the goal unless you point that out.
And often people forget about, like, after a week or so that they did something great, so it's great to get back to that.
And in the meetings, we always had a section where we were praising the results from the previous meeting and figuring out who did those things and call them out as well.
And the other thing that's super important, I think, is to praise the people that go away, because when they go away, they probably already burnt out two or three months before they just didn't realize it.
And it's good that they went away. It's good for them because they need the break.
And it's good for you because they're not going to be here and, like, maybe have negative effects on the team.
And it's good for you because if you are praising that they need this break now, it shows the team that they don't need to overwork here and they don't need to kill themselves through this project.
We'll figure this out. And the person that you celebrated for taking the break may actually come back after they took the break if you've been kind through this process.
So it's like there's no other option, I think, that's like the win-win-win-win-win to praise people that go away because it's the best for everybody.
So if you do these things, you have those buddies, you have a small tight-knit community, even in the bigger community.
You have this space. You give them autonomy to work on their own ways. You just share the high-level goals.
And then you have this shared ownership about things. And maybe it's not going to be implemented in a way, maybe it's not going to be implemented by the same people you started with or on the timeline you wanted, but it's going to have shared ownership.
And that was kind of useful for me when I had a problem. So a couple of years into this initiative, it was a long initiative.
I had breakfast with my wife and she started to having very strong stomach pain that didn't end. And so we stopped our breakfast there and we went to the emergency room.
And they figured out that her blood results are getting worse and worse, but there was no blood to be seen anywhere.
So they figured out that it's internal bleeding and she was about to die in a couple hours if not operated immediately.
And so they assembled a team of doctors that would operate her that night and they saved her life.
But she lost one ovary on the way. But she now lives on and we still remember this day.
And at the same time, Drupal Karnasdin was happening. I was supposed to be there and do all of this magic with the multilingual initiative.
And I was obviously not going to travel to Drupal Karnasdin when my wife was recovering from a life-saving operation.
So because we had this shared ownership and shared understanding of the initiative, all the stuff that we were planning for the multilingual initiative happened in Austin.
They sent us flowers and guards and well wishes and they sent us this photo of some of the people on the Contribution Day to wish us well.
But this was because we built this initiative to do it together.
And so mastery is the final one, I think, which is probably the most interesting thing, I think.
Because people want to get better and you want to have people on your open source project.
And so the question is what is that you want to have people on your open source project and they want to get better at and what do you need that they may want to get better at.
So that's what we are looking for.
So one of the things that I've been doing at events is therapy sessions because multilingual used to be very painful in Drupal and people had pain.
And so I set up a multilingual therapy barf, is what it was called, on the schedule.
And I would sit back and I was like, do you want to talk about it?
And they wanted to talk about it.
And so what this was great for is, A, I got in the users that had pain about multilingual so I could have a requirements list of what I want to solve in the multilingual initiative.
They got to talk about their pain so they felt heard.
The people that were contributing on the initiative came in to the barf and they felt like they are the experts because they could give advice to the people that had the pain.
So I was basically sitting there, I didn't do anything at this barf.
I said, do you want to talk about this?
And the experts came in from the initiative naturally and the people with the pain came in and I just sat there and I enjoyed it.
So that's the investment.
So the experts, basically the people working on the initiative came in and they gave advice to people with the pain.
And we got to show at the barf, this is what we're working on, this is how it's going to make your life easier.
We feel your pain.
Yes, it is something that's hard right now, but this is how we are solving it.
And so we could build in that feedback into what we were working on.
We could review with the people with the pain the solutions that we had.
Does this solve your pain or not?
So it was very good to get direct feedback, it was very good to have them listened,
it was very good to provide visibility to the people that were contributing and get professional recognition for them,
sometimes business because they were giving advice to clients that were showing up in the room and they may get a business relationship after the barf.
So it was great.
So I think it was important to acknowledge that multilingual was a pain and provide this space in person as well.
The next thing we did was radical openness about how we organized this initiative.
So we created an open source slideshow for example that anybody could present anywhere.
And they translated this slideshow into multiple languages presented in Japan and Poland and France and bring it to companies and a lot of places.
So we just gave this slideshow and we didn't ask for anything in return.
And this brought the news of the initiative into far and wide on the globe everywhere that this is happening and made people excited.
And also gave people the opportunity to deliver sessions that have not done it before, they didn't build a slide deck that was compelling or anything.
And this was useful for them as well.
We made the Drupal distribution which had a demo of how this multilingual thing will work.
It had demo content and demo menus and a bunch of features set up so that people can try out how they can do it.
And they can try out how this will work and they can test this out and we can get feedback.
We created a two hour workshop with a 23 page handout that detailed the steps of how you get to build this distribution basically.
How you get to build out a multilingual menu, how you get to build out a multilingual content structure, etc.
Super detailed. That's why it was 23 pages.
It was like click here, right this, click here, right this detail.
So this was very useful for people to do these workshops and teach people how to use the multilingual Drupal system before it was even done.
Like we were already training people on multilingual Drupal before we were done.
And with the help of Acquia we created a user testing script that could be crowdsourced so that people can do user testing at their meetups at their local events
and record them and publish their results and we could aggregate the results and use that to inform how we are doing and where we need to improve the user interface or the flows or how all the things are connected.
And so I've been doing a bunch of research and reading in the meantime and read a bunch of interesting tricks on how to involve more people.
So this is one of them, car wash loyalty.
So that was one interesting story about car wash companies.
They want to have people come back to wash their cars.
And so they did an experiment where they had a car wash loyalty card with eight slots that you could stamp in and then get a free wash at the end.
And they did another card that had ten slots but two were already stamped in.
It's the same eight slots but there was two more that were already stamped in.
How much better did this one work for people? What do you think?
This worked twice as good.
So the ten slots two already stamped in worked twice as good to get people to get to ten stamps than the eight slots, eight empty slots.
They had the same exact number of empty slots.
But this one told you that you are already on your way to achieve your goal.
So it was like you already started.
You had two stamps even though you didn't do any car wash.
It was just two stamps and the first stamp was the third stamp that you got there.
And the people that had this card, they got there faster as well.
Not just twice as many people got there but they got there faster.
So I have to translate this to open source contribution.
So one thing that I did is I wrote blog posts about how Drupal Multilingual is going.
And I broke down the initiative basically I think 18 posts or so.
Like this is what we do for multilingual installation.
This is what we do for interface translation, etc.
And at the end of the post I had a section of by the way this doesn't exactly work well yet.
And these are the issues that you can be involved with.
So people read about what's exciting thing coming up.
They got informed.
And at the end they got rubbed into helping with solving the problems
because they already felt like we are getting this great solution
and they was like it's just almost there.
I just need to help with this one.
That helped a lot.
So at the end we got 1,300 people involved
and that included people from companies like NBC Universal and Pfizer and Carefor
and the University of Waterloo, University of Iowa, Biologist, Genetic Information Management,
McGill University, Johnson & Johnson, Ticketmaster, Google Summer of Code, Google Code and you name it.
So all of those sources had people that were involved.
So this is the list of people.
Too fast.
Wanted to spot yourself?
So there's a lot of people.
And so basically all it took is for me to understand that this is not a fixed pie
that we need to look at how we grow this pie.
We need to figure out what's in it for people to come in here and grow and be involved.
And for me to figure out that I need to give people the autonomy in this project
to figure out how they're going to solve this problem.
So they have a shared ownership of solving this issue,
for them to have ways to get better at things, for them to master their craft,
for them to improve on their own terms,
and for us to have a shared purpose on why are we doing this.
So if you want to read a lot more about all of these things,
these are the three top books that I would suggest in this area.
So David Marquez turned the ship around.
This is great for handing off autonomy.
He's a nuclear reactor, nuclear submarine captain
that was training for one type of submarine for two years
and then got reassigned in one week another type of submarine
that he had no idea how to operate.
And so he can need to figure out how to give autonomy to the crew.
It's a great book.
Danny Alping's drive is about this whole structure of autonomy, mystery, and purpose.
And the switch from the Chip and Don Heath is a lot of great stories
and solutions and tips about how do you make people do things that they probably wanted,
but you need to convince them.
So the car wash story comes from there, but it's all...
There's no software stories in there, by the way, nothing.
But there's a lot of stories about what do people do about glove ordering
in the hospital or kids' cancer treatment or a bunch of other things.
There's a lot of great stories in there that you can apply in one way or another
to open source as well.
So there was my talk.
Any questions?
You've left a speech list.
All right.
When does your book come out?
I don't have one on my own. Thank you.
All right.
Oh, there we go.
Yes.
So the question was that Drupal has this challenge in all kinds of other areas as well.
So I think that is the 10x or 100x to apply to all kinds of other topics.
I think so, yes.
So I think we've seen some of the recent initiatives that people were really driven to implement
that had similar approaches, like the single directory components initiative,
for example, had a very similar approach and a smaller scale.
So I think we could apply a lot of these to other initiatives.
We've been trying to mentor initiative leads on these ideas.
And we've been successful in some of these ways of like how do we involve people from events in initiatives.
That's been a track that we've been really successful on working through.
But there's definitely a lot more that could be applied from here.
Yes.
Yes.
Please submit a proposal to the 5.3 developer next.
All right, please.
I was suggested to submit the proposal for the 5.3 developer days.
When and where is it?
It's the first and second and third of August and it's in Koffrüh in Germany.
It's the first three days of August in Koffrüh in Germany.
It's for the camera.
5.3 developer days.
You.
Yeah, me too, but the listeners as well.
Great.
Yeah, thank you everyone.
Have a nice day.
Thank you.