In the early days of open source, projects did not have community managers. Collaboration among developers was a given, and if you were lucky, some people in your community enjoyed tasks other than software development, like tending to infrastructure, organizing events, or leading a marketing team. As open source has matured, there are many more projects created from within large companies, and these things are no longer a given. Increasingly, people inside those companies are designated the Community Manager or Community Architect, and are tasked with ensuring that projects run well as collaborative, multi-vendor efforts.
Much has been written here (1, 2, 3, 4, 5, 6) about what a community manager may or may not do–but if one thing is certain, it is that projects evolve, and the role of community manager evolves with them. In the life of a project, a time may come when the original community manager is moving on–to a different job, a different role in the project, or just taking a back seat because of life.
At its beginning, every open source project starts with code, and one or more developers. What turns that project into a community are the people who engage with each other around that code. No matter what the maturity level of your project, one of the most important things to encourage and maintain is engagement with the users and contributors of your projects.
When a user of your project makes the effort to engage with the developers of the project, treat it as you would a gift from someone close to you. This person has taken time that they could have spent on something else, and they have chosen to spend that time contacting you. Whether it is a bug report, a feature request, or a pull request, these first interactions are critical to whether that person will have a positive or a negative impression of your project. Continue reading
When a piece of proprietary software that has been developed for a few years is being open sourced, there is often a perception in the engineering world that it should be quick and painless. After all, what’s involved besides picking a license and making the code repositories open?
Here are a few things that come up when moving from a proprietary to an open source development model for a project. Continue reading
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?