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
The adage “knowledge is power” is usually a very good one. After all, the more you know about what’s going on, the more you can usually make a better decision about the things you need to get done.
In an open, collaborative environment, methods such as more transparent processes can lead to more efficient knowledge sharing. which in turn can lead to more effective decisions and outcomes.
But such systems also have people involved, and when that happens, sometimes the most ideal open framework can be thwarted from its intended goals.
These were just a couple of variations of hashtags that propagated through the chat channels shared by Red Hat associates and upstream community members during the course of the DevConf.cz and FOSDEM events, as a flu-like infection went off like a bomb among our friends.
A lot of people think New Years Resolutions are doomed to failure, so instead of going down that path, lets do something that will create the opportunity for progress. Let’s all stop licking cookies.
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.