devopsy.kinsta.cloud

Tag: open source community

What I’m Thankful for in DevOps This Year: Living Through Interesting Times

Whether it’s the breakneck pace of innovation, including AI and how it is changing our day-to-day, the shifting regulatory landscape, or simply the challenge of keeping teams connected in a world that’s still figuring out hybrid everything, we truly are living at a historic juncture. In the spirit of the season, I want to reflect on what I’m thankful for in DevOps this year — not just as Shimmy the founder and editor, but as Alan the community member, fellow traveler and eternal optimist. Because for all the drama and disruption, there’s still so much to appreciate.

Five Reasons I’m Grateful for DevOps This Year

1. The AI (R)evolution Hits DevOps — And We Dove In

Like everyone else, DevOps couldn’t escape the gravitational pull of generative AI and machine learning (and let’s not forget agentic AI). But instead of shying away, our community embraced it — experimenting with AI-driven code review, smarter testing tools, automated documentation, and even “prompt engineering” as a new craft. I’m grateful for the way we didn’t treat AI as a threat but as an opportunity, driving innovation from chaos and charting new paths for collaboration between humans and machines. On a personal note, I’ve seen so many practitioners leap from fear to curiosity to mastery, sharing lessons learned and building open tools for all. That’s classic DevOps spirit.

2. Security Finally Gets a Seat at the Table — For Real

It’s been a long journey, but this year, DevSecOps matured from buzzword to baseline. High-profile breaches and an ever-expanding attack surface forced organizations to move beyond compliance checklists and into true security-by-design. From SBOMs (software bill of materials) becoming table stakes to greater investment in secure supply chains, I’m thankful we’re not just talking the talk anymore. As a community, we’re shifting left, right, and center to build safer pipelines, and that benefits everyone. Personally, it’s rewarding to see the security conversations I’ve championed for years finally become front and center. I’m not saying we solved security, mind you, but it is getting the attention it deserves.

3. Remote, Hybrid and Flexible Work Are Here to Stay — And So is Culture

Remember the scramble to go remote? Now, we’re refining it. I’m grateful for the creative, resilient ways our community has adapted. From asynchronous communication practices to dynamic incident response rituals, we’ve managed to sustain (and sometimes strengthen) open, blameless cultures in a distributed world. That’s no small feat. For me, it’s a joy to see companies invest in “DevOps Days” both online and in-person, and to watch global teams swap wisdom across Slack, Discord, and even just plain Zoom. Communication is key to DevOps, and we are better at it than ever.

4. Platform Engineering and Internal Developer Platforms Find Their Groov

If you’d told me a few years ago that “platform engineering” would become one of the hottest job titles in DevOps, I’d have raised an eyebrow. Even more, after the “DevOps is dead marketing nonsense, thinking of platform engineering as part of the tribe was not on my bingo card. But here we are, and I’m thankful for the thoughtful focus on developer experience, self-service and scalable enablement. Internal Developer Platforms (IDPs) aren’t just tech — they’re a cultural movement to reduce toil and friction, helping teams spend more time delivering value. I’ve heard from countless engineers who say, “I just want to build,” and that’s music to my ears.

5. The DevOps Community: Stronger, Louder, More Inclusive

This one never changes, but it’s truer than ever. I’m grateful for an ecosystem that’s fiercely inclusive, open to newcomers, and unafraid to challenge the status quo. From meetups and open source initiatives to hard conversations about burnout and diversity, our community has shown up for each other. devopsy.kinsta.cloud hosted stories this year from underrepresented voices, from junior DevOps pros to industry legends reinventing themselves. That diversity of thought is DevOps’ secret weapon—and my personal inspiration. This, coming from a Johnny-come-lately to the DevOps world just 13 or so years ago.

Three Things We’re Less Thankful For

Lest you think it’s all Unicorns and rainbows, let’s be real: This year hasn’t been without its struggles.

1. The Ongoing Talent Crunch, Layoffs and Burnout Epidemic

Demand for DevOps talent is hotter than ever, but supply — not so much. The result? Overworked teams, slower delivery, and a rising tide of burnout. I’m not thankful for the stress, the 2 a.m. incident calls, or the attrition I’ve witnessed. We need to invest more in mentorship, training and sustainable practices. I am also stressed about the frequent requests I get on LinkedIn from friends and colleagues who have been part of the massive layoffs in our industry. I wish I could help each one of you find your next job, but jobs are hard to come by today.

2. Tool Sprawl: More Tools, Less Flow

We love tools, but this year the ecosystem seemed to explode — again. Developers and operators alike are struggling to juggle ever-expanding toolchains, integrations, and dashboards. Instead of “you build it, you run it,” too often it was “you integrate it, you curse it.” We need a renaissance of simplicity and focus, or risk losing sight of what matters: delivering value.

3. Security Theater and Compliance-Driven Thinking

Yes, I’m grateful for security’s rise — but not when it’s all checkbox compliance and theater. Some organizations still treat DevSecOps as a patch to be applied rather than a mindset to be embraced. When regulation is the only motivator, we risk building brittle, reactive defenses rather than proactive, resilient systems. We can — and must — do better.

The Shimmy Take: Grateful Beats Grumpy, Every Time

Looking back, it’s clear: We have a lot more to be grateful for than to be upset about. The future of DevOps is brimming with promise. AI and automation, when guided by our values, will supercharge human creativity — not replace it. Our focus on security, culture and experience will pay long-term dividends. And the beating heart of DevOps — this irrepressible community — remains strong, curious and generous.

As we head into the holiday season, I’m filled with excitement. There are new technologies to explore, new voices to hear, and new challenges to tackle together. I believe the best days of DevOps are ahead of us.

To all our devopsy.kinsta.cloud readers, contributors, skeptics and champions: From the bottom of my heart, I wish you a wonderful Thanksgiving and a joyful holiday season. What I’m most grateful for, every single year, is your continued support, engagement and passion for making DevOps (and the world) just a little bit better.

Onward.

November 26, 2025
Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: SUSE announces a Red Hat Enterprise Linux fork after Oracle said a similar thing, and Sarah Silverman says OpenAI and Meta have stolen her words. (more…)

July 12, 2023
IBM/Red Hat Sparks Anger at GPL ‘breach’ as RHEL Source Locked Up

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Red Hat Enterprise Linux (RHEL) goes closed source. Well—no, not really; but IBM’s lawyers are accused of skating so close to the edge of legality that they risk violating the GNU Public License. (more…)

June 29, 2023
The Benefits of Open Source Technologies

Over the last 20 years, we have seen the proliferation of open source software and technologies become part of commercial offerings, either as part of the technology stack that powers the product or part of the product itself. Although these two use cases are largely different, both have come to showcase just how useful open source is, not only for the developer community but for businesses as well.

One of the benefits of working with open source technologies or projects is the free sharing of ideas. Open source brings people together to brainstorm and develop a common piece of technology. The shared love for what they do crosses cultural and geographical boundaries. One of the best-known – and arguably, most important – open source projects is the Linux kernel and operating system. Linus Torvalds released the first version of the kernel to the open source community through a mailing list, sparking worldwide collaborative development and widespread adoption.

The passion for open source stems from a deeply rooted belief that contributors are solving an important problem, and that they are working towards the betterment of the world as a whole. In many cases, this is demonstrable. The Linux kernel now powers the majority of data centers worldwide, serving billions of users. But it’s not only that subjective passion that has played a key role in establishing open source technologies. The peer-review process of open source projects means that each code commit passes a rigorous, public audit and verification process. It has proven to be a superb way to increase code quality, reduce bugs and regressions and guard against vulnerabilities. Research has shown, objectively, that this process produces higher quality software than the standard, proprietary quality assurance and testing procedures.

When selecting an open source technology to use in development, there are a couple of issues that need to be considered in order to safeguard the quality of your product. One key consideration is to resist chasing the latest technology fad. Instead, select the right technology for the job. It’s in developers’ DNA to obsess over new and exciting technologies, but this does not always mean that they are appropriate. While Kubernetes may be the right solution if you need to serve millions of users at Netflix-like scale while managing maintenance and cost, it likely isn’t the best choice for a new startup launching the first iteration of their product. In this case, speed of development and flexibility to make changes is more important than scalability (so, perhaps, the startup might be better off using Ruby on Rails or Django). These three projects all share an important characteristic: They have active communities that not only safeguard project features but also maintain them and offer peer-to-peer support.

When implementing a new feature with a particular technology, this supporting community is very important, since they can greatly accelerate the development of your product. These are people who love what they do and want to see other community members succeed with the technology. In this regard, it’s also important to consider giving back to the projects and communities you benefit from. You can either participate in the communities and help others yourself, one-on-one, or contribute by sharing the improvements that you have made to the open source technology. If you have extended the API, for example, or discovered and fixed bugs, there is no reason not to contribute your changes back and further enrich the ecosystem. The credibility you build in this way can also be a benefit, as people will identify you, your team and your product as supporters of the open source project. It’s a virtuous cycle of collaboration with benefits that should not be underestimated.

As you and your product become an important part of the open source ecosystem, either because you use open source components or because the core of your product is open-sourced, remember that trust is notoriously hard to build and very easy to lose quickly.

Whatever one’s feelings are on this matter, the open source community is very careful about who they trust and can easily be alienated by a company that appears not to have their best interests in mind. In order to build trust, it’s important for teams to build credibility. Open source communities are largely merit-based, so unless the community sees proof of expertise and knowledge, they will not automatically trust a self-proclaimed expert. This credibility can even extend to the personal, like the many open source developers who have a large following on social media and lend their credibility to the projects and companies that they work for.

Finally, when dealing with open source technologies, projects, and communities, it’s key to remember that developers are very sensitive to blatant sales pitches. Authenticity matters in the way that a project, company or brand presents itself. Open source is all about collaboration and community; it’s a relationship built on trust and mutual benefit, not profit.

February 9, 2021
5 Areas to Consider When Building an Open Source Stack
Open source software has gone mainstream, propelled by the increasing maturity of many communities and tools working together with organizations seeking ways to deploy software faster and cheaper. According to Gartner Research, over 95% of them are deploying open source software, and while it brings many benefits, it also introduces a whole new set of challenges, beginning with choosing the right open source stack. There are multiple risks including disappointing software performance, tools that cannot connect well with others, surprise additional costs, lack of control and security problems.

Choosing the right open source stack is not easy. Many organizations lack the internal expertise to know what to look for or don’t have the time to research open source software sufficiently. Software engineers can’t be expected to become open source market experts overnight.

Some years ago I worked with a team that certified open source solutions to be used in production. We created a list of 42 necessary qualifications to consider, which is (at least part of) the answer: Start by knowing what questions to ask when selecting open source software.

Open Source Considerations

Here are five areas to consider when choosing open source software:

Time: While the ability to download open source and get it running fast might be tempting, it is better to invest in due diligence or think about working with an external specialist who can carry out the research. Take time in building the right solution for your use case(s). It is important to note that open source is often purpose-driven and chosen to perform a specific task; you may need to combine several different projects together to arrive at a complete solution.

The Backers: While volunteers play an important role in successful open source, the fact is that the majority of the most well-known tools have sponsorship. Having a committed backer with a strong track record is a good sign for both longevity and software quality. The example I often cite is the Cloud Native Computing Foundation, which is behind Kubernetes, Linux and Prometheus.

The Community: The commitment and responsiveness of the community are essential. Essential questions to ask include:
- How fast does the community respond to queries or bugs?
- How well do its members document and share collective knowledge?
- How active, large and stable is the community? Is it likely to be around long enough to support the required use case for which the software is being selected, or is the community and the software likely to pushed sideways by something else on the horizon?
The Different Types: Even some very knowledgeable CTOs do not properly understand the different types of open source, especially the difference between copyleft licensing and permissive licensing. Each has very different implications for an organization. The first requires contributors to share their changes with the relevant software community, while the second doesn’t make that obligation. Businesses are nervous about having to share parts of their proprietary source code and possibly their IP, though this only applies if the business modifies the code.

Unforeseen costs are implicit in all of the following categories:
- Time: could be wasted instead of saved if the solution doesn’t end up matching the use case.
- Solution updates: A project without “the backers” runs the risk of dying and not receiving any more updates, forcing a business to spend energy choosing a new solution. The same is true for the community.
- Legal ramifications: Businesses have faced expensive legal action if they modify and distribute copyleft source code without sharing it back.
- Availability and support: Will the organization be supported by a third party, the community and by its own team? Consider the potential costs of all of the options.
Software Quality and Integrations: It’s important to look at coding practices (do they align with the organization’s own standards?), usability and support for distributed resources. Above all, scrutinize integrations, because one of the biggest risks when building an open source stack is ending up with a bunch of tools that won’t work together or are not all aligned on the use case.

Examine integrations throughout the stack: platform, database, middleware, application runtime and monitoring tools. Look for solutions that have lots of backing and that are known to interoperate well with lots of other solutions, such as Kubernetes. Concentrate on well-adopted language distributions such as OpenJDK, which can run tons of other enterprise-class open source on top.

It can be difficult, but choosing the right components for an open source stack will help make future curation easier and benefits clearer to see. Spending the time on research and asking the right questions from the beginning could save a lot of headaches in the future.
July 6, 2020
Using Open Source for Better DevOps Outcomes

Many insurers have jumped on the DevOps bandwagon in order to improve the efficiency and effectiveness of their systems and systems implementations. Very few insurers, however, spend much time thinking about the open source software community as a way to improve their DevOps approach–and the skills of their developers–and in that regard they’re missing a golden opportunity. In fact, insurers often restrict their developers from updating or contributing to open source libraries because they don’t realize the potential benefits available to them by participating more actively in the open source community.

A 2016 survey by 451 Group indicated that the more companies used open source solutions in their DevOps portfolios, the more effective the DevOps function was. More specifically, the study reported that among companies with at least 60% of their DevOps portfolio as open source, a full 54% had reached the “fully deployed” DevOps state, with all of their development occurring via DevOps models.

By comparison, only 30% of the surveyed companies that used less than 60% of open source tools in their DevOps portfolios had reached this state of DevOps adoption. Clearly there’s a link between open source use and DevOps success. Given these results, insurers should focus on the benefits of supporting and encouraging their DevOps groups to embrace the open source community.

It’s a dated but still persistent view: Participating and contributing to the open source community means developers are giving away their time by creating and contributing intellectual property (IP) that may benefit others outside the organization. However, the truth of the matter is participating DevOps engineers, developers, analysts, etc. are often fixing bugs and making improvements to code libraries other than their own but that can have value for their own DevOps efforts.

The very definition of open source –software for which the original source code is made freely available and may be redistributed or modified–makes it fertile ground for skills and solutions improvement. Additionally, that process of analyzing and repairing code represents some serious skills development. It’s the kind of development skills that can be difficult to obtain by just working on in-house applications and platforms–which are often proprietary and dated–lacking modern coding techniques.

Since open source literally means a developer and/or organization has the ability to make the code fit their needs however they see fit–they control their own version of the product that may diverge from the original open source project–the opportunity for DevOps solutions improvement is substantial. Moreover, any DevOps related IP a developer creates and contributes is not lost and is certainly not stolen–the IP can be used directly by the developer and that developer can continue to benefit from the IP of other developers on a gratis basis.

Utilizing DevOps solutions from the open source community can be both time and cost effective and can be a positive boon to organizations. While some insurers may not knowingly allow open source code in core systems or applications, its use in a DevOps ecosystem is another matter. That’s especially true since DevOps is a newer and less mature IT function that requires new tool, process and solutions development. Leveraging open source solutions can expedite that process. In fact, many of the key DevOps tools used today either are or started as open source solutions for DevOps problems. One would be hard pressed to find a DevOps development stack–from building/developing to monitoring–that didn’t use at least one open source tool as part of the stack.

Often the fear or apprehension to using open source libraries (for DevOps or anything else) is that anyone could have written it, thus its quality is or could be sub-par. While in some cases this can be true, the same holds true for closed source proprietary software, as many insurers could attest. Simply put, open source tools and libraries are worked on by developers of the exact same caliber–if not the exact same people–who work on closed source proprietary tools and libraries. The only difference is there are often less people involved with proprietary solutions development. And since there are relatively few proprietary DevOps solutions in the marketplace to choose from, open source should be considered a viable channel for DevOps solutions.

Even if there were more choices for proprietary DevOps solutions, the financial savings involved in combining open source solutions with DevOps can be significant. Importantly, open source solutions for DevOps are particularly useful when the right solution for a problem has yet to emerge, almost a given in a maturing DevOps ecosystem. Rather than rushing out to buy something that promises to fix the problem–or writing something themselves–DevOps developers can find open source solutions and use those to experiment, test and otherwise isolate and identify the true nature of and solution to a DevOps challenge.

Another reason DevOps groups should avail themselves of open source techniques and tools is the fact that the tools and techniques available for DevOps–proprietary off the shelf and built inhouse–are still not quite there yet. The tools available are almost always missing something, resulting in developers at many organizations spending most of their time–and the organization’s money–trying to develop fully functional solutions from the ground up.

More often than not, the resulting tool or solution is never as complete or well-built as the open source tool or solution that already exists. Most organizations would be better served tasking their developers with scouring open source libraries, identifying the “best fit” DevOps tools and then spending the time required creating the updates and improvements to the tools that have already been mostly built, saving time and money.

Finally, there are lots of DevOps staff out there who participate in the open source community–in their spare time anyway, or have done so while working on previous projects. That means hiring DevOps staff with open source experience is a shortcut to potential open source techniques and tools. These are people that can hit the ground running by bringing their open source experiences to bear while they’re getting up to speed on the proprietary work they may be assigned. Considering these benefits, it’s past time for DevOps groups at insurers to dive into the open source waters.

— Tanner Gibson

November 6, 2019
The Value of Commercial Open Source
Adhering to the open source definition enables a large, passionate community to collaborate and share their work, insights and innovations on a given OSS project. Companies working in commercial open source add to that value by turning what may look to enterprises like “raw material” into whole product.

These combined efforts serve to improve products, while continuing to protect customers from the stranglehold of proprietary vendors. Beyond just open source, adherence to open specifications (such as CMIS in the content services space) and implementing open RESTful APIs provides a treasure trove to developers that they can quickly and efficiently build upon to add new innovative functionality into the solutions they craft to meet specific business needs.

When vendors employ open thinking at all these levels (open source, open standards, open APIs), there are commercial benefits across the board. The enterprise customer has a hedge against lock-in, can benefit from the innovation across the community, and, perhaps most importantly, can quickly and nimbly respond to changing market conditions while relying on the robust software quality commercial open source provides.

James Dixon, Pentaho Founder and CTO, has described the approach of commercial open source as being akin to a Bee Farm. Bees can, of course, create honey on their own in the wild, but most of us buy honey that comes from a farm. The beekeeper’s job is to create conditions that attract the bees in the first place, and then (bravely!) collect the resulting honey before refining, packaging and distributing in a way that appeals to consumers. This system of open collaboration adds value throughout the supply chain, from the bee to the beekeeper to the customer at the breakfast table.

Likewise, in commercial open source, the vendor takes on the role of beekeeper, creating conditions in a community that attract and retain contributors to help create a better product for all in a win-win-win scenario:
- The community gains open source software they can use for their own purposes. This software has more functionality and more resources than a ‘pure’ open source project could provide. In this way the community profits directly from the company and its customers.
- The customers gain higher quality software at a better price. The customers profit from the open source community’s ability to produce high-quality software.
- The company gains by growing and increasing its valuation as a result of keeping both sets of consumers content.
I can’t think of a more perfect metaphor for the role of commercial open source. In fact, as a nod to James’s insight, years ago the Alfresco user community named their organization the “Order of the Bee.” What a complimentary match for our company, which, after all, is named after an open air, outdoors experience!

The open source mindset provides areas of opportunities along the entire supply chain, from creation of software to products and services on which the software runs. Just as bees are integral to honey, open source is integral to today’s digital business environment.

About the Author / Chris Wiborg

Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.
December 28, 2017