Collaboration in open source is usually considered in broad terms: communities, workflows, and processes. What is sometimes forgotten, though, is that often the best part of open source is getting a few people in a room together and just letting them… create.
This was the approach adopted by DevConfCZ’s visual identity team, a group of three volunteers who took it upon themselves to update and coordinate the visual elements of the tech conference held in Brno, Czech Republic. And while much of their work was done online, as so much collaboration is done these days, often their best work was performed getting together, listening to music, and just bouncing ideas off of each other.
I remember the first time I rolled into the ULB Solbosch campus in Brussels. It was 2014, just after I first started with Red Hat. I was there to attend my first FOSDEM, the free software conference that holds a unique and prominent place in the technology world.
Even though I had been a writer and a community manager in the Linux and free software ecosystem for nearly 14 years, I had never had the opportunity to actually attend. (Pro tip: media companies are cheap.) So looking around that gray chilly day, I had to take a moment to take it all in.
For some people in the IT sector, attending conferences is par for the course in learning more about technology and networking with people in their area of interest. But while many people take attending such events for granted, in reality, it can be a struggle of time, resources, or finances to get to a tech conference. The organizers of DevConf.US have recognized this and have made significant efforts to try to remove the barriers that are preventing attendees from getting in the doors.
For Marina Zhurakhinskaya, Senior Program Manager for Diversity + Inclusion Outreach at Red Hat, the key is to focus on all elements of diversity and inclusion. Continue reading
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
There is a saying in the legal profession that you should never ask a question you don’t already know the answer to. Despite how this sounds, it is actually a rule most people follow in life. This is the source of that feeling you get when you’re too scared to raise your hand and ask a question. In Open Source we need to make sure that contributors feel like they already “know” the answers, so they will feel confident in making the request.
As a university lecturer, I always encouraged my students to first think about what they thought the answer was and then ask the question. In some cases, I encouraged them to actually write down what they thought the answer was. In this way, they could judge both their skills and their ability to grow based on what the answer turned out to be. It created an additional feedback loop.
One of my favorite sayings is “If you want to make God laugh, tell Them your plans.”
It’s not my favorite by making me feel good, since it’s usually something I’m reminded of after one of my own plans has gone kablooey and I’m sitting in a pile of smoking ruins wondering what the heck just happened. Then I remember: God just had a chuckle.
Your own belief system may differ from mine, but there is a lot of evidence in any worldview that Life, The Universe, and Everything is highly resistant to many (if not all) forms of control.
This time of year, Brussels, Belgium is always a big community focal point for free and open source software, when FOSDEM brings passionate and talented members of the community to town.
Many organizations take advantage of the gathering and stage events of their own. Red Hat’s community members are pleased to host and participate in all of these events, especially FOSDEM.
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.
Attending KubeCon + CloudNativeCon 2018 was an eye-opening experience for someone like me. On paper, it was a very product-oriented conference, with the focus of my fellow Red Hatters on product and feature offerings in OpenShift and a whole host of Kubernetes and container-oriented software. Attendees here are very much developers and operators who are here to learn about how this technology works and how they can best use this tech in their organizations.
So what was a community person like me doing in a place like this?