Building a Community that can Challenge itself
Playing devil's advocate.
Noticing more and more in certain communities that there's a status quo and a tendency to not challenge the status quo. Things work a certain way, and have always done, so why change it?
There's a couple of areas:
1) In Ubuntu, traditionally been a distribution that packages upstream software. Wanted to change focus around app developers instead. Series of challenges (technical, policy), but… reactions from community about "Why would you want to do this?" Where I feel this is necessary to move forward.
2) Diversity debate. Women in open source, harassment, etc. Sensitive set of topics. There's a status quo. People feel nervous about shaking it up (right or wrong reasons). We need to focus in our communities on challenging the norms, think differently.
In apps development goes from "How do we move things in the right direction" and "How do we encourage people to move into brave new territories without feeling weird" etc.
So, how do we challenge the standards/conventions we're familiar with in our community?
One technique is consistency, openness with introducing ideas to community. Through moderation team, even if we know what we want to do, we still involve community and ask them if they want to do this. So when we have a question of what we don't know how to do, we condition them to know what to expect
First problem is getting people to agree on what "forward" means. If your community has existing charter of "This is what this organization exists to do" then it's more obvious. You can have disagreements on how to achieve that. Can also point out that "That was our charter back 10 years ago, and it's time to revisit it now."
Agreed, this is the type of transition period we're in the process of going through. 1998 limits in terms of relevance to consumer technology. It changes a lot of things. A lot of decisions we've made furthering that direction have been controversial; demotivating to people. Very politically insensitive in concept of community to go this way, even though it's very exciting for Ubuntu.
Also pressure to keep the community happy. But some members of community are unable to think of bigger picture moving forward. Want to think of ideas of how to challenge these norms, where we say "we're going to do this" that it's given fair and accurate consideration
I think it's easy to fall into the trap of "Bigger community = better." But a smaller group of committed people is much better than a large group of uncommitted confused people. Shuttleworth, Jobs, tell people what they're not going to like. Doesn't make me passionate, but they don't need me. In my communities, the more I can create a steady core,
One thing that's coming to mind is alpha/beta testing of that nature. With that concept, could you have a working group/oversight committee that's part of the community itself that's part of looking forward to the future. Let the community think already that changes need to be made in a strategic direction.
One of the things related to that, my experience with open source specifically is a lot of innovations come out of companies that pay people to develop software. Lots from volunteers as well, but many from product development direction as well. Companies tend to be more strategic, open source better at fleshing out bigger picture.
Linux, lots of modules here and there to flesh out coverage, but companies are good at defining vision. Communities can already coalesce the troops around an idea and get people excited about it, but often this vision comes from companies that give people full-time work to do.
Part of the challenge is people are resistant to step up and take on that role, but often been surprised with how often people do that if you tap them on the shoulder and ask them to step up.
Even if they're not employed by community, often have a stake because of their own use of the project, so get involved that way.
Problem you're talking about is not related to communities; human group problem. We tend to resist change. Groups develop a status quo, and when we need to shift it's difficult. Bt there's a lot of knowledge/intelligence around dynamics of change. Tapping into that (group psychology, anthropology) is a huge field, with lots of intelligence (resources, patterns).
Drupal going through similar thing; pulling in Symfony components. Pulled together real-life sprint with project leads, contributors working on Symfony, detractors. Able to hash through things in 3 days, walking people through code and demonstrating value, taking that back to the community.
We have a similar situation where we get people together like that. But it's more about communicating vision. Some people get right on board, see the vision. Others can only find problems. Maybe part of it is a better way of articulating that vision. What always convinces people is running code. But difficult when trying to get traction in order to get that code done.
Struggle is challenging the community to get behind the vision.
We're struggling with moving from SaaS to PaaS. Different user community, but same developers. We're leaving the old stuff running while the new stuff comes online. That allows them to stick with what they're comfortable while we progress.
But what happens with people who are doing what they are doing… the thing you're bolting on is quite different. It doesn't compromise existing system, but does mean new policies around permissions, etc. The thing that worries me is people don't like the idea of that because "it's different." Trying to figure out a way to communicate that vision.
Could you try some other methods of communication (e.g. podcast "webinar" (puke)) to try other ways of articulating vision?
Yeah, we're trying different ways of doing that.
One other issue is a "sense of ownership." If we start bringing up thoughts of changing it, it starts to make people feel threatened. Make people feel like they "own" the change, rather than feel like it's something being thrust on them.
Make something shiny/interesting, "You get to own MORE" (with glitter, unicorns) :)
You're dealing with individual FUD. Fear of the unknown/of change itself, Uncertainty about outcomes, Doubt of one's place in the new order - what your role is in it. First step is to acknowledge the situation. Change can create a lot of FUD. Acknowledge this. As a first step, that alone takes care of a big part, because people are acknowledged, and, given the opportunities to voice their worst fears takes power away from the fear. Resistance is an emotional response, not rational, so not as amenable to direct argumentation or rebuttal. By reframing, still have resistance, but now working *together* in getting through the FUD.
Go through that with MySQL…
Yeah, fear is always that company makes decision in "ivory tower" and you only find out after the fact.
Some "kerfuffkes" lately around how decisions are made. Concerns around transparency. Matt suggested "Every time you're about to make a decision, try making it a proposal, get community response." Even if you make the decision they don't want, they feel like they were listened to, not just the top 7 people who can invest the time who get to make it.
We'r e trying it, will see how it goes. Matt's fear is project being led by committee. But it's not a committee with lots of red tape, just saying "before you make a decision, let's have a chat." Even president has advisory council brought in on decision-making process. Don't have that for our BDFL situation.
Most other open source projects have some sort fo process around this, but if you don't have distinct roles "What is my role? How much of a voice do I have in this decision?" then you *always* have FUD.
So maybe blueprint for how to approach situations is.. we always talk about how to deal with FUD. This is generally seen as derogatory, but it's a good way to think about how to break this down.
Similar to women in open source conversation, part of it is put yourself in other peoples' shoes. "What kind of fear will we see? What kind of uncertainty?"
People have been grappling with this in every group organization situation for long period of time. Some is in academia, others is people in the trenches. Making a proposal vs. making a decree… Advantage is that proposals may result in feedback that improves proposal itself, or even better way for it to be adopted by the community/"sold" to the community - make the community challenge not the change itself, but rather "how are we going to master and communicate this change together". You already hit on key things: "What's the worst that can happen?" "What are you worried about?" give people space to articulate that.
Issue of diversity is a problem w/ everyone in tech world. One of the ways people are tackling is reframing, to change thinking around what diversity is. Not just gender, ethnicity, etc., but differences of opinions, outlooks, styles, etc. Once they make the connection the diversity of opinions, diversity of other kinds becomes more palatable to those who tend to resist it.
Similar strategy: If you have a decision and that's the way you want it to go, introducing "concept" to the community, finding people with similar ideas and let say "oh, you already had that idea." reach out to them.
Give people space to air concerns and acknowledge = step 1.
Stage after that is once you get that out of the way, build out toward the goal. I am a 1998 linux user, but what are the goals for our community? This thing I'm suggesting with having more awesome apps, does that meet our community goals? If so, awesome! If not, maybe we fork and don't have the same community.
FUD is also a system preserving property. one of the things to think about is that all FUD is not useful. A lot of times we want to get rid of these problems, get them out of the way, but dig into the core truths and figure out how to resolve them. Don't want to get a product that's off base.
I was thinking about this as a community that embraces conflict. How do we use conflict as a way to move us forward?
I feel like generally I'm ok with dealing with conflict and handling crises. But the thing I wrestle with is that I have a set of strategies for dealing with these problems, but stuck on how do we build a forward-looking community where we preserve the values of the community? When talking about building a core, every community has a set of values, and these rarely change. But the focus, implementation does.
Usually when someone puts something on the table that's incredibly controversial, it does cause conflict. Worry about people joining community and all they see is fighting. Want to be able to have proactive discussions and not defensive ones. Trying to provide reassurances around the values, but falling short.
Certain amount of bravado. Confront people when they're being unreasonable, non-solutions-focused. How do we transform conflict into practical solutions? I have a solution, but feel like I'm going through the blocks to get there.
Drupal does a "code thaw" period where all ideas are on the table, no judgment. Brainstorming phase. Last about 1/3 of the release cycle.
Risk to org is that once the community's empowered, the community is, in fact, empowered.
Is it about feature requests or what people are working on?
To kick off "code thaw" we have the a kick-off post called "personal battleplans" where you talk about what YOU want to work on.
We have this "User ideas" thing which is just a load of stuff that is probably not going to get done.
[HELP: huh… sorry, lots of stuff :( basically +1 that sounds good :P]
Include the company roadmap in with the community roadmap.
Process of change management, is bringing community on board to feeling ownership of the problem.
Something I like about this idea is it defines how people discuss it. It defines this is a period of discussion/openness. Not just a focus on company, but a focus on community and how they can bring value rather than latching onto value that Canonical people can give.
Reminds me of "improve" not allowed to say "No," only "Yes, and"
When the innovation cycle shuts off, do you lose steam?
yes, this is a risk. D7 took 1.5 years between code freeze and code thaw. Thinking of differnet
- Define values for the community, can't be compromised.
- Define the mission. Tie everything back to the mission.
- Have a sensitivity to the fact that change is emotional; causes fear, uncertainty, doubt. Focus on implications of change, not why you should be doing what you're doing.
- Frame context of change about what you're doing about this direction and what you can bring.. NOT "this is what we're doing. Get ready." INstead, "This is what we'd like to do, what would YOU like to do?" Big app change would feed into this, as opposed to being THE big change.
It's like a railway track: values are getting you there, mission keeps you on track, everyone who wants a seat can have one. [paraphrased]
Don't dismiss FUD, but acknowledge it. Instead of "Powert to the pain" go "Oh, my hand is on fire!" :)
Not everyone is going to go along, but that's ok.
The more you try and push people away, the more it comes back. How to roll that into the change process rather than
Rather than how to make one shift in the organization, how do we get everyone involved?