You can't have DevOps without open source

No readers like this yet.
A sunrise

You probably think I'm going to talk about all the reasons why you should use open source tooling as the foundation for an effective DevOps culture in your organization, but that's not what this is about. Not to marginalize the complexity of the challenges faced by the team I work with, but I have confidence that the engineers are going to figure the tooling part out. Believe it or not, the daunting part is wrapped in cultural change.

I have spent a significant amount of time reading about cultural change, what you need to have an effective DevOps community, how you build high functioning teams, and asking the question, "How do I DevOp?" The ideas I've read have given me a few new things to stick in my tool belt. However, nothing has resonated with me as much as this:

The open source way is...

Open exchange

We can learn more from each other when information is open. A free exchange of ideas is critical to creating an environment where people are allowed to learn and use existing information toward creating new ideas.


When we are free to collaborate, we create. We can solve problems that no one person may be able to solve on their own.

Rapid prototyping

Rapid prototypes can lead to rapid failures, but that leads to better solutions found faster. When you're free to experiment, you can look at problems in new ways and look for answers in new places. You can learn by doing.


In a meritocracy, the best ideas win. In a meritocracy, everyone has access to the same information. Successful work determines which projects rise and gather effort from the community.


Communities are formed around a common purpose. They bring together diverse ideas and share work. Together, a global community can create beyond the capabilities of any one individual. It multiplies effort and shares the work. Together, we can do more.

That is how you get an effective DevOps culture. You embrace the open source way.

If you didn't fist pump, remember a job you have had in the past where you felt like this guy, and then read that again.

Open exchange, participation, community

My career before Red Hat was filled with statements like "just do your job" and "that's just the way it is, you can't change it." I have viscerally felt the horrible feeling of having to tell someone that they couldn't have their idea, not because it wouldn't solve many problems, but because they didn't know the right people or know the best way to get their idea across.

When you have an open exchange and everyone is encouraged to participate:

  • People talk to one another and build off of each other’s collective experience.
  • People earn each other's respect while working together.
  • People are less likely to say, "It's so and so's job, not mine," when they know and respect each other.

No team is going to believe they are in an optimal working environment if someone is saying, "Work together or else." Yes, they will work together, but wouldn't you prefer to give them a reason to want to work together? The reason can be as simple as helping two individuals connect on similar interests, or as hard as getting teams with a long-standing history of disliking one another to work together. But the key element here is a path to empathy and having respect for those you spend your week with. At the end of the day, you need to foster an environment where it is OK to have an opinion, OK to have an idea... OK to share.

Even on the team I'm working on, where the values of the open source way are individually embraced, we have to work hard to continue to cultivate that global sense of community and collaboration. Even at Red Hat it is hard. I strive on a daily basis to provide as much visibility into what our team is working on regardless of how trivial it may seem. The result of this? People are sharing their ideas and helping to build something we can all be proud of and support.

Rapid prototyping and meritocracy

A brilliant thing happened very early on with the team of engineers I'm working with; they reminded me about the importance of just getting something done. We spent a good bit of time trying to muddle through the mountain of things we could work on and the output of that? Well, frankly—it was a lot of talking.

Being able to show someone what you are doing, and receive feedback on that thing, is so much more satisfying than the talking.  Rapid prototyping? Getting to see the code, instead of an idea disappearing into a requirements hole and resurfacing at QA, is so satisfying I can't shout about that enough. In my past experience with closed source projects, I haven't seen code delivered, input received for changes, and subsequently modified very quickly. So, that continues to be transformational for me.

Don't get me wrong, this is not an easy thing to master. Early on the team made a technical decision to move forward with a custom application that could provide certain system information (like software versions running) without requiring root access to servers. I understand that there are tools that already do that, but the team wanted something quick to ease the pain. After we were done, we agreed we would start looking into longer-term solutions to help. We are still feeling the pain from that decision; meritocracy is in full-on mode here where this project is concerned, and no one is shy about sharing the details about the impact it has had on their servers. However, I can still say the work was successful because at the end of the day it delighted the people who needed it the most, and it certainly gets people talking to me.

Consider this

How hard do you think a DevOps transformation will be if employees don't feel comfortable enough to share ideas, are being told not to collaborate because it isn't their job, or it is implied that their financial well-being is wrapped around performing one function and there is no emphasis placed on whole systems thinking? 

The open source way isn’t an easy button for success. However, what it can do is provide a set of values for an individual and a group to follow that can set your organization on the path towards an effective DevOps community. Do me a favor and go back and read those values again. Are you and your organization open enough to embrace the open source way?

User profile image.
Jen Krieger is Chief Agile Architect at Red Hat. Most of her 20+ year career has been in software development representing many roles throughout the waterfall and agile lifecycles. At Red Hat, she led a department-wide DevOps movement focusing on CI/CD best practices. Most recently, she worked with with the Project Atomic & OpenShift teams.


Simply, excellent.

I don't doubt that startups that are limited in funding and can't afford mature tools find value in open-source, but when organizations start to grow and be successful, open source is not the answer. The best example of that is Jenkins, which works great for what it was designed -- small teams, closely coupled. But when the organization grows and you have multiple teams working in different places in the world, Jenkins creates a very well known situation called "Jenkins Sprawl" that gets in the way of growth and control and, unchecked, can lead to failure. Remember, in open source you get what you pay for.

Proprietary solutions come with proprietary costs which force careful consideration of how a tool is used. Therefore it's not Jenkins that is the problem but that it's so open, easy, and useful that everybody wants to use it now instead of waiting for a standardized and supported deployment in a central location.

No, the problem is not the cost nor the proprietary nature of a commercial solution, it's the value that the solution brings that must be considered. Jenkins is simply not an enterprise-level solution, it is a team solution.

To address the concern of sprawl you noted there needs to be goverence. I'm simply saying that closed source tools have an up front and/or reoccuring cost associated with their use and therefore the tool is governed from the beginning. Yes, the value is key to tool choice, but I disagree that Jenkins is not usable for an enterprise level solution. It is more that enterprises are not well positioned to assess the non-monitary cost of using the tool in a uniform and supported way which results in sprawl. Teams are likely to find "real" build tools to be cumbersom, bloated, slow, etc and therefore create a team based solution. Because it is easy, flexible, and open but not because it isn't something that is ready for use in enterprises.

Governance is a separate concept. True governance is when you realize that the tool you are using does not align with the goals of the organization. The only way governance will deal with sprawl is to remove the cause of the sprawl and replace it with a tool that addresses the needs of IT governance. Open source does not translate to easy or flexible. That's a myth that was dispelled long ago.

I see the consequences of organizations experiencing growth and trying to make Jenkins do what it was not designed to do. I see the pain of the management that needs centralized control, information access, collaboration across teams, but can't get it with Jenkins. It's the reason why many organizations are dumping Jenkins altogether, or finding commercial solutions that can deal with the cultural shock of getting rid of Jenkins by first absorbing it and then slowly removing it from the organization's processes.

It's really funny that you'd raise this concern when a quick <a href="">search</a> for "jenkins sprawl" turns up <a href="">CloudBees</a>, a SAAS provider specializing in addressing large Jenkins deployments. Here you have the option of paying for an open source solution in a managed environment - buying the skills of a Jenkins contributor and folks who have focused their attention on how to make it work for the enterprise. Exactly what you asked for!

Oh? And you think that hosting Jenkins as SaaS erases the limitations of Jenkins' design? That -is- funny. LOL! Sorry, you don't get it.

To give you an example of how funny I find your comment, if I followed your logic I should be able to deploy MS Access in a bunch of vm's and call it an enterprise database solution. :)

Open source tools are providing mature value to companies, some of whom are contributing directly to its success. Open source software has been demonstrated to have fewer bugs per thousand lines of code than closed-source counterparts [<a href="">1</a>]. Firms with the deepest of pockets, like NYSE Euronext [<a href="">2</a>] are embracing open source, and have been for years. The best of open source software attracts more users, more contributors, and makes for even better software.

The contributors to open source software are not just amateurs. Professionals contribute core parts of open source code and serve to maintain existing software. [<a href="">3</a>] There is no shortage of people with a vested interest in better open source software.

Excellent insight Jen: an open source culture embracing sharing, visibility, and joint goals brings people together, socializes individual contributions, and improves DevOps team performance.

Your article inspired me to write about how <a href="">DevOps amplifies open source credentials</a>

Don't forget that culture without good strategy always fails, but a strategy that doesn't necessary have a focus on culture can be successful.

Interesting comment Juan... Based on advising hundreds of Fortune500/Global2000 organizations, I disagree. Strategies fail when the culture does not embrace the objectives. To succeed, IT strategic plans must move forward five distinct top-level workstreams; business models, infrastructure, process, governance, organization. Without a cultural alignment of purpose and objectives, top-down strategies fail. I have seen many SOA strategies fail due to cultural impediments; lack of trust, misaligned funding models, team boundaries, and missing service provider mindset. You can read more about cultural impediments to top-down and bottoms-up adoption in a recent blog post, and in a published paper focused on SOA & API strategy and tactics at

The pieces describe how culture trumps strategy, and how the API movement attempts to fix cultural impediments that created a backlash against SOA strategies.

Chris, not a word of what you posted negates what I said. Culture does not trump strategy, ever. Without strategy, it doesn't matter what culture you have, good or bad -- the org will fail, because there will be no target to which governance can be aligned. On the other hand, plenty of organizations succeed with a good strategy but a culture perceived to be inappropriate by people outside the org. The only example I have to show to prove that is Walmart. Anybody who has ever worked with their IT knows what I am talking about -- the mindset that might is right, and inertia = success. And I don't even have to quote my own blog to prove it! Imagine that. :)

While the cultural norms you mention are essential to voluntary efforts like open source projects, they are applicable to many sorts of endevors, to include development of proprietary software (in house, anyway). And even in traditional commercial firms, individual initiative feedback and creativity are necessary to prevent ossification. The boss is still the boss but a boss who expects his people to mindlessly follow orders without contributing their own ideas or otherwise providing feedback is cheating himself, his organization, and (in the case of a commercial firm) his customers. Good ideas come from all sorts of places and from all sorts of people. They don't require a business degree or any other sort of educational background or training (if nothing else, even ignorant questions can provoke good ideas).

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.