Sooner or later in the growth of a community project, the question arises of how to choose representatives for the community. For some projects, this is when they lose a founder, and as a group decide to move to a “ruling technical council” model; for other projects, the need comes from the move to a non-profit governing body with paying members, and the desire to have a technical steering committee chosen from members; other projects evolve over time to a representative leadership model.
I have been involved in boot-strapping, reforming, or running elections in a number of different communities over the years (GNOME, Maemo, OpenStack, OPNFV, OpenDaylight, fd.io, and others). Which voting system to use, how to define the electorate, and limiting the pool of eligible candidates have tended to create the deepest rat-hole conversations in all projects I have been involved in when the topic of elections has come up.
The phrase “cookie licking” has become popular in recent years to define a pattern which can be problematic in communities. Its meaning comes from a story: Mom makes a plate of cookies, and sets the on the table for the family. After everyone has had their cookies, there is one left on the plate. The cheeky child of the family wants to have the last cookie later, but has no confidence it will still be there when she comes back, so she grabs the cookie, licks it, and puts it back on the plate, secure in the knowledge that no-one else will want to eat it.
A project roadmap is a valuable document for a community open source project. For growing projects, even when the developers are predominantly working for one company, the roadmap is invaluable and accomplishes a number of things at once:
- It is a great tool for setting shared priorities and setting limits for what is in and out of scope for the project
- It encourages the developer team to be transparent about planning and provides context for more discrete quantities of work
- For engaged community members, it gives an opportunity to contribute to the improvement of the project, by suggesting features which are not on the roadmap, or by volunteering to develop features, which are included but not yet committed by the core team
- Finally, for casual users of the project, and visitors evaluating whether they would like to use the project, it gives an idea of what is coming down the road
“Should we open source this project?” An easy question to ask, and a hard one to answer. The goal of this article is not to answer the question, but maybe to give some tools that you can use to find the answer when the question arises.
The first question to ask is why the project leader is interested in open source in the first place. Typical answers might include “because we want a community” or “because we want to be the Firefox of our field.” But when you dig deeper, there may not be a clear understanding of how an open source project can benefit your company’s goals.
The creation of an open source strategy is about finding that benefit. In short, you want to understand why open sourcing this project will benefit the company.
The open source community manager is one of the most diverse roles in the industry. Each community manager has an opportunity to define their role and areas of focus based on their skills and interests, and on the specific needs of their community.
As a result, they are often not a natural fit in any part of a traditional software organisation, but have a dotted line relationship into a number of teams.
There are many traditional software and product development roles that a community manager can fill for an open source community.
Here are five I’d like to highlight:
- Partner/ecosystem development
- Developer enablement
- Product/release management
- Product strategy
In the last article, we finally went beyond theory to some practical tips on how to improve communication in your community. In this article, we get even more practical, offering some easy to follow tips which will make a material difference in your communities.
There are two concrete things—one piece of advice for both community developers and individuals seeking to join a community, and one piece of advice for community projects interested in encouraging greater geographical diversity. Each one has a number of consequences.
In the preceding article, we covered the six dimensions of culture according to Geert Hofstede, and explored the consequences that these dimensions may have on people’s cultural attitudes. In this article, we explore some more practical ways to uncover cultural assumptions through good communication.
Sociology theory is all well and good, but how can we apply this to interactions in our communities? Is it possible to apply Hofstede’s cultural dimensions theory to real-life interactions in community projects?
In the previous article, we outlined how cultural dissonance can cause issues when cultures collide. In this article, we talk about what makes up cultural identity, and perhaps help you become more aware of your own cultural assumptions.
In "Cultures and Organizations", the sociologist Geert Hofstede identified six dimensions for characterizing a culture. The effects of these dimensions can be analyzed according to multiple characteristics of a culture, including education, social structure, political and economic systems, religious attitudes, traditions, and customs.
Communities are messy. What makes them messy is the relationships between the humans who make up those communities. Humans are complex beings, each with their own sets of experiences and assumptions which they bring into a relationship, and when the underlying assumptions about how the world works do not match, we get into trouble.
One colleague of mine has described culture as "the way that humans in a community actually do things." The things we say and do consciously are the tip of the iceberg—many of our reactions and feelings are unconscious, and based on underlying values and assumptions about society which we may not even be aware we have.
Editor’s Note: Speaker notes for FOSDEM 2017 talk in Community DevRoom (video included).
For anyone reading this who has been a parent, you will know that the most surprising thing about toddlers is how fast they change. You go away for a couple of weeks of business travel, and when you get back, there’s a different person waiting for you when you get home. And two years old is about the time when the rate of change is at its peak.
That is what OPNFV feels like now: we have navigated the early teething issues and reached a state where there is lots of change and lots of progress. We have labs on every continent, many active projects developing new NFV related functionality, three platform releases, and increasing industry interest. Two and a half years ago, NFV was a promising architecture concept. Today, operators are putting NFVi platforms into production, thanks in part to the work of OPNFV.