Against This Manifesto 🚫📄

[francescobianco]

This issue exists as an open space for anyone who disagrees with the DevOps Manifesto, partially or fully.

DevOps is a broad and evolving discipline, and critical perspectives are essential to keep the conversation honest, balanced, and technically grounded.
If you believe the manifesto is incorrect, incomplete, misleading, or ideologically biased — this is the right place to express it.

🎯 Purpose of This Issue

• To collect critiques, disagreements, and opposing viewpoints
• To give space for experienced engineers to share their concerns
• To avoid scattering negative feedback across multiple issues
• To help refine or challenge the ideas expressed in the manifesto

🗣️ How to Contribute

Feel free to comment with:

• Your technical objections
• Your philosophical disagreements
• Your experience-based critique
• Your concerns about terminology, culture, or industry trends

Short comments, long essays, rants (within reason), and sharp technical feedback are all welcome — as long as they remain respectful.

💬 Why This Issue Exists

A manifesto is only meaningful if it can survive scrutiny.
This space ensures that all voices — including dissenting ones — can be heard, so the discussion remains open and healthy.

Thank you for taking the time to share your perspective.
Your feedback, even if critical, helps strengthen the conversation around what DevOps really is — or what it should be. 🛠️🔥

[francescobianco]

As reply for: #1 (comment)

Thank you @osevan for taking the time to share your perspective — especially with your 22 years of Linux kernel experience.
Your concerns are absolutely valid, and in fact they are one of the core reasons why this manifesto exists.

The manifesto is not defending the industry-created, cost-cutting version of “DevOps” you describe.
On the contrary:

We fully agree that DevOps has been abused and reduced to a label applied to roles without true engineering skills.

For us, DevOps is — first and foremost — software engineering:

• writing solid, benchmarked, reliable software
• understanding the underlying systems
• knowing how infrastructure, performance, memory, page cache, and I/O behave
• designing software that evolves correctly
• avoiding the “cloud operator with no engineering background” anti-pattern

Only after that comes DevOps as a mindset, culture, and discipline.

If there is no real engineer underneath, the whole DevOps story is just an empty box — and this is exactly what we want to fight.
Not to remove engineering — but to bring engineering back to the center.

So your comment does not contradict the manifesto — it actually reinforces its purpose:
to contrast the misuse of the term DevOps and restore technical competence at every layer, from development to infrastructure.

Thank you again for sharing your point.
Your input helps us strengthen the message.