Open Source(start-ups too) vs Enterprise Engineering Notes from an Engineer Who's Lived Both Lives

I’ve written code in the middle of the night with zero supervision and shipped tools that helped teams ship faster at startups moving at breakneck speed. I’ve also waited three weeks for legal to approve a single line change to a PowerShell script. This is not a rant. This is a field report.

This is the duality of the engineer who lives in both worlds: open source and enterprise.

Spoiler: It’s probably why .NET devs end up a little stuck-up, while Golang engineers are bouncing around with minimal Dockerfiles and a grin.

Speed: The Race vs The Process

In open source and fast-paced startups, speed is survival. You build fast, test fast, ship fast. If something breaks, the community (or your tiny team) catches it. CI pipelines run in seconds, releases happen on impulse.

You might start writing a tool for fun at 10PM and be testing it in prod the next morning. You’re shipping value constantly. There’s freedom in it.

In the enterprise? There's a process for everything. And a meeting to discuss the process. Code goes through design reviews, threat modeling, multiple approvals, and then gets merged into a staging branch that only deploys on Wednesdays assuming the CAB (Change Advisory Board) signs off. Even a one-line environment variable update can take two sprints.

Ownership: Makers vs Maintainers

Open source is personal. You write code that solves your pain, then find out 100 other people had that pain too. You maintain it because you care. You triage issues during lunch breaks. You merge PRs while waiting for your flight.

You're not blocked by bureaucracy. You're blocked by your energy level or curiosity.

In enterprise, you inherit legacy code that predates your team. You maintain things out of duty, not love. And you rarely get to throw things away. Every decision has a stakeholder. Sometimes three. Sometimes legal. Sometimes the CIO who still thinks Excel is a database.

Tooling: Latest and Greatest vs Battle-Tested and Budget-Approved

Open source is where I first touched Rust, Bun, esbuild, Wails, and Tauri. It’s where Dockerfiles are tiny, scripts are clean, and everyone uses the CLI like an extension of their brain.

It’s also where I learned why tools work the way they do. The fundamentals. Because there’s no "cloud magic" to lean on. You build and break things yourself.

In the enterprise, I’ve seen Jenkins pipelines that need to be restarted twice before they work. Internal documentation refers to tools no one uses anymore. And every tool goes through procurement, security review, finance approval, and sometimes board-level clearance.

You don’t just spin up a new service. You raise a ticket, build a business case, and wait for a budget cycle. Azure and AWS are configured for you already, but you rarely touch the core infra.

Pros: You use tools that are supported, licensed, and tested for scale.
Cons: You forget the fundamentals. You live in vendor convenience mode.

Security: Vibes vs Frameworks

In OSS, security is sometimes a pinned issue. You hope contributors care. You might integrate Dependabot or write a GitHub action to scan secrets.

There’s a lightness to it. You’re aware of risks, but you’re also just trying to get things working. You prioritize momentum. Sometimes recklessly.

In enterprise, there's a security team, a compliance framework (hello ISO, SOC2, NIST), and penalties for non-compliance. You do quarterly audits. You rotate secrets like clockwork. And you learn the hard way that forgetting to tag a security group properly can trigger an email chain involving six departments.

Impact: Global vs Local

In open source, impact is wide. Your library might power 10,000 apps. You might get emails from random devs in Uruguay saying thanks. You become part of a global dev conversation. You feel seen.

In enterprise, impact is deep. You improve a workflow and save a department 100 hours a month. You automate a compliance process and save the company $80k in fines. You’re solving business problems in a way that matters to people’s actual jobs.

Pros: Enterprise changes business. OSS changes developers.
Cons: OSS lacks long-term feedback loops. Enterprise often buries your work under layers of abstraction.

Culture: Explorers vs Protectors

Golang engineers tend to be light, curious, and allergic to bloat. They love tools that "just work". You see them shipping microservices with Dockerfiles so lean it hurts. They're fun because their work doesn't have a cage around it. They know what the Linux box looks like under the cloud.

.NET engineers? Often live in a world of IT policies, LOB apps, 10-year-old ERPs, and corporate identity policies. They're not stuck up because they want to be. They're stuck up because their systems are.

They can't just docker run something new. It has to go through approval, compliance, and sometimes Active Directory. That's not freedom. That's corporate purgatory.

The Engineer in Between

I don’t believe one is better(cap I believe open source is better). I believe engineers who live in both worlds become dangerous in the best way.

You learn to ship fast and document clearly.
You learn to write flexible code and design for auditability.
You understand hacker speed and enterprise scale.

Open source keeps you sharp. Enterprise keeps you structured. One teaches you how to build from scratch. The other teaches you how to operate at scale.

Love open source. Respect enterprise. Know when to push, and when to write a risk memo.

I’m not trying to romanticize either side. I’m just saying: if you ever get the chance to do both, take it. It changes how you think. It sharpens how you build.

Oche signing out.

(But I'll probably push something to GitHub later tonight, and definitely write an approval request on Monday morning)