We know you may have questions about what the new IBM and Red Hat relationship means for Red Hat’s participation in open source projects. The short answer is nothing, but we’ve gathered a few specific questions below that you may have. In addition, I will host an online Q&A session in the coming days where you can ask questions you may have about what the acquisition means for Red Hat and our involvement in open source communities. Details will be announced on the Red Hat Blog. Continue reading
Today, CentOS turns 15 years old. It’s had hard times and good times, and gone through a number of big changes over those years. We feel that we’ve landed in a really great place over the last five years, as part of the Red Hat family of projects, and we’re very excited about what’s coming with CentOS 8, and the years to come.
Right now, we want to look back at how we got where we are now. We did that by going back and talking with some of the people that were involved in those early years, as well as some that joined the project later on. 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
(With Leslie Hawthorn)
For the past three years, we’ve run the FOSDEM Community DevRoom, welcoming speakers from the ranks of open source maintainers, community builders, FOSS non-profit organizations, and agile coaching. We’ve also been fortunate enough to get great reviews on our program curation and DevRoom facilitation, so we’re sharing a few tips to help people who’d like to run a DevRoom at FOSDEM.
This list isn’t just for FOSDEMers, though; it’s good for anyone who needs some getting-started advice on running a single-track program at any event!
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.
Companies are now taking pride in their rankings for providing their employees with flexible, relaxed, and comfortable working hours to help them manage their lives better. In return, employers get access to the best talent from across the world without having to consider the geographical constraints. It is happening now more than ever, and needless to say that no one is perfectly equipped to tackle the emerging unexplored challenges that come with it.
Of course, we saw this coming. We knew there would be problems with the incompatible working hours, the difference in work cultures, technical problems with connectivity, etc. What was inadvertently overlooked was a simple fact that “humans are social animals.” We have been conditioned to rely on society around us for every kind of exchange and we do need a social confirmation of some sort to stay motivated and driven.
I’m often asked about the timing of linux.conf.au as it generally occurs during January, or early February, when a lot of people in Australia and New Zealand are taking a summer break. My response is that the timing is perfect as it provides a much needed mental jump start at the beginning of the year, and always leaves me excited about the amazing things happening within our Open Source community.
The 2019 linux.conf.au in Christchurch NZ, I’m very pleased to say, did not disappoint in this context. It easily stands as one of the best conferences I’ve been to in the last 10+ years, and I already can’t wait for next year’s conference in the Gold Coast of Australia. In addition Red Hat continues to sponsor the conference each year, and several colleagues had speaker slots.
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.
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.”