DEV Community: Kat Keilty

Why Enterprise Should Embrace Open Source

Kat Keilty — Mon, 30 Mar 2026 01:28:09 +0000

Open Source Is Not a Charity. It's a Competitive Edge.

Most executives hear "open source" and think: free software made by volunteers. That assumption leaves money on the table.

Open source is a global pool of production-grade software, maintained by thousands of contributors, that your team can use, extend, and build on without a vendor contract. The question is not whether it matters to your business. It is whether you are using it strategically, or spending development dollars on a stack of paywalled tools just to make things work.

The Contribution Economy

When a company contributes to an open source project, you are effectively commissioning development:

Bug fixes your team needs
Features aligned with your roadmap
Integrations with your existing stack

Every other organization using that same project is doing the same thing. Which means they may be building features you did not know you needed.

The strategic move is not just to consume open source software. It is to contribute. A small engineering investment in a project your team depends on pays back through roadmap influence, early access to fixes, and visibility in the developer community you recruit from.

The Accessibility Stack

Three tools make open source practical for teams that are not full of engineers.

Docker removes the single biggest complaint about open source software: "it doesn't work on my machine." Docker packages any application with everything it needs to run, so your team can deploy a tool in minutes instead of spending a day on setup. You do not need to understand it deeply to benefit from it. You need one person who does.

Git is version control: a way of tracking every change made to a file, by whom, and when. Most people associate it with code. It applies equally to data pipelines, configuration files, and documentation. The mental model it teaches (work in branches, merge when ready, roll back when wrong) is a thinking skill, not just a technical one.

LLMs as a learning layer. Tools like Claude or ChatGPT are not replacements for understanding. They are on-ramps. A non-developer who hits an error in an open source tool can paste the message into an LLM and get a plain-language explanation and a fix in seconds. The feedback loop that used to take days now takes minutes.

Finding What Exists Before You Buy

Before your team renews a SaaS subscription, check two places.

Linux Foundation (linuxfoundation.org/resources/open-source-guides): Guides on why, how, and when to adopt open source at an organizational level.

OpenAlternative (openalternative.so): A curated directory of open source alternatives to popular paid tools. Search what you are currently paying for. There is often a production-ready equivalent that is actively maintained.

Who Is Actually Building Linux

This is where the "volunteer project" assumption falls apart completely.

Over 84% of Linux kernel commits in 2025 came from paid corporate developers, across more than 1,780 organizations. This is coordinated infrastructure investment, not charity.

Intel: Top contributor by changesets in 2025, nearly double second-place Google
Red Hat (IBM): Consistent top-3 contributor, historically held the number one spot
Google: Nearly 1 in 8 patches handled by Google developers; Android, Google Cloud, and Chrome OS all run Linux
Oracle: Top contributor to kernel core components across multiple recent releases; cloud infrastructure and database performance
Huawei: 8.9% of changesets in kernel 5.10; consistent top-5 since
Samsung: Mid-tier contributor since at least 2013; Android devices and Tizen OS
Meta: 1 in 8 patches handled by a Meta maintainer in kernel 6.15; data center infrastructure running billions of users
AMD: Active GPU and CPU driver contributor each release cycle; 30% performance gains for legacy AMD GPUs in recent kernel
Microsoft: Hyper-V and virtualization code; Azure cloud VMs require Linux kernel compatibility
NVIDIA: Rust-based GPU driver jointly developed with Google and Arm; GPU drivers for AI and ML workloads

The companies shaping your cloud infrastructure, your devices, and your AI tools are doing it through open source. The question is whether your organization is paying attention.

Stop Guessing.

Kat Keilty — Sun, 29 Mar 2026 05:06:16 +0000

Most organizations have the tools. They have the certifications. They have the right intentions. What's missing is the structure to make it all work together.

Work gets dropped because no one owns it. Problems fester because no one's measuring. Projects drift because the plan was a slide deck nobody opened after kickoff. People show up to status meetings, say what sounds good, and leave with no more clarity than when they walked in.

It's not a people problem. It's a visibility problem.

The Tools Are There. Nobody's Using Them.

Every organization has a project management methodology. A lot of people have the certification to prove it. PMBOK on the shelf. PMP after the name. Risk registers, RACI charts, communication plans -- built during the course, forgotten after the exam.

The deliverables get produced. The plans get filed. And then the team goes back to running on Slack threads, tribal knowledge, and whoever is loudest in the room.

That's not project management. That's project paperwork.

Real project management is a working document, not a submission. A RACI that people actually reference when accountability gets fuzzy. A risk log that gets opened when something smells wrong, not after it explodes. A schedule that reflects reality and gets updated when reality changes.

The tools work. The structure and discipline to keep using them after the kickoff meeting is what most teams skip.

Data Isn't a Dashboard. It's a Decision.

The same pattern shows up with data. Metrics get built, reports get scheduled, dashboards get shared. And then nobody looks at them until something goes wrong -- and even then, the question is usually "who do we blame" not "what do we fix."

Data's job is to tell you something is broken before it becomes a crisis. To show you where effort is going versus where results are coming from. To cut through the noise of everyone's competing narratives about how things are going.

That only works if someone is actually looking, asking the right questions, and willing to act on what they find. Measurement without follow-through is just overhead.

Collaboration Means Working Together, Not Checking In

Status meetings where everyone reports what they did last week are not collaboration. They are performance. The project exists on a shared stage for fifteen to forty-five minutes and then everyone goes back to their silos.

Real collaboration means the plan is a shared object -- visible, current, and owned across the team. It means problems get raised before they become blockers. It means fierce accountability, with owners who stand behind their team..

When project management and data are treated as team infrastructure instead of afterthoughts, something shifts. Work becomes legible. Decisions get made faster. Problems surface early, when they're still cheap to fix.

The Gap Is Execution

Strategy is easy. Everyone has a vision. The gap is almost always between what was decided and what actually happened -- and that gap lives in the space where structured execution should be.

Three things close it:

A plan that stays alive -- owned, updated, and used as a decision-making tool, not a kickoff artifact
Data that drives action -- metrics tied to outcomes, reviewed consistently, and connected to what changes next
Accountability that's structural -- built into the process so it doesn't depend on one person chasing everyone else

This isn't complicated. It's just discipline. And discipline, applied consistently, is what separates teams that execute from teams that are always almost there.

SQL: The Foundation you Need

Kat Keilty — Sun, 29 Mar 2026 04:22:30 +0000

SQL Is a Literacy Skill. Treat It Like One.

If you had a MySpace or other early social media profile, you already know this pattern: the default was not enough, so you figured out just enough HTML and CSS to make it work. No tutorial. You broke it, fixed it, and moved on. SQL is the same moment, applied to data.

The Low-Code Ceiling

No-code and low-code tools work until they do not. A filter that almost does what you need. A report that is one join away from useful. A dashboard you export to Excel because there is no other option.

That is not a tool problem. It is a vocabulary problem. SQL is the vocabulary.

What You Actually Need

Four commands cover the majority of non-developer data work:

SELECT: choose what to return
WHERE: filter to what matters
JOIN: connect tables with a shared key
GROUP BY: summarize

Learn CASE and you will ascend to Guru status in non-tech groups.

Start with SQLiteOnline or W3's SQL Tutorial. Paste errors into an LLM for a free tutor. There is no expensive course between you and functional.

Why It Compounds

Once you understand how data is structured: rows, columns, relationships, every tool gets clearer. Why reports break. Why dashboards are slow. What your developer is actually saying.

SQL is not a developer skill any more than HTML was a designer skill in 2004. The floor has moved. People who cleared it are not fighting the tools everyone else finds frustrating. Excel is useful; it is also where repeatable work goes to get rebuilt from scratch every quarter.

Learn it the same way you learned everything else: mess around until it works.

Developing Human-First Solutions

Kat Keilty — Sun, 09 Nov 2025 14:27:10 +0000

When developing solutions, it’s easy to get distracted by shiny new tools. A sleek interface, a trending platform, a feature-rich dashboard, all tempting shortcuts to progress. But here’s the truth: tools are irrelevant without purpose, process, and people.

The Tool Is Not the Strategy

Choosing software is not a strategy. It’s a tactic, one that only works if it’s embedded in a well-defined process. Whether you’re hiring, building workflows, or designing systems, the real question isn’t “What tool should we use?” but “What problem are we solving, and how will we sustain the solution?”

A poorly defined process will fail in any tool. A well-defined process will succeed in almost any. That same process can also adapt and scale.

Purpose Before Platform

The most successful systems aren’t built around tools. The requirements gathering phase, where people get together and define what they need, that is the most critical step. When roles are defined, goals are shared, and processes are mapped, the tool becomes secondary. It’s a vessel, not the engine.

Once requirements are clear- technology can be mapped. Tests can run, collaboration can launch. Even with all of the LLM, AI, Machine learning & Algorithmic tools at our disposal- if they aren't given clear requirements- they can't produce results.

Before you invest in a platform, invest in understanding:

What outcomes you’re driving
What resources you’ll need to maintain it
Who will own it when the launch hype fades
Maintenance Is the Missing Metric

Data governance & Maintenance planning aren’t glamorous, but it’s what separates sustainable systems from digital debris.

Hiring for Systems, Not Software

When hiring, don’t just look for tool proficiency. Look for systems thinkers, people who understand how processes connect, how decisions ripple, and how to build for longevity. A candidate who can learn a tool is valuable. A candidate who can question whether it’s needed is indispensable.

The Real Competitive Edge

In the end, your competitive edge isn’t the software you use. It’s the clarity of your process, the strength of your team, and the discipline of your maintenance.

Tools don’t build systems. People do. The best systems are built with purpose, not plugins.

Quality in the Age of Acceleration

Kat Keilty — Sun, 09 Nov 2025 09:10:57 +0000

When technology evolves faster than we can refresh our feeds, the concept of quality often feels like a moving target. We chase speed, scale, and novelty, but what happens to the quiet discipline of doing things well?
For professionals in business transformation, operations, and process improvement, this isn't just a philosophical question. It's a strategic one.

The Myth of Speed vs. Quality

There's a persistent myth that speed and quality are mutually exclusive - that to move fast, you must break things. But the most resilient systems, the most beloved services, and the most trusted organizations are those that balance velocity with intention.
Quality isn't the enemy of innovation. It's the foundation of it.

Iteration Is the New Perfection

Gone are the days when perfection was a prerequisite for release. Today, iteration is the norm. Agile workflows, continuous feedback loops, and digital platforms have redefined how we deliver value.
But iteration without reflection is just noise. Quality emerges not from how often we ship, but from how thoughtfully we learn.

Technology as a Mirror

Technology doesn't just solve problems , it reflects our values. The phrase "Garbage in, garbage out" has never been more relevant. When needs are clearly defined and well provisioned, systems often- somewhat surprisingly -do what they were meant to.
Digital transformation is not just about automation. It's about clarity. You can't automate a process you can't define.

The Quiet Power of Craft

In the rush to optimize and scale, the collaborative efforts of professionals are more important than ever. A tool is only as effective as its upkeep. Continued success requires governance. Something perfectly serviceable can become unusable through neglect, poor planning, or lack of ownership. Something revolutionary can be reduced to a low-priority admin backlog.

Craft isn't about perfection. It's about care, and care scales better than chaos.

In the end, quality isn't a checkbox. It's a mindset. In a landscape that never stops moving, it might just be our most enduring competitive edge.