To paraphrase my colleague, Dave Neary, cookie licking is when you volunteer to do something and underestimate the commitment required. Then, instead of stepping back so someone else can do the work, you keep the task marked as yours, preventing someone with time from taking it. This can also manifest as staying on as part of a leadership group you don’t have time for, thereby creating a block on consensus and decision making when you don’t have time to show up.
Red Hat Community News
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?
There’s big news coming out of KubeCon Seattle today: our team is donating a keystone project to the Cloud Native Computing Foundation (CNCF), ensuring that project’s longevity and success. The open source etcd project has been donated and accepted into the CNCF, a neutral foundation housed under The Linux Foundation to drive the adoption of cloud native systems.
Open sourcing code is always at the forefront of Red Hat’s goals, whether we start new projects like etcd, which has been open since it launched in 2013, or opening projects whenever we acquire software that is closed and proprietary. We have done it so many times it is second nature. We open sourced oVirt after we acquired Qumranet, Aerogear after picking up FeedHenry, and Ansible Tower after adding Ansible to our ranks. We are firmly committed to the open source model of collaboration and innovation, so when we do have closed code in our portfolio, it’s not a question of “if” we will open source the software, but generally “when.”
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.