Formally adopt a management and decision making model

[mkalkbrenner]

I wonder if there's already a plan about how decisions will be taken within the backdrop project in the future.

Is there a defined process or will @quicksketch finally decide everything on his own? Will there be an inner circle of developers who have to vote on issues? Will @quicksketch be a project lead like Linus or Dries? Or will backdrop use a more democratic approach like debian?

[davereid]

I would fully support @quicksketch and/or @jenlampton taking a dictatorship role in this project - it's their project so they should run it how they want. Lack of a strong leader to some has been a negative in the Drupal community. I don't believe either of them would make decisions that don't support the vision of what this project intends to do, even if I may disagree.

[webkenny]

++ @davereid - Discussion and collaboration are key but ultimately there must be a "this is a great suggestion, but here's the direction we're going to go and why" or nothing will get done. Leave it to the project leads to make the final calls and trust they will know their community well enough to make the right choices. To the degree it's been possible, I think some in Drupal have done this well - albeit mostly in the contrib space.

[beeradb]

I'm not involved enough (at all) for my vote to count, but yes, BDFL is the way to go imho.

+1 for Quicksketch Jong Il or Kim Jong Jen

[quicksketch]

Thanks @davereid and @beeradb for the votes of confidence. For the time being, I'll be reviewing and merging pull requests and replying to issues to help set the tone of the project. Additionally, @jenlampton and I are working on broader statements of philosophy, mission, and goals. Backdrop isn't going to be everything for everyone, and until the mission is really understood, it's going to be hard to select leaders who we know will take Backdrop in the direction for which we're hoping.

That said, I strongly believe in hands-on engagement between maintainers and contributors. Management-wise, I'd absolutely love to empower sub-system maintainers to update and manage their respective systems with more authority. That means that a maintainer of Views module would be empowered to enhance and fix bugs directly in the core module without supervision (or perhaps through large-batch branch reviews). The process of reviewing has been killing core development for a long time, by easing that process I hope we can reward and welcome contributors, rather than letting patches age and die, unreviewed in the queue.

[13rac1]

I was just talking with @davidneedham and @mrf about this question, then I found this issue. This QuickSketch's/Jen's project, so BDFL is probably best. https://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life

[jenlampton]

I nominate @quicksketch for BDFL (but thanks for the votes of confidence in me too! :)

I'm also in favor of having many, empowered, sub-system committers who can own and manage their own part of the project. In order to do more things more quickly, we'll need more help. The big thing is to make sure each one of those people understand and agree with the big picture so things stay both manageable and on track.

/me goes back to outlining the big picture so that becomes clearer too

[mikemccaffrey]

Well, if the project is a success, @quicksketch will eventually be corrupted by power and become increasingly egotistical and domineering. However, when that happens, we can just go ahead and fork the project again and call it Backspatter.

[quicksketch]

Well said @mikemccaffrey. :)

[molenick]

Good leadership is integral to the success of any project, but I think decisions need to be make democratically and transparently. I think having the project creators create some goals/vision for the project will be important - this lets contributors know if it's the sort of thing they want to dedicate their time to.

I think Jen and Nate's contributions to Drupal have been huge, and think their initiative in forking Drupal will be huge for the success of Backdrop. That said, I think there should be longterm goals of democratic process, collective decision making and transparency. I believe the project will be most successful if the community makes the best decisions for the project, not the most powerful stakeholder making the best decisions for their interests.

[mkalkbrenner]

I second @flaneur-de-mal

[mikemccaffrey]

I actually agree that there should be some democratic process as well, but let's not put the cart in front of the horse. Why don't we start trying to get the first release out, and see what types of conflicts and disagreements that we have, and then adopt a system of governance to address those specific issues.

That seems like time better spent than enumerating hypothetical problems based on our baggage from other development communities we've been a part of. Make any sense?

[chrisfromredfin]

I would be concerned that trying to adopt something democratic LATER (after, say, a year of dictatorship) isn't going to necessarily fly. However, this could be mitigated, I think, by enumerating a set of core values. If some of those core values include "community-informed decision making" or something of that ilk, THEN later there is some ground to stand on if there's an argument to be made that "well you're not really listening to anyone BUT YOU SAID YOU WOULD."

I think that if Jen and Nate come up with the core values that should drive the project (and I think this IS something they're already working on and already have in their heads to some degree), we can always refer back to that. (I bring all this up because I think clear leadership and decision-making early on WILL be essential to its success.. the project could move too slow because of too much democracy.)

[nedjo]

First off, yeah Backdrop! Very welcome addition to the Drupal circle. Personally, it's the most energizing development I've seen in Drupal for a long time.

Re structure, yes, this is a key question. We could use some analysis here: what is the relationship between Drupal's current direction and its structure? Some related questions have been at least touched on in discussions like Does Acquia exert inappropriate influence on Drupal core?

Yes, there are arguments to be made for the so called "benevolent dictator" model. My own experience in Drupal however has been that this structure often has negatively impacted discussion and debate on the project's direction, and fed what at times has felt like a borderline personality cult. As part of the Backdrop "reset", i'd love to see - and would be happy to contribute to - a fresh approach to project structure.

OSS watch has a useful article on open source governance models. What they call the "meritocratic governance model" could retain key advantages of an explicit and limited governance role while opening the project up to peer and participatory decision making. One well developed and documented example of a meritocratic system is the Apache project management committee (PMC) approach.

And in practice, Backdrop doesn't have a single founder--it has two. I like that, and I also like that it has a female as well as a male founder. In a male-dominated tech field, that starting composition counts for a lot.

For Backdrop, here's what I propose:

• A PMC structure is formally adopted.
• Nate and Jen become the first two PMC members. They can wait before considering adding anyone else.
• Schedule a review of the structure in e.g. six months time.

That could start the project off on a fresh basis without weighing it down with a lot of up-front structural development work.

[sun]

Awesome thoughts, @nedjo. That is the level of quality that made people contribute to Drupal.

I'd like to amend that excellence with another perspective. To do so, I'd like to take a step back.

(Hard) Decisions are only required in the first place, if there are conflicts. The root cause for conflicts is a difference in understanding of the proclaimed goals, vision, and direction of a group of humans (with or without a software project). Without conflicts, there's no need for making hard decisions.

At the same time, a "free flow" model involves group dynamics. Even if the project has a (more or less clear) mission statement, answers to challenging problems will result in more complexity over time, diverging from the originally stated mission. Within this process, conflicts may not actually arise — it's a simple matter of evolution.

Looking at the most successful products, you will notice that a primary factor for success is (1) vision, (2) quality, (3) consistency, and (4) passion. These factors are typically driven and maintained by a stake-holder/product-owner that is very actively involved in all processes. Until 2008, that was even the case for Drupal.

The BDFL model (with limited attention to conflict resolutions) is not going to be a successful strategy, as it fails on all four factors and leaves too much freedom/tolerance for group dynamics that are able to hi-jack the original mission statement in the long run.

In other words, 3 months after removing DBTNG, someone will create a PR to add support for rarely used databases (poor example). The community might agree, the change is merged. There was no conflict at all, but yet, the project progressed in a way that may or may not diverge from its original goals, vision, and mission statement.

Closely related, the difficulty with the Lieutenant and/or working groups model is that they are elevated to own authorities for their fields. In turn, they're able to make changes and (intentional or unintentional) decisions that will introduce inconsistencies with the rest of the product. Over time, individual sub-groups are able to move the project forward into directions that were not intended.

Unless there is a product management that acts as a continuously involved and strong authority, the end result of all efforts will mirror the evolution of Drupal 5 → 6 → 7 → 8.

And most confusingly, without the required level of guidance, no one will be aware of the evolution that happened and how much the group managed to diverge from its original goals in the end (cf. Drupal).

In short, if you're shooting for a successful product in a well-defined market sector, then Product Is King™. All efforts are targeted towards solving the >80% needs of consumers. That means to say "No" very often, very clearly, and very early, before a conflict can even arise in the first place. It also means to have all changes under control, in order to ensure overall consistency of the product, as well as progress and evolution in the intended direction.

This level of dictatorship may sound scary at first sight, but all contributors will appreciate the clear orientation and transparent decision-making, which in turn allows to channel everyone's energy into the desired directions.

(In fact, the strong product manager model pretty much resembles Drupal's model before 2008.)

[13rac1]

The BDFL model (with limited attention to conflict resolutions) is not going to be a successful strategy

Agreed. When I mentioned BDFL, I meant the regular non-democratic version. We've already seen how well democracies can bikeshed an issue to oblivion. I'd like to see where @quicksketch / @jenlampton go without that hindrance. It's well described for node.js: http://nodeguide.com/community.html#ryan-dahl

Ryan is the creator, maintainer and BDFL of node.js. This means any commits that go into node.js are reviewed by him, and he's the only one who directly pushes to the node repository.

There is plenty of room for democratic discussion, but in the end someone should hold the trump card.

[DirectorHaas]

Lots of great ideas, mainly agree with @davereid "I would fully support @quicksketch and/or @jenlampton taking a dictatorship role in this project" and excellent observations by @sun.

Perhaps what an open source project needs is a jester(s) to tell the king the truth when nobody else can? from: http://en.wikipedia.org/wiki/Jester "Jesters could also give bad news to the King that no one else would dare deliver." Not that I'm saying I want that role, :) but I'm wondering how that could have changed Drupal dev over the years? Perhaps it could have helped.

That said, listening to customers, end users, site owners, site builders as well as developers cannot but help either. Having a main backdrop.org site where end users can feel invested and heard would probably do wonders for any project, open source or otherwise. Even just a form on backdrop.org w/ "complaint dept" to give people a place to rant could go a long way to find what is working and what is not. Stating the obvious but in the end, all sorts of people, not just devs must use software. It seems that the idea of Backdrop is going to address some of these issues and aim for better communication.

And in a related note, agree w/ @sun "Product Is King™. All efforts are targeted towards solving the >80% needs of consumers. That means to say "No" very often, very clearly, and very early"

[ericfg]

just a quick +1 for nedjo and sun's comments. Nice to see this level of discussion happening about this critical issue.

[nedjo]

While coming out of Drupal a "benevolent dictatorship" model may seem natural, there is a decision to make here. And in our case there's more than a passing possibility that the Drupal structure is directly tied to the reasons Backdrop is needed in the first place (more on that below).

As a contrasting example to Drupal's "benevolent dictatorship", our best model for understanding how "meritocracy" style governance works is probably Joomla. See about the Joomla project.

I'd like to engage with the Joomla leadership and see what insights they can offer here. For example:

• How are differences of direction worked through and resolved?
• What advantages and weaknesses do they see in their decision making structure?

I'm particularly intrigued by how their leasership team includes community leaders alongside development leaders and also by the role of the Open Source Matters foundation.

Anyone else interested in this conversation?

---

And some further thoughts on where I'm coming from and why this question seems to me crucial to Backdrop's success.

More than 8 years ago I proposed restructuring decision making in Drupal.

In responding to my post, Charlie Lowe noted of Drupal that:

a computer science student, without strong commercial interests/projects, is the leader of the project. That's sort of a best scenario for a situtation where contributers all have competing interests.

But of course that situation could and did change. When it did, how open was the community to looking at implications for the direction of the project?

Three years later, when Acquia received its first round of venture capital financing, Dublin Drupaller suggested that the commercial demands of Acquia could come to influence the overall direction of Drupal, given the centralization of power in the project founder (final arbiter of all code decisions, designator of all Drupal core development teams, founder/owner of the keystone Drupal enterprise, de facto permanent president of the Drupal Association, and so on).

If there was a critical moment where we as a community had a chance to think through the implications of a potential corporate turn, that was it--but the space was quickly shut down.

Since then, Drupal has taken a decidedly enterprise-focused turn--which is pretty much the reason that Backdrop exists. Was "Dub" right? Was this turn intimately tied to the project's structure?

The section "Re-architecting for world domination" in the March 2013 article in Computer World that Jen recently linked to is important reading here. In that interview, at least, it's hard not to conclude that there's a tight correlation between Acquia's business priorities and the enterprise focus of Drupal development.

In short: structure matters. Let's take a bit of time and get it right.

[quicksketch]

Hi guys, really appreciate the excellent brain-storming here. I really like @nedjo's suggestions around the PMC model, and I completely agree with @sun's comments about making sure there's a clearly stated direction for the project. I too feel like Drupal is a victim of weak goals and direction. The "it's whatever you want it to be" model has resulted in a lot of complexity for the benefit of only those who are able to understand it (and the determent of everyone else).

I've been drafting up some text on philosophy, goals, leadership, etc. in the new handbook @sirkitree assembled for us:

http://handbook.backdropcms.org/about/philosophy/ http://handbook.backdropcms.org/about/organization/

These are not yet official in any way. The initial drafts are to collect feedback and establish a baseline.

Anyway, let me elaborate on why I like the PMC model and think it would be a good fit for the project:

• The PMC can and should be a small group with a unified vision. Multiple people that take a vote on escalated issues provides a gut-check and discussion on issues, even though it's between a small number of people. Keeping it small prevents bikesheding.
• Separating the concerns of project direction (the PMC) from day-to-day work of reviewing and merging pull requests (committers), means that we can have a larger number of empowered individuals and move the project along faster and reduce the "review bottleneck".
• The PMC has the power to add or remove committers or stop/rollback individual issues when conflicts occur. This might be upsetting to the individual who wrote or merged the PR, but as long as it's established beforehand, they accept this situation may happen at the time they become a contributor/committer in the first place. Setting clear expectations makes for fewer hard feelings when conflicts arise.
• The PMC model can outlive the founder(s), it has a built-in mechanism for replacing members by voting.
• The PMC model shares responsibility, credit, and blame, all of which are easier to handle for a group than an individual.

The thing I'm not certain about with PMC however is that it's possible to be disconnected from everyday usage of the product they're building. We might be able to mitigate this however by having non-committers on the PMC, keeping them out there in the real-world. But in any case, you'd have this problem with most approaches and almost certainly with a BDFL.

[sun]

Excellent summary, @nedjo.

Now, that is nice and simple, and a great start. It's extraordinarily helpful to be able to comment on a concrete proposal, so thanks for that, @quicksketch :+1:

Starting with a basic sanity check:

• The keyword "product" does not appear at all. :heart:
  Please bear in mind that a "project" is defined as an organized effort, which, among other required scope definitions, has (1) a start date, and most importantly (2) a termination date (aka. "deadline").
• The keyword "community" appears 5x (across both pages).
  But all instances presume that (1) there is a community, (2) people know how to contribute, and (3) the product management accepts contributions in the first place.

Minor stuff. To get to the bigger questions:

The model of core committers + PMC requires a conflict and escalation scenario to happen upfront. That is not a given.

A smart and thriving community is able to hash out and resolve conflicts on their own in most cases (not involving the PMC). If there is no conflict, then the product's mission statement can and will be undermined in the long run. (natural evolution)

One of the only two ways to prevent that would be to formulate a mission statement that encompasses tons of architectural and technical details. In a sense, whenever a major meta discussion happens and a (product) decision is being made, the mission statement is immediately amended with clarifications about what problems the (future) product is (ever) going to solve (and which not). Although I've to admit that I cannot provide actual data points for this approach, I'd consider it to be unmaintainable (and also ungrokable for contributors, over time).

The other way is the success model of Drupal, before and up until 2008, on which @nedjo (unintentionally) elaborated on. FWIW, the same model is implemented by Symfony and other popular FOSS products. It boils down to a few very active and strong authorities that are driving the product vision and ensuring that goals are met in a complex and challenging system that involves plenty of group dynamics, trust relationships, as well as (more or less) vocal interest groups. The fundamental concept closely resembles the product success factors I mentioned earlier in this thread.

Fact is, that is the most successful concept for smaller communities/dynamics.

Now, the only question is whether you want to prepare and account for scalability at this point in time already. @unconed will sing you a song of how disgusting the role of a final gate keeper becomes, in case the surrounding community and ecosystem grows to a level at which (1) quality and excellence is not a given anymore and (2) you are one of just a handful of persons that continuously have to deny and reject tons of change proposals that are not in line with the product vision, and which do not remotely meet your understanding of quality.

From my perspective, there's hardly a compromise between that model and the PMC model. A small and most importantly talented group of strong and active core committers does not need a PMC beyond them — such an entity would only be disturbing at max, as it distorts the decision authority of core committers.

In other words: When a core maintainer says "No" (at comment #8 instead of #288), then "No" has to mean "No" (with solid reasoning). If, and only if that causes drama, there are 1-2 other maintainers to escalate to, and who are able to either confirm the previous stance or point out potential compromise solutions (different to the proposed solution) that may be attacked in a new effort. (And "No" still means "No.")

We're all engineers after all. We love to invent solutions that enable everyone to make status quo work for more scenarios, and perhaps most importantly, solve everyone's problems.

In short, if you do not "cap" the goal of perfectionism, these engineers (we) will agree with each other, and we will proceed with technical solutions that strive for a perfect system. (Edit: I'm not kidding. — This is hands-on experience from the front lines.)

Sir, the community just invested 200 hours to resolve this problem with this clean solution! — Please reconsider.

Who on earth cares for the product?

[DirectorHaas]

Great comments from @sun and @quicksketch :+1: PMC is way to go. And :+1: on handbook/about/philosophy including the end users, builders, and other customers of the software.

Anyway who ever heard of a Jester designation in Open Source? Just a thought about fail-safe(s) (ref: https://github.com/backdrop/backdrop-issues/issues/59#issuecomment-25108584). If only Rodney the Cat could tell us what he thinks. :) The PMC should provide a fail-safe function in most cases.

The following statement is very true in any complex software system, take your pick:

"If there is no conflict, then the product's mission statement can and will be undermined in the long run."

Or basically if a product is anything anyone wants, entropy will increase (even re-factoring cannot stop it). Alternatively, acceptance of low level conflict, diplomacy, is the very thing which keeps order and moves a system forward.

All that said, "no means no," can save everyone much time.

Yes, it's refreshing to see this kind of dialog. :+1:

[quicksketch]

FYI I moved the handbook to http://handbook.backdropcms.org/ since if we continue using Github pages/markdown for docs (which I do really find to be a good fit), it'll need to live on its own domain eventually. We'll use Backdrop for the primary domain itself.

[sirkitree]

Notably, http://handbook.backdropcms.org/about/organization/ is relevant to this discussion.

[rfay]

This is an awesome conversation and the resulting documents are outstanding.

I think the "passive leadership" approach of Drupal has been a major problem, preventing necessary decisions from being made, and leaving key decisions to brutal yelling matches, or worse, to key unmade decisions, death spirals and "smoking craters". The approach here deals with that at least for now. Yay!

I do suspect that the approach outlined in Project Organization focuses a bit too much on the back end (the commit/committers point of the cycle) when in reality key tough decisions should be made way before commit time. In fact it may be that calling key trusted individuals "committers" focuses on the wrong part of their (hopeful) role in the software development process, as leaders, incubators, guides, and then as committers. Key decisions should rarely be made at the end/commit level of the cycle - they should be made way before that so people have some idea whether their energy is worth spending.

[nedjo]

Great start @quicksketch and others. https://github.com/backdrop/handbook/pull/9 follows up on some of rfay's suggestions along with other small fixes and suggested changes--see the pull request for details.

[jenlampton]

Since we have adopted a management and decision making model, I'm going to close this issue. Thanks all for the feedback!