I just had the time to watch Larry Garfield's DrupalCon Amsterdam core conversation on managing complexity today. I did not have the chance to attend his session live due to other obligations, but it is nonetheless a topic I am very interested in.
The key point of the talk in my understanding is the Drupal community needs to decouple and be component based (evolving around more independent components), so responsibility and authority is distributed and local. Larry specifically calls out that Drupal 8 initiative leads and component maintainers are "glorified secretaries" with responsibility but no explicitly granted authority.
I am not a native speaker and although I had an idea, I wanted to clear up what authority would mean. According to Google the power or right to give orders, make decisions, and enforce obedience. (I'll use hard power as a synonym). Larry alludes to parts of this definition in the talk with examples. While the talk is well worth the hour to get insights form one of the Drupal 8 initiative leads on some of the struggles we had in the Drupal 8 cycle so far, I think there are fundamental issues with the premise. The biggest fallacy is the gross generalisation and picking one facet out of a very multi-faceted situation, so the proposed solutions don't stand deeper scrutiny.
Let's assume that leaving everything else as given, we grant authority (by the above definition) to some selected people in Drupal core. How would they be selected? Probably the same way leads are now, coming up the ranks, showing expertise and availability in a given technical area. It is hard to see that without giving in lots of those 1-hour 1-votes that Larry is concerned about, anyone would grow to be recognised as an authority. What would be other ways?
Let's assume they are there. Now what? Would everyone suddenly agree with their set direction and go and implement them? Why would they? If Dries says Alice and Bob should now have authority in X that does not change the incentives of contributors. Alice and Bob still need to spend all the time architecting solutions, communicating them clearly, rally people around their idea and then being available to gatekeep changes in their area, so to ensure they conform (see enforce obedience). What if contributors don't agree or Bob and Alice are not good communicators to get the word out? If Dries gave them authority, how does that give them the power to give orders? Where are the people waiting to implement Alice and Bob's great ideas? The only way the model proposed by Larry would work in this case is if the component in question is so small that Alice and Bob themselves can move it forward (or if they have or at least also control money to hire people to work on it, despite disagreements with contributors).
So the authority solution would solve Larry's concerns with those winning who have "time they don't know how to spend better" in two scenarios:
- If the components are (a) so decoupled (b) so small and (c) interface with each other so rarely that you can become an authority without needing to put in so much time ahead and then constantly, to exercise your authority
- Or if there is abundant money to pay both authorities for their time and then implementors to abide the authority even if they disagree
Both scenarios are interesting. I don't think the first will happen in several years (way into the middle of Drupal 9 earliest), and I doubt all three subpoints would apply. I really wish the funding situation will improve, there are so many people working on it, but I am not sure paying people to work on things they are not excited about / agree with is the spirit of open source anymore.
In short, hard power and a volunteer based open source community are not compatible on the long run. You either need to lose the volunteerism or gain soft power which authority does not help you with.
And initiatives in Drupal 8 were especially set up to be "soft power centers". Larry says initiative leads are merely "glorified secretaries" which I think is a very unfortunate misunderstanding from an initiative lead. The official definition of initiative leads says they coordinate work on the initiative and communicate the plans, progress, and needs of the initiative to the community and the branch maintainers. While this does not give them authority, as shown above giving authority in itself would not have helped.
Initiatives are the first try to set up bigger areas of work with appointed leaders. By highlighting these topics, end users know some of the major improvements to expect and contributors know where to contribute effectively. An initiative is a self organised unit with meetings, possibly its own website, issue tags, sprints, blog posts, sessions, etc. If a contributor cannot figure out how to get involved that is then a problem with the initiative.
So my understanding of initiative leadership was that I have responsibility to show the community there is a (1) shared goal, that (2) it is an achievable goal, and then (3) help people get there. There are a myriad of ways an initiative lead can do these, I did at least the following in the multilingual initiative:
- I set up a website to promote the goals and progress of the initiative and a twitter account to follow progress
- I held "Multilingual therapy" BoFs at DrupalCons to gather common problems from real scenarios to inform our decisions
- I worked with people experienced in user testing to help us develop a user testing script for key actions and coordinated several user tests; circled back results to improvements
- I distributed power in my initiative to three key areas relying on topic experts Erik Stielstra (Sutharsan), Francesco Placella (plach) and Jose Reyero (in alphabetical order)
- I made a point of not being attached to specific architectures so that I can scale myself (but it also turned out to be great to stay sane)
- I figured out a tagging system for the three areas and adopted one for the current focus issues (thanks Jacine Luisi for the idea)
- I built a custom visualisation tool to help communicate our goals / progress after trying mindmaps and other tools that failed
- I grabbed new people coming to sprints; the most famous example is Cathy Theys (YesCT) at DrupalCon Denver who is a fabulous team player and mentor
- I made an effort to try to make people on my team successful by finding reviewers, pairing people up, etc.
- I organised sprints to get the team together, Denver being the first "extended DrupalCon sprint" but only for multilingual; it grew into a generic extended sprint and transformed some events such as Drupal Dev Days
- I did my best to find funding for these sprints so at least we had a good venue and if possible people got fed
- I wrote a blog post series to communicate changes and point out missing pieces and lingering flaws at the same time, which helped drive some contribution.
- I made effort to find replacement for people when they left (for a while), including myself
- I held a fast paced talk of all the changes and the new multilingual structure in Drupal 8 at DrupalCons and Camps to inform people and recruit new contributors
- I developed a two hour lab with Aimee Degnan and Kristen Pol of Hook42 for DrupalCon Amsterdam which we "open sourced" (slides, handout, demo script, Drupal 8 distribution) to be presented around the world
- I wanted to acknowledge all issue contributors, not just patch contributors, so I created a page to credit all of them (above 1100 people) and bring them to life with photos from events
- I organize weekly IRC meetings (more inclusive for foreign language folks than video meetings) to discuss progress, find people to help each other with issues
- I developed a bad case of RSI two weeks before DrupalCon Amsterdam and was in pain; at the sprints therefore I focused on bringing food/coffee to discussions and clearing out tables of trash instead of typing, so I can help people not spill soda on their laptops
- I read a lot of literature on leadership and suggested my favourite find in practically all related conversations: Switch - how to make change when change is hard (protip: the whole book is about getting your way in things you don't have authority about, which is most things in life)
- I called core maintainer attention to important issues and helped explain decisions when needed (more on this below)
All of these one by one helped immensely to make great progress on the initiative. All of them required time to implement, some more significant than others. None of them would have come any easier if I was given authority. Not a single one of them. (Unless authority comes with a sizeable budget that I can direct so others do these). And all of these are well within the definition of the initiative lead published as coordinate work on the initiative and communicate the plans, progress, and needs of the initiative to the community and the branch maintainers. As for whether initiative leads like myself are glorified secretaries then I leave to the reader to decide.
But what about power then? Are initiative leads powerless people with way more responsibility then they should have? As a matter of fact leaders have unparalleled access to core committers. Leads had a 2 hour phone meeting with Dries every other week and Dries asked leads to attend separate issue review phone calls for high stakes issues. Core committers in general were eager to discuss pressing issues on IRC with leads. Longer sprint events made a point to have core committers sit in person on prescheduled meetings for several days with initiative leads discussing important topics (special thanks to xjm for organizing these!). That is a level of access that is far above what anybody else in the community could attain. (This in itself did not guarantee an initiative lead supported solution would get committed, and I had a major counter-example as well). So while saying an initiative lead has no formally documented power may be true, that it does not actually have power is way too far from the truth.
Several people said the multilingual initiative, that is my experience is a special flower and the same tools or processes would not apply to other topics in Drupal (or even Open Source in general). Let's return to my understanding of initiative leadership that one needs to show the community there is a (1) shared goal, that (2) it is an achievable goal, and then (3) help people get there. I don't think it can be said for any of the initiatives that a huge number of people would not share the goal (even if they disagree on some steps). In my view if a lead looks to defining that shared goal and help drive people there, then they can use all these tools effectively and get to good results regardless of whether they are (also) granted authority or not. Authority is not what gets you there, appreciating leadership to its fullest (not as being a secretary) does.
catch's point of view
@catch posted amazing feedback on the talk at https://amsterdam2014.drupal.org/comment/1773#comment-1773 as well, suggested reading! Choice quote:
Larger Topic
I'm afraid a lot of people have cherry-picked the argument they want to have here. I keep trying to illustrate that the topic is much larger than Larry's specific suggested solution. Larry didn't really push that particular solution, he just said it was one he thought would work. For the sake of argument, let's consider the lion-share of your blog post as sound debunking of Larry's specific solution, this does not negate the problem space which is that large changes, even one that existing Drupal leadership want to see implemented, are extraordinarily difficult to make happen when even a small number of people don't approve of those changes. I submit to you that what I want (and I think Larry would second it) isn't authority in and of myself, but rather the authority of a roadmap. In certain cases, it will have to go beyond a roadmap and down to architecture document levels as well. Sometimes you DO have to be married to an architecture, or at least certain elements of an architecture.
In short, my own feelings on this are very simple:
One could argue that the points you made above are your own version of exactly what I'm asking for, however D8MI was a special flower to a certain degree because you didn't have to be married to a particular architecture, and there was already broad agreement that your goals were desirable. Other initiatives did not have those benefits. Speaking personally, I'll be the first to say you were/are ridiculously more organized than myself, but I was (and still am) married to a particular architecture, and that introduces a lot of complications in the process. I hope that distinction makes sense. I'm happy to document it further and better if people are interested, but it's not as black and white as "we want authority". I think the big point I really wanted to make is that I want the authority of an agreed upon roadmap, and if we intend on making new releases every 6 months, I think that'd be wise to seriously consider on our part. Clear goals with a clear roadmap to get there is likely to improve our development cycle dramatically.
I'm afraid a lot of people
It's not just the conclusion we've taken issue with, it's also the premises of the talk - this is the case both for Gábor's blog post and my comments on https://amsterdam2014.drupal.org/session/managing-complexity.
I certainly have many more criticisms of the talk than I've written down so far, but that's for lack of time/energy to write many many hundreds/thousands more words on the subject - especially given the lack of substantive response to the feedback already given. Also Larry has been talking about wanting more formal, explicit authority in Drupal core for years, it wasn't an off-the-cuff suggestion.
I posted similar in the comments on the talk, but I'll repeat it here. I think it's reasonable to have a list of "things we'd really like to see in 8.x minor releases/9.0.0", however the 6 month cycle means we have to be absolutely prepared to put out minor releases without any of them being done. Personally, I'd also like to see a short 9.x development cycle (say 9 months) if possible, that concentrates on removing bc layers and dealing with the very worst/oldest technical debt that we can't resolve without bc breaks (everything else can continue in minor releases). Not sure everyone agrees with me though on that.
A formal roadmap in the sense of "this is what we're going to do" is very different from "here's a list of things it'd be great if people worked on" though.
As 8.x branch maintainer/release manager (a sentence opener I try not to write usually), I have some actual, real authority to say "no" to patches or wider sets of issues - because I can refuse to commit them, or even roll back issues after they go in. This only breaks down if that comes into conflict with another committer, and then we discuss it, and regardless of the decision try to come up with something everyone can live with. Or if someone convinces me the change is fine, which also happens.
However there is not nearly the same scope to 'pre-bless' sets of issues - because people still have to actually do the work of coding them and doing the reviews. Even for patches I write myself (not as much as I'd like recently but it does happen), they still need to be reviewed by someone else, then committed by another committer.
This comes back to the main point of this blog post that if people agree something is a great idea, you don't have to enforce it with 'hard power'. If people disagree, the only way you can get people to do it is by paying them money (because people need money to live, so they have to work doing something). Then you're paying people money to work on something that they, and potentially many others, disagree with, on an open source project which still very much relies on a heterogenous and not-directly-funded contributor base. The fact that it's hard to do just chuck a bunch of money at an issue and get changes into core against the wishes of other contributors is a feature for me, not a bug.
movement vs. doing it oneself
Ok what were the goals of your initiative? According to http://buytaert.net/layouts-for-drupal-8 those are Contextual blocks, Blocks everywhere, Multiple page layouts, Partial page rendering and Better UI/UX to manage blocks. There is definitely a huge number of people interested in these areas. There are a multitude of modules and themes covering these areas from Bean, Spaces, Context, Display Suite, Panels, even Views, OG, Omega, Better blocks, Blockify and even to some degree Rules. And then I probably forget lots of others. So that there is not a substantial group of people sharing those goals would be false to say. So as an initiative lead I think you had a huge pool of experience/talent to draw from.
It is true that many of these things are not complementary but competing with different architectures. Given you came from one of the approaches, it is understandable that you would be married to that one. So long as you don't have a team to work with though agreeing to that architecture, I don't think you are leading an initiative anymore? Who do you bounce ideas off of? Who are the people working on blocks issues when you are not available? In my mind an initiative can only be a movement if there is a group of people understanding the same goals and figuring out the architecture together. Its not a problem if the group of people arrive and agree on your favourite architecture but I think its a problem if there is no group of people.
As a comparison there are some competing solutions in multilingual (eg. node translation and entity translation) in Drupal 7 and we did have extensive pro/con discussions at the start before we were convinced which way to go. I was far from convinced that the entity/field translation solution that actually got implemented in Drupal 8 at the end was going to be good. Which is understandable because we designed the original node relation translation system with Jose Reyero with input from chx in chx's Budapest apartment in February 2007 (photo from dinner). So it took me a bit to turn around. See my comments on https://groups.drupal.org/node/165194 for example, particularly: Yes, we've been discussing attaching fields to translation sets instead of their entity members and sharing fields that way. I was a historic proponent of that model.
Sometimes you DO have to be
I think the current architecture we should aim at is: First Composer, then PSR-0 / PSR-4, then DIC, then decoupled core components, then Symfony and everything else.
At the beginning of Drupal 8 or WSCCI, I totally did not see these being the goals. Tbh I found the initial wscci goals confusing. We only got to where we are now because different people joined in with their ideas, and an overall community learning process. (this is my personal observation, I might lack some parts of the picture)
Whichever roadmap we might have come up with at the beginning, probably would look quite different today.
On the other hand, a written and possibly version-controlled roadmap would make these changes visible. So it could still be a good idea.
One thing I enjoyed when doing patches for Composer (instead of Drupal) was that once I have approval from Jordi or Igor, I can be quite confident that I am not wasting my time on something that will never get implemented.
On the other hand, in a Drupal context it can happen that the answer you get is "I agree, but who am I".
The benefit of authority is that there are fewer people you need to convince, to get something done. And if you get a NO, you can stop wasting your time. Either walk over to another project, start your own, or just live with your idea being buried.
The thing I did not enjoy so much with Composer was the fact that Jordi does not scale. There is a big refactoring attempt that is still lying there. Cannot blame him - I don't scale either. Similar situation with a lot of contrib. And it will happen in core, if those with the "authority" become unavailable.
I would claim that everyone has been this person with too much time at some point. "Someone is wrong on the internet" is the driving force of Open Source. Turning down people with too much time can be a suicidal move.
Above all else
Is security. Security trumps every other consideration including performance, developer experience et al. In particular, we have rolled back already some loosely coupled parts because of security considerations.
soft power vs. hard power
Great post Gábor, thank you.
What I read between the lines here, was a key insight about leadership.
Simply putting someone "in charge" if people don't want to follow them, won't
make them a leader.
Soft and hard power is a useful way to look at this issue. Thanks for
sharing your thoughts and experience.
Donna
Excellent post!
This is an excellent post. Authority is sometimes also defined as influence. And you gain influence in an OSS model if you can convince others that you have a good idea.
The twig initiative was also a special flower, but very different from i18n. The most obvious it being never any official initiative.
When I first joined, there was already a huge community movement, but no one to take the initial idea over the finish line and actually implement it. In that way the community empowered me to implement it, which was a HUGE motivation.
Back then it was just Jen Lampton and Morten DK with chx mentoring on technical issues.
But since then the team has grown substantially with varying leads. When Jen Lampton left to pursue other ventures, the team self-organized itself and continued the weekly hang-outs.
At DrupalCon portland we empowered the theming community by teaching them performance profiling to land twig finally completely. I wrote xhprof-kit to help make that task as simple as possible, other wrote documentation, even others made the usage simpler.
When I was busy with other things, the initiative continued - this is the BIG advantage of having a team. And basing its power on empowerment by what the theming community in general wants and on wanting to see this get implemented.
In parts the roadmap I and Jen originally had envisioned was implemented, in other parts it wasn't. In some parts in more awesome and clever ways I had ever imagined. And that is okay for me. There are many ways to solve a problem and while I like my ideas (who doesn't?), if I see a better solution, I will gladly switch and abandon my idea.
For me OSS development is about Freedom and not Restriction. It is also about good solutions and better solutions.
- There is a software - I like it, I use it.
- I find a bug. I fix it for myself.
- I share it online for others to not having to do the same.
- Someone improves on my patch (good)
- Or tells me there is a better solution (uhhhh)
- Which I can then use (yeah!)
If I not want to to apply my patch again and again I might be motivated to put some time in to work with the maintainer of the software to accept my fix - or I might just continue to patch the software for myself.
For me - regardless of how complex the software has become - this is still the spirit of Open Source Software:
It is based on Intrinsic Motivation in its core:
* I do things for myself, because I have a use case for them.
* I want to make something better.
* I want a certain feature
In DrupalCon Austin the Drupal theming community came up with the Consensus Banana on how to do theming.
They made a writeup and thats the written roadmap: This is what we want to do.
Then others started to implement it and we could point back people to that roadmap.
But this roadmap is not based on one lone architect - as genius as it might be - but on a community consensus of a general direction.
Which is exactly what Gabor pointed out.
I might disagree with things - which is okay, but I know it is the wish of the larger theming community (at least those that participated of course). And I still might put in ideas for how to make it better or different or whatever and the roadmap could be changed if others agree.
The problems begin in my experience - when you start doing things with 'pressure' and against real or fictional 'resistance' instead of motivation and 'love what you do'. And usually the main factor there is often "fear". Fear of not getting your way, of others that destroy "your" queue, Fear of Dries not accepting, not committing (he might have a good reason), Fear of someone finding a better way, fear of my roadmap not being followed, fear of someone completely re-writing all my hard work, etc.
The response then is: I need more power!!! I need control! I need to be in charge! Others just have to accept the way I want it.
And being given that power would indeed diminish the fear and remove the resistance. But it would also lead to having to exercise that power to keep feeling in control.
And that in the end might not lead to the best solution, but to a solution that is implemented just because I want it. It might also be the best solution in the end.
But the assumption implied here often is:
* Leaders need to take decisions sometimes that are making huge changes and because most people naturally resist change, I need to exercise control to get that change done.
But that is not empowerment and not open source - in my opinion.
This is "dispowerment" to the people, because it implies that they won't understand why that change is needed and good.
And that is part of why Drupal's overall leadership is so great:
- Every change is not only documented, but also announced very carefully and talked out with the community.
- Drupal listens very hard.
To empower them would mean to talk with them and show them all the benefits and possibilities they then have.
e.g. I just love the DI concept - even if I like another implementation better. I had a hard way getting to the point where I found out why I need "all these services".
Dries said that Drupal is not for hobbyists anymore.
And I disagree with him. Drupal is more simple than ever before - just not for those people that are used to the old ways.
But the same hobbyist that 5-6 years ago learned the hard ways of how to do things in Drupal (learning curve anyone?), will as a new hobbyist starting now surely be able to learn some OOP concepts, write a nice DI service and get whatever motivates them done.
People are smart and will do whatever motivates them.
And if I can sell the benefits of whatever roadmap I have and people whole-heartedly want it, then the initiative will be a huge success.
If I try to push it through against a huge resistance, I might be successful, but just need to keep on fighting more and more and more.
And if I want a roadmap done, but no one is motivated by that, then it might not work out or work out later - when people feel what they are missing.
There are many unofficial initiatives in core and most of them have been mostly operating 'under-the-radar': Performance, Security, CSS, Markup, Field, converting all to OOP, etc.
Some have a roadmap, some don't, but all that get things done are based that there are people that are motivated.
Some have leaders, some don't.
As a long conclusion of this, this are my own key conclusions:
- A leader in open source is someone whose ideas motivate people and who trust him and follow his lead and that empower him. That for me is true authority.
- The concepts and visions are the important key elements, not the actual implementation.
- OSS is most often based on motivation.
- Disempowering others, leads often to felt 'resistance' and the need to fight them
- Empowering others usually empowers me
- People are actually really smart
- Roadmaps are great, but even better are sea maps and a compass - you know the general direction and goals, but not how to get there and how many storms and waters await you and what other turns you take.
This was a very inspiring discussion on twitter, IRC, blogs and @heyrockers talk (that I have yet to look at the slides).
Thanks all!
Hobbyists
Great post, Gabor. FabienX wrote: "Dries said that Drupal is not for hobbyists anymore". I never said that, actually. Quite the contrary; I said we need hobbyists/volunteers to keep innovating. We just can't expect hobbyists to do some of the heavy lifting.
Re: Hobbyists
Hi Dries,
I am sorry that I mis-quoted this and instead wrote my own interpretation of it (I had that mixed up). Thanks for correcting.
The original quote (and I hope this one is correct) I meant, was:
"We're not losing hobbyists. We're asking hobbyists to do very difficult things."
My own interpretation and those of others I have spoken with at DrupalCon Amsterdam has been that this means: "Drupal is too difficult for hobbyists."
It might be wise to clarify the role of hobbyists compared to the "enterprise" / commercial space again some more.
Thanks for clarifying here though, my new understanding of the quote and what you wrote above is:
Just with hobbyists it is not possible to get Drupal (8) "done". We need help/support from those using Drupal professionally (and so far not contributing).