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?
People, in general, have a hard time moving outside their comfort zone. Or even thinking about it. We can plan ahead for events that cause us discomfort, but when things are going well–especially when they are going well–we can fall into the trap of complacency.
For example, right now I am dealing with a head cold. It’s no big deal, I am still plodding along at work, getting things done. But I did not plan for this, and my productivity levels are correspondingly low this week.
We are rapidly entering a new era.
The era where data is the lifeblood of the worldwide economy.
The era where organizations that learn how to channel their data will survive.
The era where those that do not will become dinosaurs.
I am reading Superminds – the The Surprising Power of People and Computers Thinking Together by Thomas W Malone–a book which calls out various facets of injecting Artificial Intelligence into thriving ecosystems of humans working together to augment the collective intelligence of these groups as a whole. Malone takes us through a journey into a world that brings to bear collaborative technologies and machine learning to aim for the perfect enterprise — An enterprise that can be ideally positioned to formulate and execute the most effective strategy to be successful. Respecting one of the “super brains” in the recent past, Malone calls this enterprise “Alberts”. I continue to read this page-turner and within a few pages, Malone references Wikipedia and Open Source software as highly de-centralized online groups that are much more prominent — just as he had predicted in his Future of Work book published in 2004. This got me thinking. Can this concept of the “Supermind” be applied to Open Source? Taking a cue from Malone’s idealistic enterprise–“Alberts”, join me as I inject a new member into the Open Source community–O2S2.
A replacement plan/document is a great community resource, even when you’re not being replaced.
A year ago, as the role of RDO community manager at Red Hat was moving from one person to another, that team started thinking about what needs to be in place to effectively transition a role. More generally, the managers started thinking about planning, and documenting, for anyone’s eventual replacement.
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.
It is a convenient myth for a lot of people in the free and open source software community that our projects have few barriers to entry beyond a base set of knowledge about the project new contributors want to try to join, and the skills need to contribute to a project.
Diversity, to a lot of people who buy into the pure meritocracy myth, is a problem that can be solved by accepting anyone who can contribute. It’s the contribution that matters, not the person’s race, gender, or other identifiable status. Train more people up, the meritocrats will argue, and the diversity problem will be solved.