In my previous articles we discussed challenges, stressors and common bad practices that software projects may face. Almost every software system evolves through pressure, unexpected failures, design mistakes, governance gaps, and the constant friction between what users need and what the architecture can support. Now when we talk about antifragility in software, we talk about a pattern that emerges when a project becomes stronger because of stress, not despite it. We are not talking about the projects that avoided disruption but the ones that had to respond to it.

Today I want you to join me to a journey down to memory lane. Together we will revisit the evolution of five open source software projects. During their development history, these projects went through several crises. These crises ranged from security incidents to governance disputes to architectural transitions. Each of these projects used the pressure to clarify its direction, strengthen weak processes, or rework assumptions that no longer fit. And that is exactly why they make very good antifragility cases.

PostgreSQL

During its transition from an academic research project into a community-led database the original codebase had structural limitations and slow development cycles. As users grew frustrated with stalled progress, the community reorganized itself around clearer governance and more incremental releases. This shift created a culture that values careful engineering and transparent decision making, shaped directly by early stress and uncertainty.

Later, PostgreSQL encountered pressures from large-scale deployments and competition from established commercial databases. These challenges pushed the project into developing advanced indexing, replication, and extensibility features. Instead of weakening the system, these demands clarified architectural priorities and led to the robustness PostgreSQL is known for today. The database grew stronger because real-world stress revealed the next set of capabilities it needed to support.

If you want to learn more about PostgreSQL’s challenges and evolution here are some useful articles:

• Inside PostgreSQL: An Open Source Project’s Growth, Governance, and Future. Q&A with Joe Conway and Robert Treat

• The History of PostgreSQL: How Postgres Became the World’s Leading Open Source Database

• Looking Back at Postgres (arXiv)

• Breaking With Filing Cabinets: The History of PostgreSQL

Python

Python’s most visible stressor was the long transition from version 2 to version 3. The incompatibility created confusion and fragmentation across ecosystems and organizations. Teams struggled to maintain dual codepaths, and migration resistance became a recurring point of tension. This forced the Python community to improve its governance, clarify long-term roadmaps, and invest in modernization incentives. The project matured through the pressure of reconciling past decisions with future needs.

Performance limitations created a second persistent stressor. Developers often compared Python unfavorably to languages with stronger throughput characteristics. Instead of destabilizing the project, this led to the creation of PyPy, Cython, better packaging standards, and work on concurrency models like asyncio. Each response strengthened Python by acknowledging constraints and adapting around them rather than denying their existence.

If you want to learn more about Python’s challenges and evolution here are some useful articles:

• Python’s Tale. Command Line Heroes (podcast by RedHat)

• YCombinator: Breaking the Snake: How Python went from 2 to 3

• Inside Python’s new governance model

OpenSSL

OpenSSL encountered a defining stressor through the Heartbleed vulnerability. The incident exposed long-standing governance and funding gaps and brought global attention to the fragility of widely used cryptographic infrastructure. Instead of collapsing under scrutiny, the project responded with new audits, better testing practices, and increased transparency. The shock created momentum for reforms that had been needed but repeatedly deferred.

The creation of LibreSSL introduced another challenge. The fork publicly highlighted technical debt and maintainability issues inside the codebase. Rather than fragment the ecosystem, the pressure motivated the OpenSSL team to simplify components, modernize the API, and revise development processes. The project became sturdier because the crisis clarified exactly where technical and organizational reforms were required.

If you want to learn more about OpenSSL’s challenges and evolution here are some useful articles:

• OpenSSL after Heartbleed

• Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL

• LibreSSL languishes on Linux

• LibreSSL crypto library leaps from OpenBSD to Linux, OS X, more

Git

Git originated as a response to the sudden loss of BitKeeper, a proprietary tool crucial to Linux kernel development. The abrupt constraint forced a rapid exploration of new ideas around distributed version control, integrity, and performance. Instead of weakening the development workflow, the stress catalyzed a fresh design that solved long-standing coordination problems in large distributed teams. Git’s early identity was formed directly by the need to operate without a central point of failure.

As Git grew, the project confronted usability challenges and workflow confusion among new adopters. Problems with rebasing, merging conflicts, and branching models exposed gaps in documentation and tooling. These pain points pushed maintainers and the community to improve safety features, refine commands, and evolve best practices. Git became more robust because user struggles consistently revealed which areas required clearer patterns and better support.

If you want to learn more about Git’s challenges and evolution here are some useful articles:

• A Git Origin Story

• Short(-ish) article on how Linus Torvalds came up with git

• Git turns 20: A Q&A with Linus Torvalds

• History of Git (GitKon 2021 Keynote)

React

React’s antifragility first surfaced in the licensing controversy surrounding its PATENTS file. Developers questioned the long-term implications of adopting the library, and the pushback challenged Facebook’s governance assumptions. The maintainers used this tension to revise licensing choices and communicate more openly about project stewardship. The event helped React grow because it forced clearer boundaries around trust, communication, and community expectations.

React’s architectural evolution created a second stressor. The introduction of hooks and the shift toward a more functional model presented conceptual and migration difficulties. Early adopters confronted unfamiliar patterns, and many struggled with mental models for state and lifecycle management. These pressures encouraged the ecosystem to refine documentation, standardize patterns, and simplify teaching materials. React strengthened its consistency because the friction revealed where conceptual clarity was lacking.

If you want to learn more about React’s challenges and evolution here are some useful articles:

• React and Patents

• Facebook drops efficient infringement clause from its React software license

• 4 Lessons from the ‘React Patent License’ Controversy

• A lawyer’s review of React’s license

Final Thoughts

The projects discussed here did not follow a predetermined path toward resilience, or antifragility for that matter. They were shaped by disruptions that forced clearer governance, more deliberate architectural choices, and better alignment between the community and the long-term direction of the software.

There is value in studying such cases (and the past in general) because they reveal how stress can clarify priorities and expose unrealistic assumptions. They also remind us that growth often follows discomfort. When a system absorbs a shock and uses it to improve, it offers a practical example of how technical, social, and organizational layers interact. As engineers and leaders, the question is not how to avoid stress but how to design environments that respond to it with learning instead of fragility.

In every choreography harmony is not born of numbers, but of intent. Whether a single dancer moves in solitude or a hundred glide across the stage, the essence of choreography lies in the invisible thread that binds rhythm, movement, and purpose. Scale does not define the outcome. A duet can echo with the same emotional gravity as an ensemble, provided each gesture serves its purpose.

Harmony, in this sense, becomes the equilibrium between precision, expression and discipline. It is the point where the dancers’ individuality dissolves into collective coherence, where the choreography transcends coordination to become communion.

A choreographer’s true pursuit is not magnitude but alignment. The end goal is not to fill the stage, but to fill the moment! To turn time, motion, and intention into a collective breath. For when harmony is achieved the stage, no matter its size, becomes infinite.

Corporate vs Startup Culture

The contrast between startup and corporate cultures is often painted as agility versus structure, creativity versus protocol, passion versus process. Yet this is a false dichotomy. The startup, with its frenetic energy and fluid hierarchies, thrives on motion: ideas emerging raw, unfiltered, evolving in real time. The corporation, by contrast, consists of systems. Each process honed to preserve consistency, each decision guided by precedent. One dances to improvisation, the other to choreography. But both are, in essence, searching for harmony: that elusive alignment between people, purpose, and performance.

Where startups risk chaos, corporations risk inertia. One may falter from exuberance, the other from complacency. Yet within this tension lies the possibility of synthesis. A mature startup aspires, eventually, to the operational elegance of a corporation. A wise corporation rediscovers, cyclically, the restless spirit of the startup to remain alive. The most antifragile organizations are those that understand when to lead with rhythm and when to lead with structure. When to let the dancers find the beat, and when to steady the tempo.

Thus, startup and corporate are not opposing forces but complementary movements within the same choreography of innovation. The scale of the team, like the size of a stage, does not determine the grace of the performance. What matters is coherence. A shared rhythm that allows invention and discipline to coexist. In the end, both cultures are striving toward the same goal: a harmony of purpose where creativity finds its frame and structure finds its soul.

The Cathedral + The Bazaar!

In The Cathedral and the Bazaar, Eric S. Raymond illuminated a profound tension in how creation unfolds: the cathedral, meticulously designed behind closed doors, versus the bazaar, alive with open exchange and constant iteration. The true difference, he observed, was not structure but visibility. In the cathedral model of closed-source development, the process is veiled. The work of a few, revealed only when complete. The bazaar, by contrast, thrives in the sunlight of participation: transparency becomes both a mechanism of quality and a philosophy of trust.

In the context of modern organisations, this distinction resonates far beyond software. Traditional corporate cultures often mirror the cathedral. Teams working in isolation, information flowing upward rather than outward. Startups, meanwhile, embody the bazaar’s ethos: porous boundaries, open dialogue, and collective sense-making. Yet the emergence of inner source transforms this binary. By opening the code within an organisation, making it visible to all regardless of team or department, the cathedral’s walls dissolve without sacrificing its architectural coherence. Visibility no longer threatens control; it enhances alignment.

In such an environment, harmony is no longer the privilege of small, agile teams. When code, ideas, and intent are shared across an organisation, silos fade into choreography, movement coordinated not by hierarchy, but by shared rhythm. Inner source, then, becomes a synthesis where the stability of the cathedral meets the openness of the bazaar. In this convergence, visibility is not a risk to be managed, but the very light that allows collaboration, trust, and creativity to flourish in unison.

Waterfall & Agile is the new Yin & Yang

As organisations evolve, they often traverse the same bridge that connects Raymond’s cathedral and bazaar. In the early days of a startup, energy resembles the bazaar: a cacophony of ideas, swift decisions, and porous hierarchies. Everyone sees the work unfolding. Visibility is total, ownership is collective, and mistakes are treated as steps in the dance rather than flaws in the score. Yet, as the organisation grows, the very chaos that once fuelled innovation begins to strain its rhythm. Processes solidify, structures emerge, and a cathedral slowly rises from the noise. The challenge is to preserve the vibrancy of the bazaar within the quiet discipline of the cathedral. To maintain harmony as the stage expands.

A similar philosophy underpins the evolution from pure Agile or pure Waterfall to a hybrid approach. Waterfall, like the cathedral, is deliberate: a design drawn in advance, its beauty found in precision and predictability. Agile, like the bazaar, is fluid: it values learning in motion, discovery through iteration. Each has its virtue, but also its constraint. When combined (carefully, consciously) they can form a methodology that acknowledges both the need for foresight and the inevitability of change. The hybrid Agile–Waterfall model, then, becomes an architectural metaphor for organisational maturity: the scaffolding of the cathedral supporting the improvisation of the bazaar.

For startups in transition, this hybridisation is not just methodological but existential. Scaling brings weight: more people, more dependencies, more voices. To sustain innovation at scale, an organisation must manage its dual identity. The restless spirit of a startup and the composure of a corporation. The hybrid model allows that synthesis. Agile frameworks empower teams to adapt locally, respond to users, and innovate at the edges. Waterfall structures coordinate the larger machinery, aligning delivery, compliance, and governance. It is a system that learns as it plans but also plans as it learns.

Ultimately, hybrid project management embodies the same principle that unites choreography, architecture, and open collaboration: harmony through visibility and balance. It accepts that growth need not mean abandoning agility, nor that discipline must suppress creativity. A truly evolving organisation does not choose between cathedral and bazaar, or between Waterfall and Agile. It learns to dance between them. In this sense, the organisation finds its enduring rhythm: structure with transparency, purpose with adaptability, and innovation sustained by design.

References

• Zaleski M. Traversing Hybrid Project Management: The Bridge Between Agile and Waterfall. Toptal. Published 2025. Accessed November 14, 2025. https://www.toptal.com/project-managers/agile/hybrid-project-management-a-middle-ground-between-agile-and-waterfall

• Harvard Business School Online. Startup vs. Corporate Culture: What’s the Difference? Published August 31, 2023. Accessed November 14, 2025. https://online.hbs.edu/blog/post/startup-vs-corporate-culture

• Devologyx. Startup Culture Versus Corporate Culture: Which Is Best for You? Published 2024. Accessed November 14, 2025. https://devologyx.io/startup-culture-versus-corporate-culture-which-is-best-for-you/

• Founders Network. Startup vs. Big Company: Which Is Right for You? Published 2024. Accessed November 14, 2025. https://foundersnetwork.com/startup-vs-big-company/

• Raymond ES. The Cathedral and the Bazaar. Published 2000. Accessed November 14, 2025. http://www.catb.org/~esr/writings/cathedral-bazaar/

A software startup is, in its essence, a hypothesis. A tentative combination of technology, market timing, and belief in a user need that might not yet exist. It carries the posture of innovation, but beneath that, it is a fragile construct. A prototype of a business model wrapped around assumptions waiting to be tested. The product is a manifestation of these assumptions, an interface layered over uncertainties about usage, adoption, pricing, and retention. Before it is a company, it is a question.

But this question is posed to a market that is not static. It is dynamic, multi-dimensional, and entangled with variables far beyond the startup’s scope or control. Economic conditions shift. Legal frameworks evolve. Competitors pivot or collapse. Technical landscapes change rapidly. Even the internal rhythms of decision-making can create fault lines. Each of these vector, business, software, legal, economic, can become a source of pressure. In time, some of these pressures manifest as crises. Whether or not they become fatal depends on the antifragility of the startup, or to put it in another way, how many “skeletons has in its closet”.

The lifecycle of a startup

This graph originates from Silicon Valley Bank’s article titled “What are the three stages of a startup?” [1]. I referenced these stages during my talk at the InnerSource Summit 2024 [2] international conference to describe the evolution of InstaShop, the company I currently serve, as it progressed from startup to acquisition by a publicly traded company. InstaShop successfully gone full-circle, passing through each of the three stages described. Not all startups, however, have this luxury. In fact, 90% or more of them, fail!

The early stage of a startup does not begin with scale but with a question. There is a kernel of an idea, sometimes born out of persistent frustration, other times from a moment of clarity, suggesting that a product or service could be viable under the right conditions. This phase involves defining the problem and shaping the first response. The team is small, risk is high, and most commitments are personal rather than formal. Resources tend to be limited and improvised. It is in this environment that the initial product takes form, often alongside the first attempts to raise funding. Support commonly comes from friends, family, or personal savings. Accelerators may enter the picture once the team has built something more tangible than an idea.

The venture-funded stage begins with the arrival of Series A capital. At this point, the focus shifts from potential to performance. Investors come with expectations, and the business must demonstrate its ability to grow. The company is now expected to scale its operations with a clear plan, a structured team, and a functioning sales strategy. Founders take on new responsibilities, often moving away from execution and toward leadership. As the company grows, it must remain responsive to changing conditions and willing to adapt. Each funding round depends on the outcomes achieved during this stage. This is where theoretical value must be proven through practical results.

In the late stage, the startup increasingly takes on the structure and responsibilities of a mature company. Financing stabilises, and revenue is no longer speculative. Strategic expansion becomes a central focus. The company may consider entering new markets, expanding its product offerings, or exploring acquisitions. Fundraising remains important but is now driven by demonstrated performance. Founders often face the decision of whether to continue leading or begin planning an exit. At this point, the market that once challenged their idea may now be prepared to acquire it. Yet, even in this advanced phase, the core question persists: how to build a business that does not just endure pressure, but improves because of it.

Common business startup mistakes [3,4]

1. Selling to the Wrong Customers: It is tempting in the early days to take any deal that comes your way. But not every customer is a good fit, and those who are only loosely aligned with your core offering will eventually churn, drain your support resources, or damage your reputation. Building a disciplined qualification process early is not a luxury, but a necessity for sustainable growth.

2. Underpricing and Poor Monetisation Strategy: Setting your price too low, either out of fear or in a misguided attempt to gain market share, signals a lack of confidence and risks anchoring your product as low value. At the same time, overcomplicating pricing or failing to tie it to customer outcomes can block adoption and reduce your perceived impact. Pricing must be tested, validated, and continuously aligned with how value is delivered and experienced.

3. Overbuilding Before Core Value is Proven: Many startups add features too quickly, trying to be all things to all users before they’ve demonstrated their core utility. This leads to bloated products, longer onboarding, and higher support costs. Start with the smallest, clearest version of value, then evolve based on actual customer behaviour and needs.

4. Failing to Build Around Retention and Expansion: Focusing exclusively on acquisition is a short-sighted strategy. Your existing customers are a richer source of revenue and insight than cold prospects, especially in subscription models where retention, upsell, and advocacy drive growth. Build your sales, success, and product functions with customer lifetime value in mind from the outset.

5. Misusing or Neglecting Sales Technology: Technology should serve your sales strategy, not complicate it. When properly selected, integrated, and used, sales tools enable faster feedback loops, better visibility into the funnel, and more time for meaningful conversations. But without the right setup, training, and process discipline, they become expensive distractions.

6. Hiring Sales Reps Too Early Without a Proven System: A common pitfall is bringing in sales hires before there is a repeatable and documented process for finding, qualifying, and converting leads. Even experienced sales professionals will underperform if thrown into an undefined system. Before hiring, ensure you’ve built the basics: a validated ICP, a tested pitch, and a reliable lead generation mechanism.

7. Trying to Do Everything Alone: Founders often carry the full weight of vision, product, and sales. But as the complexity of growth increases, so does the need for external input. Seeking out mentors, advisors, or strategic partners is not a sign of weakness; it is an operational strength that accelerates clarity and builds robustness into your go-to-market approach.

THE mistake! Also known as Technical Debt

Technical debt [5] is a powerful metaphor for deficiencies in internal software quality that slow future change. As Martin Fowler explains, it surfaces when our system accumulates “cruft”—architectural, design or code­r‑level issues that make adding new features harder than it should be. For example, a muddled module structure might take a developer six days to extend rather than four; the extra two days are interest on the debt. The metaphor helps us frame trade‑offs: deliver quickly now, or invest time in internal quality so that the future becomes easier.

But as Uncle Bob argues [6], not all bad code qualifies as technical debt. He draws a distinction between deliberate, managed compromises and reckless messes. A team may choose a sub‑optimal design for legitimate business reasons, fully aware of the cost and committed to pay it off later, this is true technical debt. In contrast, when poor design arises through laziness, ignorance or lack of discipline and there is no plan for remediation, it is simply a mess, not a debt. The mess will eventually choke the architecture and erode team productivity regardless of whether it was intentional.

Managing technical debt therefore becomes a matter of strategy and discipline. It is unwise to pretend that every shortcut is safe; we must treat debt like a financial obligation, some of it we may choose intentionally, but we must track the balance, pay the interest and gradually reduce the principal. Fowler recommends incremental “pay‑down” of cruft by refactoring areas we modify often, since the interest payments there are highest. Uncle Bob emphasises that taking on debt still requires cleanliness: the code created under the compromise must be maintainable, testable and refactorable, otherwise you’ve simply created a mess.

Ultimately, the question is not whether your system has flaws (every evolving software system does) but whether you treat them as manageable debt or uncontrolled mess. Internal quality is not a luxury; it is the fuel that enables speed, adaptability and antifragility. By being deliberate about the debt we accept, transparent about the cost, and disciplined about the payment, we build systems that do not merely survive change, but thrive because of it.

Final thoughts

A startup must not confuse early traction with stability. What it builds, how it sells, and who it serves are all subject to volatility. Pitfalls are not always dramatic collapses. Often, they are silent inefficiencies, decisions made under pressure, or compromises never revisited. The startup that survives is not the one that avoids all mistakes, but the one that learns how to surface them early, understand their impact, and build stronger processes in response. Whether the problem lies in misaligned customers, rushed pricing, overbuilding, or neglected code quality, each mistake leaves a trace. Startups should monitor these traces carefully, not to avoid failure, but to metabolise it into capability.

This is where the concept of antifragility becomes essential. It is not enough to remain operational in the face of stress; a company must grow more resilient because of it. Antifragility comes from feedback loops, from actively confronting what went wrong and iterating forward with intention. This includes managing technical debt deliberately, building quality into high-velocity areas of the codebase, and recognising when speed has quietly turned into drag. It also means knowing when to slow down, when to refactor, when to listen. Startups that treat every feature shipped, every deal lost, every spike in support tickets as signals rather than setbacks are the ones that stand a chance to grow past the fragile beginnings and into something more durable.

References

1. Silicon Valley Bank. What Are the Three Stages of a Startup? SVB.com. Published April 2022. Accessed November 5, 2025. https://www.svb.com/startup-insights/startup-growth/what-are-the-three-stages-of-a-startup/

2. Kritikos A. When There Is No Alternative to InnerSource. YouTube. Published December 5, 2024. Accessed November 5, 2025. Kritikos A. When There Is No Alternative to InnerSource. YouTube. www.youtube.com/watch?v=yvTn5DGvSA0

3. de Vonarkha‑Varnak J. Six Common Sales Mistakes SaaS Startups Should Avoid. Salescode.io. Published April 25, 2022. Accessed November 5, 2025. https://salescode.io/en/blog/six-common-sales-mistakes-saas-startups-should-avoid

4. Common Mistakes in SaaS Business and the Best Ways to Avoid Them. Medium. Published February 2022. Accessed November 5, 2025. https://medium.com/startup-insider-edge/common-mistakes-in-saas-business-and-the-best-ways-to-avoid-them-2f18cbb3c6bb

5. Fowler M. Technical Debt. MartinFowler.com. Published May 21, 2019. Accessed November 5, 2025. https://martinfowler.com/bliki/TechnicalDebt.html

6. Martin RC. A Mess Is Not a Technical Debt. Uncle Bob Consulting LLC. Accessed November 5, 2025. https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt

7. Fowler M. Technical Debt Quadrant. MartinFowler.com. Published October 14, 2009. Accessed November 5, 2025. https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

Open Source Software is probably the world’s largest collective experiment in organized chaos: a borderless network of volunteers, companies, and organizations who build and maintain a bunch of applications that form digital modern life. Linux, Kubernetes, Python, Apache, Android are all byproducts of this model that thrives not despite disorder, but because of it.

Let’s ask ourselves this. Could it be that the difference between a project that survives and one that outlives its founders is because of good governance choices?

Governance in open source should not be considered as bureaucracy. It’s, what we may call, the nervous system of a community. It defines the decision makers and the decision making process, but also how conflicts are resolved. In this sense, we could say that governance has the power to turn fragility into resilience and, well, resilience into antifragility.

As we saw in a previous post, an antifragile system doesn’t survive stress. It evolves through it! Sometimes when Open Source projects weather crises (a massive bug, a fork, a sudden leadership exit) we are witnessing antifragility in action. The code gets better, the governance tighter, the culture clearer.

Governance, in such cases, can assist by turning individual chaos into collective intelligence (or, as we call it, wisdom of the crowds).

Open Source Governance Types and What They Teach Us

Red Hat’s classic 2020 breakdown of governance models remains an up to date map. It identifies six archetypes: do-ocracy, founder-leader, self-appointing council, electoral, corporate-backed, and foundation-backed. Each distributes power differently.

• Do-ocracy: “Those who do the work make the decisions.” It’s agile, fast, and often terrifyingly informal. In a crisis, this model reacts quickly; the people writing the code fix the issue. But it’s socially unstable!

• Founder-leader: Clear vision, quick decisions, and one benevolent dictator. It’s efficient until it isn’t. When the “benevolent” part fades or the “dictator” part retires, fragility seeps in. The project risks losing its North Star.

• Self-appointing councils or boards: More structure, less personality. This model trades charisma for continuity, and that’s not always a bad deal. It keeps the ship steady, though sometimes at the cost of spontaneity.

• Electoral models: Democratic and fair, at least in theory. Elections can empower communities, but they can also turn them into campaign arenas. For large, mature projects (like Apache’s), the predictability and transparency outweigh the noise.

• Corporate-backed: Stability comes with strings. When a company runs the show, governance becomes predictable and predictably narrow. It’s great for focus, bad for community diversity.

• Foundation-backed: The elder statesman of governance models. By embedding legal and fiscal stability into the DNA of a project, it ensures longevity. The trade-off? Bureaucracy. (Though, as any maintainer will tell you, bureaucracy beats chaos most days.)

The key insight here is that no model is purely good or bad. Each trades speed for structure, creativity for continuity. Therefore, antifragility doesn’t come from choosing one. It comes from evolving between them as the project matures.

Governance as an Adaptive Immune System

If resilience is the immune response, governance is the immune memory. It captures lessons from crises and encodes them into policy, process, and culture.

GitHub’s Understanding Governance for Your Growing Project captures this beautifully: as communities grow, they must formalize roles (maintainer, committer, contributor) and document them, oftentimes in a simple GOVERNANCE.md.

The act of writing things down, who decides, how conflicts are handled, what behavior is acceptable, might seem mundane. Yet, this documentation transforms panic into protocol. When the next incident comes (and it will), the community has a starting point on how to deal with it. If we consider the role definitions and the documentation process learning loops, we got the project learning from past failures and hence, becoming more antifragile.

Security as the Mirror of Governance

In recent years, security researchers have started treating governance as a defense mechanism. Liran Tal, in Why Open Source Governance is Key for Security, argues that governance is security. A human firewall that filters trust and authority.

Who has commit access? Who reviews pull requests? Who maintains dependency hygiene? These are governance questions before they’re technical ones.

Software composition analysis tools can detect vulnerable packages, but governance determines how those findings become action. Without clear processes, no tool can save a project from itself.

Tal’s point is simple and profound: the earlier a community defines its governance, the easier it becomes to detect, triage, and prevent security issues. In open source, resilience is inseparable from accountability.

Diversity, Merit, and the Myth of Flat Hierarchies

Open source loves to romanticize the “bazaar”, a perfectly flat world where anyone can contribute and everyone’s ideas compete equally. But as Isabella Ferreira notes in Open Source Governance Models Explained, real communities aren’t flat; they’re porous.

Diversity of thought, background, and motivation is the hidden engine of resilience. Distributed authority ensures that no single point of failure (or ego) can paralyze progress. When one maintainer leaves, another steps in. When one company pulls out, another joins.

The healthiest projects understand that meritocracy, while attractive, is not enough. Without transparency and inclusivity, meritocracy becomes gatekeeping in disguise.

Governance creates antifragility by keeping the system open to new contributors and new perspectives. Redundancy, in human form, is what keeps open source alive.

Corporate Gravity and the Paradox of Control

Every major open-source success eventually faces the same existential question: what happens when the corporations arrive?

Companies bring money, time, and infrastructure but also expectations. As Red Hat and the Linux Foundation’s Building Leadership in an Open Source Community warn, influence in open source cannot be bought. It must be earned.

Guy Martin of Autodesk put it bluntly: “The only way to gain leadership is to earn credibility and make contributions.”

When companies learn this governance becomes a two-way symbiosis. The project gains resources and reach; the company gains insight and reputation.

But when corporations fork projects to “move faster,” they trade antifragility for short-term control. Forking is like cloning a tree by cutting off its roots. You get autonomy, not sustainability.

Culture: The Hidden Component of Governance

Culture is the personality of an Open Source Software and, therefore, its community’s. Leading in open source is as much about emotional intelligence as technical skill.

Communities succeed when they nurture psychological safety. The confidence to disagree publicly without fear of exile. Conflict, when well-managed, is not a weakness but a source of evolution.

Gil Yehuda of Oath captures this dynamic perfectly: “In order to develop influence on an open source project, you have to get a group of people who don’t know you, who work for different companies, and may have different objectives to agree with you.”

That’s governance as diplomacy. Paradoxically, the most antifragile system could be the one that welcomes disagreement. Every argument is a stress test. Every consensus, a reinforcement.

Innersourcing

Companies that contribute to Open Source Software often realize they can’t just “consume” collaboration; they have to practice it internally. Hence the rise of innersourcing; applying Open Source Software best practices in the corporate world.

The TODO Group’s guidance reads almost like a twelve-step program for cultural transformation: make code visible to everyone, enforce peer review, automate testing, shorten release cycles, and empower individuals by merit.

Innersourcing doesn’t just improve software quality; it inoculates organizations against fragility. It teaches teams to operate transparently, share ownership, and handle failure publicly. All habits of antifragile systems.

Governance as a Security Blanket with Memory

Governance can be a safety mechanism. A way to manage risk, define ownership, and ensure compliance. But over time, it can become a feedback engine.

Every vulnerability report, fork, and disagreement feeds into policy refinement. Every contributor who leaves, leaves behind documentation. Every failure leaves data.

Projects that institutionalize this learning, through governance councils, voting systems, mentorship, and codes of conduct, don’t just recover from stress; they grow because of it. They become harder to break and easier to adapt.

From Code to Community

Imagine democracy as an Open Source Software Project: policies are pull requests, citizens are contributors, laws are versioned releases.

Just as governments struggle with transparency and participation, so does Open Source Software. Yet the analogy holds as both systems thrive on shared intelligence. Governance, whether civic or digital, is a mechanism for turning conflict into collaboration.

A project that can handle dissent without division, like a democracy that can debate without collapsing, has achieved constructive disorder which can be considered a form of antifragility.

Final Thoughts

In software, sometimes we obsess over architecture, testing, and performance. But the real architecture that determines whether a project survives, is social.

Governance creates the conditions for creative tension. It’s what turns a community of strangers to an organism. One that senses, reacts, and adapts faster than a system.

In Open Source Software, fragility sometimes can be a feature rather than a flaw. Every crisis can be considered as a patch. Every argument documentation. And every fork, well, an experiment.

Good governance doesn’t protect software from failure. It teaches software and its people how to get better at failing.

And that, ultimately makes Open Source Software not only resilient, but antifragile.

References

1. Neary D, Berkus J, Novakovic K, Behrenshausen B. Understanding open source governance models. Red Hat; July 17, 2020.

2. Ferreira I. Open Source Governance Models Explained. Medium; March 23, 2022.

3. A Guide to the 6 Open Source Governance Models. Scantist; February 9, 2023.

4. Leadership and Governance. GitHub Open Source Guides; accessed 2023.

5. Tal L. Why open source governance is key for security. Snyk Blog; 2024.

6. Building Leadership in an Open Source Community. Open Source Guides, TODO Group (Linux Foundation); accessed 2023.

7. Open-source governance. Wikipedia; last updated 2024.

Software as a Service (SaaS) is the industry that undeniably moves fast but breaks faster. Platforms that promise to “revolutionize” collaboration, automate the tedious, or unlock new efficiencies in the cloud, pop-up all the time. Yet most SaaS companies wrestle with the same invisible pressure: how to build, launch, and grow a product that actually lasts.

The SaaS model is beautiful in theory: recurring revenue, global scalability, automatic updates. In practice, it’s an endurance test. Implementation hurdles, scaling pains, user churn, technical bottlenecks, and cultural misalignments can grind even the best ideas to a halt.

In this post we will try to map common challenges that define the SaaS lifecycle. This isn’t a checklist but a stress map including factors that can determine whether our products thrive or burnout.

For better navigation, we have grouped the identified stressors in five major challenge zones.

1. Technical & Product

2. Business

3. Team

4. Customer

5. Implementation & Governance

1. Technical & Product Challenges

Building for Change.

There are software systems that can be fast, elegant, and even “user-loved”. However, these same systems can collapse spectacularly when success arrives too quickly. In the SaaS world, growth isn’t always connected with progress and vise versa.

In the early days of SaaS, scalability was often treated as a “future problem.” Teams focused on features, not foundations. The result was performance bottlenecks, database meltdowns, and the famous “please refresh” message that haunted every beta launch. Over time, architecture became strategy. Concepts like elastic scaling, microservices, and feature flagging evolved not just as technical patterns but as survival mechanisms.

Integrations followed a similar story. The modern SaaS product rarely stands alone. It must coexist with CRMs, ERPs, payment gateways, and analytics stacks. Compatibility is no longer a luxury; it’s part of the user promise.

And then there’s security, the quiet guardian of trust. Where early SaaS teams treated encryption as optional, compliance frameworks like GDPR, SOC 2, and HIPAA have since made it mandatory. Not just for legality, but for credibility as well.

Ultimately, technical resilience in SaaS is not about writing perfect code. It’s about writing code that endures, adapts, scales, and survives contact with real users. The mature SaaS product is not built for launch day. It’s built for the thousand unpredictable tomorrows that follow.

2. Business Challenges

Strategy Under Pressure.

When the first generation of SaaS founders spoke about “recurring revenue,” it sounded like a dream. Predictable income, infinite scalability, and low distribution costs. In reality, it was the beginning of a new kind of pressure: the constant demand for retention over acquisition and value over novelty.

At the heart of every SaaS business lies a question: Who is this for, and why will they pay for it again next month?

Finding that answer determines whether a company grows sustainably or fades quietly into a market that has already moved on. This is what we call product - market fit.

Pricing is the next battlefield. Subscription models promised stability, but also introduced psychology into revenue strategy. Tiered pricing, usage-based billing, and freemium models make evident that the closer price aligns with perceived value, the stronger the company’s financial resilience.

Beyond revenue design, SaaS businesses must navigate hidden costs. There are vendor dependencies, API fees, and compliance overheads and more. Meanwhile, the competitive landscape grows noisier every quarter. Winning today is less about adding features and more about building ecosystems that embed your product into customers’ workflows and identities.

In this sense, SaaS strategy becomes less about growth hacks and more about orchestration. Aligning technology, finance, and brand storytelling under one clear vision. Because when everything moves fast, clarity becomes your only sustainable advantage.

3. Team Challenges

Alignment is Everything.

Software doesn’t scale! Teams do. And in SaaS, team dynamics can make or break a product long before the market gets a chance to.

Historically in product development, small teams thrive on shared context; everyone knows everything. As the company grows, that unity fragments. Engineering ships features marketing didn’t know about. Customer support learns about bugs from Twitter. It’s not incompetence; it’s entropy.

Cross-functional alignment is the antidote. Shared OKRs, transparent dashboards, and interdepartmental rituals. SaaS companies should aim to a collective understanding that the product is not “owned” by any one team, but by the organization as a whole.

The second challenge is talent. SaaS companies live in a domain that demands hybrid skill sets: engineers who understand UX, marketers who speak data, and leaders who can interpret both. The hiring market rarely provides these ready-made, so training and mentorship become strategic necessities, not perks.

Then comes change management. SaaS moves fast, but people don’t. Rolling out new tools or processes without empathy leads to fatigue, resistance, and eventual disengagement. The best teams treat internal adoption like customer onboarding: communicate early, train continuously, celebrate wins.

Last but not least, there’s culture. That subtle architecture of trust, feedback, and curiosity. SaaS may be powered by code, but it’s animated by people. A company that treats collaboration as infrastructure can outlast market noise and management fads.

4. Customer Challenges

Growth Beyond Acquisition.

In the SaaS industry we used to measure success by sign-ups. If the graph pointed up, optimism followed. But soon, founders realized that growth isn’t the number of people who try your product. It’s the number of those who stay.

Customer growth in SaaS is therefore less a matter of marketing and more a study in human behavior. Users arrive with expectations shaped by other platforms, other experiences, and other frustrations. The challenge is not just to attract attention but to build and sustain trust.

Onboarding is where this trust begins. A good onboarding flow is like a well-lit path through an unfamiliar city. Products such as Slack and Notion mastered this by embedding micro-discoveries. Those small “Aha!” moments that make a user feel clever, not lost.

Retention, on the other hand, is the art of staying relevant. It demands continuous dialogue, whether through updates, education, or community. When handled with care, these interactions transform users into advocates. The strongest brands don’t broadcast; they converse.

Transparency plays an equally central role. Outages, bugs, and delays are inevitable. What defines a SaaS company’s maturity is how it communicates during those moments. The teams that publish clear incident notes and speak candidly about failure often emerge with more trust than before.

In essence, growth in SaaS is not acceleration. It’s continuity. It’s the slow compounding of goodwill, usability, and transparency. Products that respect this rhythm evolve from tools into partners, from software into ecosystems.

As we mentioned earlier, the SaaS journey doesn’t end with acquisition. It begins with retention. And in that space between the first click and the thousandth login, true growth quietly takes root.

5. Implementation & Governance Challenges

Getting It Right the First Time.

Before a SaaS product dazzles users or scales to millions, it must first work! Reliably, securely, and predictably.

Implementation sounds straightforward: connect systems, migrate data, train teams. But in reality, it’s closer to a choreography between technology, people, and expectations. The most common mistake? Treating implementation as a checklist instead of a change process. When objectives are vague or success metrics undefined, even the best software becomes another unused license in a growing portfolio of digital clutter.

Then comes governance. Once upon a time, IT departments controlled every piece of software within an organization. Today, SaaS decentralizes that authority. Sales teams buy CRMs, HR signs up for analytics tools, and marketing subscribes to automation platforms. Without structured oversight, this freedom can easily turn into fragmentation.

Strong governance frameworks restore alignment without stifling agility. They establish clear roles for decision-making, vendor accountability, and compliance checks. In regulated industries, this becomes more than efficiency. It becomes protection. The difference between a well-governed SaaS ecosystem and an unmanaged one often appears only during crisis: one adapts, the other panics.

But governance isn’t just about control. It’s about visibility. Continuous performance monitoring, user feedback loops, and iterative improvement transform “go-live” from a finish line into a starting point. The most resilient SaaS companies never stop auditing themselves. They treat every deployment as a living system to be observed, tuned, and evolved.

In this light, implementation is not the first chapter of SaaS success. It’s just an introduction. It sets the tone for everything that follows: adoption, trust, and ultimately, growth.
Because a product that begins with clarity and governance doesn’t just launch—it lasts.

From Chaos to Continuity

There are software systems that can be classified by what they do and others by how they survive. SaaS belongs to the latter category. It isn’t simply a model for delivering software over the internet; it is an ongoing experiment in adaptability.

Throughout its evolution, SaaS has forced us to rethink what “finished” means. A traditional software release had an endpoint: a version number, a CD (in older times), a patch. SaaS erased that boundary. Deployment became continuous. Feedback became instantaneous. Failure became visible. In this sense, SaaS transformed software from a product into a process.

From implementation to growth, each layer of this process introduces its own kind of stress. The technical layer demands resilience. Systems that expand and contract with unpredictable demand. The business layer tests clarity. Finding a purpose in a market of noise. The team layer measures coherence. Aligning humans around shared context. The customer layer builds continuity. Nurturing trust long after the sale. And finally, the implementation layer anchors it all through governance. Ensuring the system doesn’t collapse under its own freedom.

The SaaS Challenge Map, is less a list of problems than a living framework of tensions. It reminds us that the real test of modern software isn’t functionality, but fragility. Every new feature, integration, or deployment adds complexity, and every layer of complexity invites risk. The goal is not to eliminate that risk, but to evolve through it.

In other words, the most successful SaaS companies do not aim to be unbreakable. They aim to be antifragile! Dynamic systems that grow stronger each time they are tested.

References:

• Ful.io. Top 9 SaaS Development Challenges and Solutions to Overcome Them. Ful.io Blog. Published 2025. Accessed October 22, 2025. https://ful.io/blog/saas-development-challenges-and-solutions

• Userpilot. 10 SaaS Challenges Across Product, Sales, and Business (and How to Overcome Them). Userpilot Blog. Published 2025. Accessed October 22, 2025. https://userpilot.com/blog/saas-challenges/

• Imaginary Cloud. Top 10 SaaS Implementation Challenges and How to Solve Them. Imaginary Cloud Blog. Published 2025. Accessed October 22, 2025. https://www.imaginarycloud.com/blog/top-10-saas-implementation-challenges-and-how-to-solve-them

There is software out there that can be classified either as Free / Open Source or as Closed Source. Lately a new term, Inner Source Software, has been introduced but we will get to that later. The important thing is that the aforementioned classifications of software forms the Source Code Spectrum.

The decisive factor of where a software project will end up in the Source Code Spectrum, is usually its level of openness. This is usually connected with the type of license the project is published under (for example, if a project is published under the MIT license it is considered a permissive open source software project but if it is a proprietary software, copyrighted by a company, it is considered a closed source software project).

The license of a project can, indeed, play a part in the longevity of a software project and that is why license type has been part of the resilience-based framework we proposed in [1] for assessing the evolution of open source projects. However, in this post of Software Antifragility, we will approach the Source Code Spectrum from another point of view. The way it is being developed!

Closed Source Software Development

In the beginning, there was closed source software:

Closed source (or proprietary software) are computer programs whose source code is not published. The source code is not shared with the public for anyone to look at or change. Closed source is the opposite of open source.

~ Wikipedia

Before remote work, before version control, before CI/CD, developers were using collective backups for writing software. A version of this was the anecdotal “shout & ftp” technique in web development: You would shout “is anyone working on the foo page?” If no one piped up, you’d ftp into the server and download it. Make your changes and then load the file back, hoping your coworkers remembered to shout before they made any changes themselves that would stomp on yours [2].

Software was being developed from teams, it was orchestrated in a central release of an executable or server app and it was served to the users. For the desktop applications, the executable files were usually offered via user licenses that prevented them for being copied or shared with others for free.

Unless of course, the application is WinRAR. Because WinRAR offers a 40-day trial that ends… well… never!

From autumn 1993, when it was first released, until now, this software can be used for free even after the 40 days trial has expired 👇

Post version control systems (CVS, SVN, Perforce Helix Core in the past and Mercurial and Git more recently), the teams started working on their code collectively using a centralized version control system that allowed them to keep track of the changes, deal with conflicts and orchestrate their releases better.

What’s interesting is that, even after the adoption of version control systems, some closed source companies kept implementing their software in silos.

In such cases, although the closed source code of the software product was owned by the same company, some engineers might never access specific parts of it, even if they were working with the same company for years. This phenomenon, appearing mainly in bigger companies, is still happening nowadays, usually in large companies that are developing several different software products. In such cases the developers of one project do not have access to the code base of another.

In this sense, the Wikipedia definition of Closed Source could change to:

Closed source (or proprietary software) are computer programs whose source code is not published. The source code is not shared with anybody but the programmers who are responsible for crafting the software.

Open Source Software Development

Then Open Source Software happened! Before we dive in, let’s talk definitions: We have Free Software, Open Source Software and Free / Libre Open Source Software. If you currently look at Wikipedia you will find the following definitions:

Free software, libre software, libreware sometimes known as freedom-respecting software is computer software distributed under terms that allow users to run the software for any purpose as well as to study, change, and distribute it and any adapted versions.

Wikipedia

Free Software as a term is attributed to Richard Stallman who crafted the first formal definition who was then published by Free Software Foundation in February 1986. [3]

Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose.

Wikipedia

In 1997, Eric Raymond’s essay The Cathedral and the Bazaar explored the development model of Free Software, influencing Netscape’s decision in 1998 to release the source code for its browser suite. This code base became Mozilla Firefox and Thunderbird.

To broaden business adoption, a group of developers including Raymond, Bruce Perens, Tim O’Reilly, and Linus Torvalds rebranded the Free Software movement as “Open Source.” The Open Source Initiative (OSI) was founded in 1998 to promote this new term and emphasize collaborative development benefits over ideology. [4]

More or less, Raymond in the Cathedral and the Bazaar essay, described the Open Source Software Development culture as shown (in a simplified version) in this video:

In Open Source Software Development, a community of people are working together to create software. Since they are volunteers they can come and go as they please but this creates the need for the source code, the requirements, the specifications, the roadmap, designs, schematics, bug reports / tickets and so forth to be openly available and transparent to everyone.

Open Source Software Development looks like closed source software development, completely inversed, right?

It is worth mentioning that some of the most used software in the planet is built as open source software. And although Open Source Software is being developed as a collaborative approach based (mainly) in voluntary work, the '“valuation” of some open source software projects is also impressive:

Inner Source Software Development

We have seen what Closed Source Software is and how Open Source Software revolutionized how software development was happening. What about Inner Source? What kind of witchcraft is that and how is it positioned in the Source Code Spectrum?

Inner Source is the use of open source software development best practices and the establishment of an open source-like culture within organizations for the development of its non-open-source and/or proprietary software.

Wikipedia [5]

The term was coined by Tim O’Reilly circa 2000. It is a growing trend in the engineering world. Teams adopting Inner Source aim to work and collaborate more effectively. Although they develop proprietary software, they open up the work internally between teams so that everyone — from developers to product managers — can contribute to the source code.

Here’s a video from Github, explaining the concept of Inner Source 👇

Inner Source is adopted today by a variety of corporations in terms of business sector and size. Some of them are: Hewlett Packard, Red Hat, Philips, IBM, Robert Bosch, Google, Microsoft, SAP, PayPal but also non-technological companies and organizations like Walmart, BBC, Deloitte, Disney, Etsy, Mercedes-Benz, NASA, Harvard Business Review among others.

Characteristics of development in open, close and inner source environments

Closed Source Software Development keeps the source code private and accessible only to authorized developers within an organization. Ownership rests with a single entity, and collaboration is usually limited to internal teams following a hierarchical structure. Transparency is low since decisions, issues, and design choices are not publicly visible. Governance is centralized, and innovation tends to move at a moderate pace due to reliance on internal R&D. A classic example is Microsoft Office.

Inner Source Software Development applies open-source principles within an organization. Code is accessible to all employees, encouraging cross-team collaboration while maintaining company ownership and intellectual property rights. Transparency is high internally, as documentation, reviews, and discussions are shared across teams. Governance follows a hybrid approach; open contribution with internal oversight. This model accelerates innovation and knowledge sharing within large organizations. PayPal’s Inner Source program is a notable example.

Open Source Software Development makes the source code publicly available for anyone to view, modify, or distribute under open licenses like MIT or GPL. Ownership is shared and governed by community norms and licensing agreements. Collaboration is global and community-driven, with contributions from individuals and organizations worldwide. Transparency is very high, as development processes are open to all. Governance is distributed, and innovation occurs rapidly through diverse, continuous contributions. The Linux Kernel is a prime example.

Reference:

[1] Kritikos, Apostolos & Stamelos, Ioannis. (2023). A resilience‐based framework for assessing the evolution of open source software projects. Journal of Software: Evolution and Process. 36. 10.1002/smr.2597.

[2] Quora. Before version control like Git was invented, how did people manage code in a project? Quora website. https://www.quora.com/Before-version-control-like-Git-was-invented-how-did-people-manage-code-in-a-project. Accessed October 15, 2025.

[3] Wikipedia. Free software. Wikipedia website. https://en.wikipedia.org/wiki/Free_software. Accessed October 15, 2025.

[4] Wikipedia. Free and open-source software. Wikipedia website. https://en.wikipedia.org/wiki/Free_and_open-source_software. Accessed October 15, 2025.

[5] Wikipedia. Inner source. Wikipedia website. https://en.wikipedia.org/wiki/Inner_source. Accessed October 15, 2025.

Τhis is officially the first post of our rebranded newsletter. I’d like to start with definitions. To be able to discuss about antifragility and what it means for software engineering, it is important that we:

1. Define antifragility outside the scope of software engineering.

2. Revisit software engineering’s history and investigate why the concept of antifragility is relevant to software.

Let’s begin.

Antifragility is a term coined by Nassim Nicholas Taleb circa 2012, when he published his book Antifragile: Things That Gain from Disorder. It is defined as a property of systems that gain from volatility, uncertainty, and stressors. It’s not merely about survival or adaptation; it’s about transformation. When a system is antifragile, shocks act as fuel for improvement. Mistakes become data, volatility becomes feedback, and randomness becomes a source of creativity.

At its heart, antifragility is a philosophy of engagement with the unpredictable. It asks us to design systems that learn, self-correct, and regenerate. It is a mindset that reframes uncertainty from a threat into an ingredient for progress.

What does antifragility have to do with Software Engineering?

During the 70s and the 80s a need became apparent. In certain cases, it was critical that we create software that would be as error free as possible. Margaret Hamilton, while working for the Apollo space programme, pioneered building in code to prevent failures due to user error or hardware failure. Software Engineering was born and popularized by a NATO conference in 1968. Software crisis, a term coined by Fritz Bauer in the same conference, described a critical shortage of programmers (sounds familiar?).

Throughout the 70s the software world tried to improve software quality. Structured programming, functional programming and object-oriented programming where some of the coding paradigms that emerged to assist this effort. Testing began to be recognized as separate from debugging when Glenford Myers wrote The Art of Software Testing in 1979. The software development life cycle (SDLC) was formalised in the 1980s and the waterfall model became commonplace after the US Department of Defence adopted it in 1985 [1].

This was the era of Software Robustness.

In computer science, robustness is the ability of a computer system to cope with errors during execution and cope with erroneous input.

~ Wikipedia [2]

Software Quality as a concept was heavily investigated by the academia. In [3] we found that there were a lot of Quality Models created between 1977 and 2013. They are sorted in Basic Models (1977-2001) evaluating software as a whole and Tailored Quality Models (2001-2013) which extend evaluation to components. Moreover, these models try to evaluate more than the source code. Robustness wasn’t enough any more.

Although resilience is connected with software since 2009, the connection mainly happens on an infrastructural level. When we talked about resilience in computer science at this period, we did it from the network perspective; how (the network) could cope with stressors like power outages, hacking attempts and so forth. During my PhD dissertation (2017-2023) I tried to introduce the concept of Software Resilience by using the research of the Arup + Rockefeller institutes; the City Resilience Framework. Although City Resilience Framework was meant to evaluate Urban Resilience, in [3] we argue that there are conceptual similarities between a city and an Open Source Software (OSS). OSS projects are dynamic and continuously evolving systems with their own structural properties, they attract people that form communities around them which, on a second level, may utilize a governance model. Some OSS projects have commercial activity. As it is happening with cities, OSS projects can face stresses and crises (i.e. developers abandoning the project to work on a fork or users massively migrate to a competitive project).

Now that we have established that software can be resilient, lets try to define resilience:

Resilience lies in the ability of a system to suffer stresses and crises and, nevertheless, survive them.

City Resilience Framework [4]

I approached the resilience of an Open Source Software, from four distinct dimensions.

• It’s structure (source code)

• It’s monetization capabilities (which reflect on the projects legal and business decisions).

• It’s ability to be integrated to other projects or integrate other projects itself

• (and, last but not least) it’s social aspect (aka its community of developers, users, stakeholders, etc).

Fast forward to the sunset of 2025, I feel antifragility is a prerequisite for survival. We are seeing the world and almost every aspect of our lives facing major challenges; major stressors. From the economic crisis that started on 2008 (and never really ended), the pandemic that followed in 2020 and now the wars that emerge in different parts of the earth, we see that we are navigating through troubled times. I strongly believe that it is imperative to move past resilience - the ability to navigate through a crisis without “losing ourselves” - to antifragility, the ability to learn from a crisis and come out wiser and ready to avoid it next time.

For software it is, more or less, the same. Nowadays the rapid evolution of interconnectivity through the World Wide Web and the rapid evolution of AI create opportunities for creativity and prosperity. At the same time, they bring challenges. Resources management, privacy and security issues and the hot topic of when we are going to be enslaved by the machines 🙃.

Regardless of how likely or unlikely, how intense or impactful these scenarios may be, we will need to bring software engineering to the next level.

Welcome to Software Antifragility!

References:

1. Harrison AJ. Robust Programs. In: How to Teach Computer Science. Available from: https://httcs.online/robust/.

2. Robustness (computer science). Wikipedia. Updated [cited 2025 Oct 8]. Available from: https://en.wikipedia.org/wiki/Robustness_(computer_science).

3. Kritikos A, Stamelos I. Open Source Software Resilience Framework. In: Stamelos I, Gonzalez-Barahona J, Varlamis I, Anagnostopoulos D, eds. Open Source Systems: Enterprise Software and Solutions. OSS 2018. IFIP Advances in Information and Communication Technology. Vol 525. Cham: Springer; 2018. doi:10.1007/978-3-319-92375-8_4

4. Da Silva J, Morera B. City resilience framework. Arup & Rockefeller Foundation. Online: http://publications. arup. com/Publications/C/C-

   ity_Resilience_Framework.aspx [12/15/2015] 2014.

5. Kritikos, Apostolos & Stamelos, Ioannis. (2023). A resilience‐based framework for assessing the evolution of open source software projects. Journal of Software: Evolution and Process. 36. 10.1002/smr.2597.

Dear Subscribers,

🎉 Exciting News! 🎉

Coming October softwareresilience.substack.com will be served from www.softwareantifragility.com.

I created this Substack circa 2017 to serve as a notepad for my PhD on Open Source and Software Resilience.

I failed to follow up on that so I thought I could retrospectively share with you the learnings of the journey. And I did, for a while; 23 posts worth of a journey to be precise.

Lately I have been pondering on the future of this newsletter. I kept feeling that the name and content didn’t align. Instead of sharing content about Software Resilience I was mainly sharing lessons from my field work as an engineering leader 🙃.

I thought of starting a new Substack. But I didn’t want to let this one go and start from scratch. So I started thinking of ways to turn evolve this newsletter to something new; a topic worth investigating and field testing at the same time.

While I was struggling with these thoughts, “universe stepped in” 🤣. I received an offer to sell www.softwareresilience.com. It was the sign I was looking for.

So… Software Resilience is dead; long live Software Antifragility 🚀

From October onwards, this Substack will be served from www.softwareantifragility.com.

What you can expect after the rebranding:

1. New research related to software antifragility.

2. Opinion pieces on how software engineering roles, processes, tools, frameworks, etc, can impact the antifragility of a software.

3. Empirical insights of software antifragility in the Software as a Service industry.

4. Software Antifragility in the code spectrum: Closed Source - Inner Source - Open Source.

5. and the occasional engineering leadership / misc posts 😁.

NOTE: I will preserve the old posts as an archive, but the focus will (hopefully) change!

Unless I fail again!

Thank you for being part of the journey.

Talk to you soon 🫡,

Apostolos

P.S: What is Antifragility?

Git for Pros: Tools & Concepts for Mastering Version Control with Git

• Commits

  • git add filename

  • git diff filename

  • git add -p filename (patch level / select chunk of change to commit)

  • Commit message

  • simple title then

  • empty line

  • then body of the commit

  • git log

• Branches

• Written convention

• Always be integrating

  • few branches

  • relatively small commits

  • high-quality testing & QA standards

• State, release and feature branches

  • different types of branches...

  • ...fullfill different types of jobs

  • Long-running branches

    • exist through the complete lifetime of the project

    • often, they mirror "stages" in your dev life cycle

  • Short-lived branches

    • for new feature, bug fixes, refactorings, experiments...

    • will be deleted after integration (merge/rebase)

• GitHub Flow

  • very simple, very lean: only one long-running branch ("main") + feature branches

• GitFlow

  • more structure, more rules

  • long-running: "mail" + "develop"

  • short-lived: features, releases, hotfixes

• How to choose "Best" Branching Model?

  • consider your project, release cycle, and team

  • take inspiration from existing models (like "GitFlow" or "GitHub Flow")

  • ... and create your own model!

• Pull requests

  • Communicating About and Reviewing Code

    • Without a Pull Request, you would jump right to merging your code...

    • A Pull Request invites reviewers to provide feedback before merging

  • Contribute code to other repositories (you may not have push access)

    • creating a "Fork" of the original repository, where you can make changes...

    • ... and sugest those changes to be included via a PR (i.e. in OSS projects).

    • fork project > git clone > git branch test > git checkout test > open pref editor > make changes > git status > git add ... > git commit -m "" > git push --set-upstream origin test > go to browser github and create a pull request

• Merge Conflicts

  • How and when they occur

  • git merge, git rebase, git pull, git cherry-pick, git stash apply

  • Merging changes in Git

    • most of the time, GIt will figure things out on its own!

    • when contradictory changes happen, git may not know what's correct! (i.e. file is changed in one change and deleted in another)

    • we can undo a conflict and start over (not always have to resolve it)

      • git merge --abort

      • git rebase --abort

    • when we want to handle the conflict, we see the conflicting part in the file

      • in such cases we just clean-up the file communicating with the other team member

      • after clean-up we do git mergetool and we have to select between modified or deleted file or abort

      • changed file is added and ready to be committed!

• Merge vs Rebase

  • Merge

    • most simple scenario: original commit triggered to branches A and B, B has changes, A remained as is so the changes of B are merged to A (fast-forward merge)

    • merge-commit is created automatically from git to synthesize 2 different branches with changes

  • Rebase

    • git rebase branch-B (the one we want to integrate as with merge)

    • rebase re-writes commit history eliminatiting branching for history

    • WE NEED TO BE CAREFUL when we rebase branches in public commits as they may eliminate the evidence of the work of another developer

    • DO NOT rebase on commits that you've already pushed/shared on a remote repository!

    • You should use them to clean up your local commit history before mergin remotely.

Notes taken from this video 👇

#2

Advanced Git - Interactive Rebase, Cherry-Picking, Reflog, Submodules and more

• Interactive rebase

  • a tool for optimizing and cleaning up your commit history

    • change a commit's message

    • delete commits

    • reorder commits

    • combine multiple commits into one

    • edit / split an existing commit into multiple new ones

  • DO NOT use interactive rebase on commits that you've already pushed/shared on a remote repository!

    • instead, use it for cleaning up your local commit history before merging it into a shared team branch

    • git rebase -i HEAD~3

      • "reword" the line you want to edit the commit message

      • then a new window opens that allows us to change the commit message

    • git rebase -i HEAD~4

      • squash the line that you want to combine with the previous commit

      • first line creates the commit message for the combined commit

• Cherry picking

  • Moving a commit to a different branch

    • git checkout feature/newsletter > git cherry-pick commit_number

    • then git checkout master > git reset

    • hard HEAD~1 to clean up the master branch

• Delete unwanted commits

  • git reset --hard commit_id_I_want_as_last

• Delete branch

• The Reflog

  • Recovering deleted commits

    • git reflog > git branch happy-ending number of deleted commit from reflog

  • Restoring branches

    • git reflog > git branch feature/login commit number of the deleted branch

• Submodules

  • Mixing external code with your own files

  • Updating the external code is, again, a manual process

  • mkdir lib > cd lib > git submodule add URL to library > git commit -m ""

  • git clone project with submodules

    • git submodule update --init (to add the actual submodules folders / populate)

    • or git clone --recurse-submodules and project clone URL

• Search and Find

  • Filtering your commit history: git log

    • by keyword --grep="<keyword>"

    • by date --before / --after

    • by message --grep

    • by author --author

    • by file -- <filename>

    • by branch <branch-A>

Notes taken from this video 👇

• As computer systems get more sophisticated we've seen a growing trend to value deep specialists. But we've found that our most effective colleagues have a skill in spanning many specialties.

• We are thus starting to explicitly recognize this as a first-class skill of “Expert Generalist”.

• The characteristics that we've observed separating effective software developers from the chaff aren't things that depend on the specifics of tooling.

• We rather appreciate such things as: the knowledge of core concepts and patterns of programming, a knack for decomposing complex work-items into small, testable pieces, and the ability to collaborate with both other programmers and those who will benefit from the software.

• This echoes a long debate about the relative value of specialists and generalists.

  • Specialists are seen as people with a deep skill in a specific subject,

  • while generalists have broad but shallow skills.

• Folks that only work in a single technological neighborhood are at the constant risk of locking themselves into a knowledge silo, unaware of many tools that could help them in their work.

• This ability goes beyond just developer skills. We've seen our best business analysts gain deep skills in a couple of domains, but use their generalist skills to rapidly understand and contribute in new domains.

• So over the last year or so we have started to resist this industry-wide push for narrow skills, by calling out this quality, which we call an Expert Generalist.

• Expert Generalists have the following attributes:

  • Curiosity: Self-explanatory

  • Collaborativeness: Self-explanatory

  • Customer Focus:

    We are fans of Kathy Sierra's notion that our purpose as software developers is to help our customers become “badass” at what they do.

  • Favor Fundamental Knowledge:

    Such knowledge tends to age slowly, and is applicable when folks move into new environments. For example the basic moves of refactoring are the same whatever language you are programming, the core patterns of distributed systems reappear regularly.

• Good Catch in that —> Blend of Generalist and Specialist Skills is not being reflected correctly to the “T-shape” metaphor.

  While the T-shape moniker did catch on, it comes with a major problem in the metaphor, we don't find such folks have only a single deeper skill. They usually have a few, of varying depth.

(Martin Fowler et. al. / June 19, 2025 / MartinFowler.com / permalink)

#2

Connection with previous Notebook Entries

Entry of June 10, 2025 was about engineering roles, career ladders and professional growth extensively.

• How is the skill of Expert Generalist connects with the above?

• Is it a skill that should be linked with the “Management Track” of a career ladder, or it could be relevant to the more mature levels of the “Individual Contributor’s Track”?

• How can we effectively cultivate this skill within a company or organization?

Side Note: Is Expert Generalist skill relevant to the Open Source / Inner Source governance?

Editathon - Maintainathon - Hackathon

• 22 teams from all over world

• Maintainathon —> Strengthening the open source infrastructure

  • 50+ breakout sessions

  • Senior maintainers

• Editathon —> Safeguarding the integrity of the information online

  • 6 new articles

  • 234 existing articles

  • 30000+ edits

  • topics related to UN and mission around emerging technologies

  • 37 editors

  • Collective effort reached a global audience of 2.000.000 views

• Hackathon —> Fostering inclusive collaboration

  • 81 hackers

  • 3 ambitious challenges: Children - Climate - RIS data

3rd edition of OSPOs for Good (happening for 3 consecutive years)

This year (2024-2025) UN:

• Released the open source repository

• Released the open source catalogue

• Released the open source principles

OSPOs for Good sessions:

• Continue the dialog that started 3 years ago

• How we can build more effective government OSPOs?

• Explore the dynamic relationship between Open Source and AI

• Discuss how Open Source and DPIs can re-enforce each other

• During DPI Day we will

  • Better connect open source and DPI communities and ecosystems

  • Help align initiatives in global level and

  • Ensure that DPI projects actively contribute to the implementation of the Global Digital Compact

UN is a space for all stakeholders not only governments

Global Digital Compact (GDC) is a north-star for every actor in the digital ecosystem

• Open AI models and open access to training data

• Open Source as a foundation for digital transformation

• GDC is open for endorsement for individuals or organizations

Panel: How They Did It: A Look Behind Newly Launched OSPOs

• 96% of all software has open source components in it

• 80% is released as open source

• OSPO Amazon: Started back in early 00s (2004 - 2007)

• OSPO started first to focus on the compliance side of things

• The driving motivation for an OSPO starts usually with compliance but then moves to engagement!

• We “Africanized” open source projects to have short term project delivery of projects with long term support.

//———————————- Live X(ing)? tweeting started here ——————————//

• #AI and #OpenSource: Building #Ethical and #Transparent Systems happening now at #UNOpenSourceWeek.

• Sabrina Farmer. At Gitlab we are vendor agnostic. Before we work with services, we make sure there are no violations when our systems interacting with the #data. #UNOpenSourceWeek

• Hakim Hacid. AI as a problem is a very complex problem to be dealt by a specific actor only. We need to foster collaboration #UNOpenSourceWeek

• Guilherme Canela: Intenational rule of law system allowed the collaboration in different levels and groups (i.e. #scientific #community). But we need to revisit and be careful how we translate everything to #respect the #human #rights agenda #UNOpenSourceWeek

• Expected reference to GreatDismal work as the #digital #future and #AI is being discussed. Once again, we are coming to the conclusion that #opensource, by fueling open, collaborative work, can be a force to the right direction #UNOpenSourceWeek

• Hakim Hacid: Data is the oil that fuels the AI. However there is part of these data that can be considered high quality (data as such can help researchers to build AI) #UNOpenSourceWeek

• Hakim Hacid: Preserving the #privacy of the #data but also fostering the research around AI is a challenge of paramount importance #UNOpenSourceWeek

• Hakim Hacid: There seems to be a luck in relevant #talent that will help us build #AI the right way, collaboratively #UNOpenSourceWeek

• Hakim Hacid: There is a need for #regulation, but we need to do it the right way. Also there is need for #standardization, but we need to also collaboratively decide what we can do to speed up #development. #UNOpenSourceWeek

• Guilherme Canela: Maybe the real #innovation is not whether we have super #regulation or super #governance. Maybe it is how we do things without leaving anyone behind #UNOpenSourceWeek

• Guilherme Canela: The scientists that decided to share their research as #open #science during #covid19 era, made the vaccines to be developed very fast. We have been advocating for #openscience years before at #UN #UNOpenSourceWeek

• Panel #2 / Breaking Silos: #OpenSource and #OpenData Drive #Interoperability #UNOpenSourceWeek

• Egos drive a lot of #innovation in #tech. #UNOpenSourceWeek

• #OpenSource is a #governance #model #UNOpenSourceWeek

• In both UN/LOCODE and UN/CEFACT we are applying #opensource solution and we need help #UNOpenSourceWeek

• #dataism vs #humanism #UNOpenSourceWeek

• Nabiha Syed / Mozilla Foundation: #opensource is only one instantiation of the general #open #philosophy. This is not about product-market fit but about product-community fit #UNOpenSourceWeek

• Nabiha Syed / Mozilla Foundation: #opensource needs not consumers but collaborators in the co-creation process #UNOpenSourceWeek

• Masayuki Yamada / Digital Agency, Japan Gov: A digital society where noone is left behind. That is the vision for the Japanese government #UNOpenSourceWeek

• Rebecca Mackinnon / Wikimedia Foundation: If we want quality data, we need attribution (highlighting that data produced from AI may be of low quality due to hallucinations) #UNOpenSourceWeek

• I heard "we should go back to pre-internet human rights". I would argue that the early days of the internet created collaborative communities that had respect as their core values (at least in the majority of cases). We are talking 1990+ to 2020+ here #UNOpenSourceWeek

• Panel #3 / The Role of Open Source in Digital Public Infrastructure (DPI) #UNOpenSourceWeek #OPSOsforGood

• Adriana Groh / Sovereign Tech Agency: We are trying to create a blueprint is like a new government muscle where solutions are produced but also shared for collective improvement and optimization #UNOpenSourceWeek

• Adriana Groh / Sovereign Tech Agency: We are trying to create a blueprint is like a new government muscle where solutions are produced but also shared for collective improvement and optimization #UNOpenSourceWeek

• Gabriele Columbro: Providers solutions (meaning proprietary solution) in a very big percentage (up to 90%) probably run on #opensource. Think them as the last mile of open source #UNOpenSourceWeek

(OSPOs for Good / Parts that were available for remote participation)

Transparency → Intent → Speed:

• Transparency — is about being aware of what’s going on, and creating the correct feedback loop to discuss and design improvements.

• Intent — Transparency enables intent. The second clear trend that comes out is that teams that are intentional about parts of their engineering process are rewarded.

• Speed — is the tip of the pyramid. Going fast is only helpful and sustainable when you are going in the right direction (intent) and you have a good feedback loop to steer your practices if needed (transparency).

Good teams are fast, but fast teams are not necessarily good!

(Luca Rossi / January 15, 2025 / Refactoring.fm / permalink)

#2

• "Messy middle"—that space where you're both leading a team and reporting to senior executives.

• It's a position that requires a delicate balance, a nuanced understanding of people, and the ability to adapt your approach depending on who you're interacting with.

• When you're leading a team of managers, you're not just responsible for their output—you're stewarding their hopes, dreams, and professional growth.

• Creating opportunities for your team members to shine is key. Whether it's through challenging assignments, public recognition, or simply giving them the space to lead, it's important to be everyone's cheerleader.

  • Leadership can be lonely, and it's easy to get lost in the needs of others. Remember to carve out time for your own development and well-being.

• Managing up to senior executives is a different beast altogether. SVPs and C-suite executives are often focused on the bigger picture—the strategic direction of the company, high-level results, and key business outcomes.

  • Different executives have different styles, and part of your job is to adapt your approach to meet them where they are. Some may prefer high-level summaries, while others might want to dive into the details.

• The ability to change your style and delivery based on the person you're talking to is crucial. It's about meeting people where they are—whether they're on your team or in the executive suite.

• This means being flexible, not just in how you communicate, but in how you lead. Some team members may need more guidance, while others thrive with autonomy. Similarly, some executives might value data-driven discussions, while others are more swayed by narrative and vision.

• Embrace feedback as a way to grow—both for yourself and your team. Encourage open dialogue, and be receptive to criticism. It's not always easy, but it's through constructive feedback that we become better leaders.

• This decision-making process often involves considering the broader implications of a situation. Will standing your ground on this issue benefit your team in the long run? Is it aligned with the company’s goals? Sometimes, it's better to let go and focus your energy on what truly matters.

• It's a privilege to be in a position where you can influence the professional lives of others. But with that privilege comes the duty to lead with integrity, empathy, and a focus on the long-term success of your team. Your leadership has a direct impact on their satisfaction, growth, and career trajectory.

(Amy Crook / August 15, 2024 / LinkedIn / permalink)

• The Berkus Method: Valuing Potential Over Revenue

  • Here’s how it works: investors break your startup into five categories — the idea itself, the strength of your team, how far your product has come, the product’s launch readiness, and any strategic relationships you’ve lined up.

  • Each category is assigned a dollar amount, often up to $500K each. Add them together, and that’s your pre-money valuation.

  • Founder tip: Use Berkus as your early narrative, not your final pitch.

• Comparable Transactions: The Startup "Comps" Approach

  • This is one of the most common methods used by VCs, bankers, and acquirers, and for good reason.

  • Find relevant deals, extract the valuation multiples (like revenue or user-based), and apply them to your own numbers. For example, if SaaS startups at your stage are getting 8× ARR and you’re doing $2M ARR, your implied value might sit around $16M.

  • But here’s the catch: good comps are hard to find.

  • Founder tip: Use comps as a credibility tool, not a crutch.

• Scorecard Valuation: Adjusting for Local Strengths

  • What’s the going rate for startups like yours in your region? If most pre-seed rounds in your city are getting $3 million pre-money, that becomes the baseline.

  • From there, investors adjust up or down based on how your startup stacks up against others in key areas, like team quality, market size, product, traction, and competitive landscape. Each factor has a weight. Maybe the team counts for 25%, the market size for 20%, and so on. If your team is stronger than average, that part gets a boost. If your go-to-market looks weak, that portion might get docked. According to Eqvista, some of the most common scorecard criteria are:

    • Board, entrepreneur, the management team – 25%

    • Size of opportunity – 20%

    • Technology/Product – 18%

    • Marketing/Sales – 15%

    • Need for additional financing – 10%

    • Others – 10%

  • Founder tip: Have your data ready; know the average valuation in your area and stage.

• Cost-to-Duplicate: Rebuilding from Scratch

  • This method asks a basic but important question: how much would it cost to build your startup from the ground up, today?

  • The Cost-to-Duplicate approach estimates the value of your business by adding up everything it took (or would take) to recreate it. That includes engineering time, salaries, tech infrastructure, R&D, hardware, patents, and other tangible investments.

  • Founder tip: Calculate your cost to build and have it handy. It’s a good fallback if investors push back on price. But don’t stop there. Anchor the conversation in traction, market size, and vision to push beyond the minimum.

• Risk Factor Summation: Quantifying Uncertainty

  • This method takes a structured approach to something every investor already does - assess risk. The Risk Factor Summation Method starts with a base valuation, often the average pre-money for startups at your stage, and adjusts it up or down based on 12 specific risk categories.

    

  • Founder tip: Ask which risks matter most to an investor. If you can mitigate or reframe those concerns, you may be able to shift the math in your favor.

• Discounted Cash Flow (DCF): The Financial Forecast Model

  • one of the most rigorous valuation methods out there. It’s built on a simple idea - a business is worth the money it will generate in the future, adjusted for the risk of actually getting there.

  • This method is great for startups with steady revenue and visibility into growth, typically post-Series A or later. But in early-stage deals, DCF often falls apart.

  • Founder tip: DCF can help you understand the long-term economics of your model.

• Venture Capital Method: Exit-Driven Estimation

  • The Venture Capital Method works backward from the endgame. It starts with a projected exit, through acquisition or IPO, and calculates how much a VC needs to invest today to hit their target return.

  • 6 steps:

    • Estimate the Investment Needed

    • Forecast Startup Financials

    • Determine the Timing of Exit (IPO, M&A, etc.)

    • Calculate Multiple at Exit (based on comps)

    • Discount to PV at the Desired Rate of Return

    • Determine Valuation and Desired Ownership Stake

  • Founder tip: Know the math investors are doing behind the scenes. You can’t control their return targets, but you can influence the exit assumptions. Make a credible case for why your business could be a $100M+ outcome, and back it up with market logic.

• Book Value Method: Net Worth of the Startup

  • This one’s as old-school as it gets. The Book Value Method calculates your startup’s value by subtracting liabilities from assets, essentially, what the company is worth on paper if it shut down today.

  • Founder tip: Don’t lead with book value unless your assets are a real part of the story. But make sure your books are clean

(Ruben Dominguez Ibar / June 14, 2025 / The VC Corner / permalink)

Dev Interrupted research: We broke the software delivery process into 14 steps across planning, requirements gathering, coding, and release. We asked participants to consider their most recent pull requests, and for each step of the process, we asked participants who completed the task: a human, AI, or both.

• Coding phase shows strong AI integration

  • Regarding writing code, only 33% of developers rely solely on humans, while 67% use AI either wholly or partially.

  • AI is most dominant in writing tests, with 24% of tests being AI driven.

  • Even pull request descriptions have seen high AI adoption, with 53% of teams using AI assistance.

• Requirements and Architecture remain largely human-led

  • Task creation is still 68% human-led, architecture decisions remain 64% human-driven, and the critical question of "what to build" is still 70% human-determined.

  • These numbers suggest that teams trust AI with implementation but hesitate to involve it in strategic decision-making.

• Review and Release present the biggest bottleneck

  • Code review remains 51% human-only, while merge approval is 77% human-controlled.

  • Similarly, human workflows constrain release management, with 70% of releases being human-led.

  • AI can accelerate code creation, but traditional gatekeeping processes haven't evolved to handle the increased throughput.

• Teams have successfully adopted AI where the risk is low and the output is measurable (coding, documentation, testing), but remain cautious about areas requiring judgment, creativity, or strategic thinking. The question for engineering leaders is whether this caution is justified or whether it's leaving significant value on the table.

• Organizations like Deloitte have reported reducing unit test time by 70% through agent interactions, while others have compressed documentation cycles from weeks to days.

• This level of autonomous operation extends beyond coding into areas like debugging, system administration, and even architectural analysis. However, it raises crucial questions about oversight, security, and the skills developers need to maintain as AI capabilities expand.

• Implementing AI across the SDLC requires a cultural approach that embraces experimentation and healthy skepticism.

  "The enthusiasts need to pull the skeptics up, and the skeptics need to pull the enthusiasts a little bit down to earth." —Birgitta Böckeler.

• AI can significantly enhance quality and velocity in organizations with strong development practices.

• However, AI may accelerate the creation of technical debt or security vulnerabilities in systems with underlying issues.

• The sparring partner model, where AI serves as a thought partner rather than a replacement, has emerged as particularly effective.

• One of engineering leaders' most significant challenges is managing expectations around AI productivity gains. The focus on percentage improvements and speed metrics can create counterproductive pressure that leads to corner-cutting and quality degradation.

• Engineering leaders must also address knowledge gaps among technical teams. Many developers still don't fully understand the implications of using AI tools, from data privacy concerns to the reality that most AI interactions involve sending code to third-party servers.

• "AI is becoming foundational to how we work; the real opportunity is not replacing people. It's about amplifying individuals, amplifying creativity, and improving the flow through the system." This amplification approach requires several key elements:

  • Transparency and ownership: Clear accountability for AI-generated outputs, with humans responsible for review and validation.

  • Tool selection criteria: Guidelines around which AI tools are approved for use, considering factors like data handling, security scanning, and license compliance.

  • Progressive experimentation: Start with low-risk use cases and gradually expand scope as teams build confidence and competency.

  • Continuous learning culture: Regular sharing of successes, failures, and best practices across the organization.

• The conversation around AI in software development is shifting from tactical tool adoption to strategic workflow transformation. For engineering leaders, this transition requires several key considerations:

  1. First, resist the temptation to optimize solely for speed. Organizations that see the most sustainable benefits from AI focus on overall system improvement rather than individual productivity metrics.

  2. Second, invest in cultural change alongside technical adoption. The most successful AI implementations happen in environments that encourage thoughtful experimentation while maintaining high standards for quality and security.

  3. Finally, think systematically about bottlenecks across the entire SDLC. The gains from AI-accelerated coding can be undermined by manual processes elsewhere in the pipeline, requiring a holistic approach to workflow optimization.

(Andrew Zigler & Ben Lloyd Pearson / June 12, 2025 / Dev Interrupted - Linear B / permalink)

#2

Paymonade.tech - Delete account feature / experience:

• Delete account to Paymonade is not available through the site. The user needs to request it via e-mail

• They reply with a Google form that needs to be filled.

• NOTE:

Please note that once deleted the account cannot be restored. Additionally there is a 1-year cooling period before a new account can be created using the same credentials

• Book suggestion: Scaling People by Claire Hughes Johnson.

• "leadership is disappointing people at a rate they can absorb", typically attributed to Ronald Heifetz and Marty Linsky.

• Disappointment is the part of the performance process that leaves a lasting sour taste for managers and their staff, and it is particularly acute for top performers who can never quite get everything they desire, no matter how hard they work.

• Managing a team of any size — from a handful of people to a whole company — is a continual balance between trying to empower people to achieve what they want (interesting projects, plentiful opportunities, a plethora of pay increases and promotions) whilst navigating a conflicting reality that doesn't always want to give it to them.

• If you run a large team, there are so many zero-sum situations stemming from limited resources, strategic decisions, your customers, or the market that you can't control.

• The Dissapointment Frontier can grow in size for a number of reasons:

  • You act as a buffer or protector of your team, shielding them from the reality of a situation.

  • You project an illusion of control over things that you can't control in order to make your team trust you more, or even just to convince yourself things are more certain than they are.

  • You try to implement a team culture that is far removed from the rest of the company culture.

  • You overpromise on what you can deliver to your team.

• It turns out that by practicing the skills that you need to be a more effective manager, you can also reduce the size of the frontier.

  • Overcommunicate: The first step is to overcommunicate everything that you can from your unique position at the top. Context is key.

  • Own It Or Be a Collaborator: This leads into the next key strategy: owning what you can control, and being a collaborator on what you can't.

  • Reality Check: nobody is immune. Even CEOs can't control and decide everything: they have to manage their own disappointment frontier with their board and their investors.

(James Stanier / May 24, 2025 / The Engineering Manager / permalink)

#2

An IC on your team says they’re interested in management. What now?

• Start with curiosity: Ask what’s drawing them to management. Do they want to coach others? Take on more responsibility? Or are they assuming it’s the only path to growth? Management is a completely different line of work, so if it’s the latter, this conversation may be a short one. You should explain to them that IC and EM tracks are (and should be) separate, and career growth is possible without moving into management.

• Reflect on what they’re already doing: Are they mentoring teammates? Stepping up in group settings? Communicating clearly? You’re not looking for perfection, just signals that they’re thinking beyond their own work. If not, this is an excellent place to start. “Do the job you want” is common in management, and senior leaders want to see potential for management. Leading without authority is an excellent opportunity for them to practice management.

• Be real about the job: I think we all know that management isn’t coding plus meetings. It’s a shift away from solving problems yourself to helping others solve them. For some, it’s entirely just meetings and no code. (That’s my life!) A lot of new managers struggle with this transition from projects to people—not because they can’t lead, but because they miss the craft. Make sure this is something they’re willing to forego.

• Try a test drive: Give them a scoped opportunity to practice leadership: mentoring a teammate, owning a small project, running a retro. Then talk about what felt good and what didn’t. You’ll want to give them plenty of opportunities to see how they do and if it’s actually something they’re interested in.

• Talk about what’s next: Maybe the timing is right. Maybe it’s not. Either way, show them you’re invested. Support their growth, even if they stay an IC. Remember, promotions require a personal fit AND a business fit to move forward.

(Kelly Vaughn / June 10, 2025 / The Modern Leader / permalink)

#3

There are at least three perspectives from which we can approach incentives:

• When cooperating with other teams

  • Incentives and motivations.

  • KPIs (Key Performance Indicators).

  • OKRs (Objectives and Key Results).

  If something is unclear, nothing helps me more than having an honest conversation, where active listening plays a crucial role. You can directly ask the following questions to gain clarity:

  • What is important to you?

  • What are your measures of success?

• When mentoring your team

  • If recognition is their driving force, organising a company-wide event could address it.

  • If it's money that motivates them, providing them with opportunities to earn more may address it.

  • If their focus is on learning, ensuring they have ambitious goals that allow them to explore new technologies may address it.

• When planning your own career

  • To shape our careers, it is important to understand what drives us.

(Michał Poczwardowski / May 26, 2025 / Perspectiveship / permalink)

10 career levels for software engineers

• Engineer I: As a first-level engineer, you may be working as an intern or a junior software engineer.

• Entry-level software engineer II: Entry-level software engineers are usually considered to be at engineering level two. With this rank, a person must have the foundations of engineering, programming and software development. Engineers at this level typically spend two or three years developing their technical and professional skills before moving on or being promoted to a job or role as a mid-level software engineer.

• Mid-level software engineer III: Level three engineers, or mid-level software engineers, expand upon their foundational knowledge and develop an understanding of best practices for writing code and developing computer software. They can work independently and regularly assist level one or level two engineers with task-related or troubleshooting problems. People at this level of their careers often have three to six years of experience as software engineers.

Advancing on a technical career track

When software engineers have between four and seven years of experience, they might be selected by their employer to move forward in their career and move up in level and job title.

• Staff engineer IV: This is a high-level position, and people selected for this type of job need to have a comprehensive knowledge of software development practices, and they must have mastery over writing code and debugging code. Engineering at this level includes performing complex programming tasks and implementing software systems. The job is often highly collaborative and may include leading teams or mentoring more junior engineers.

• Senior staff engineer V: People working in these jobs typically have a minimum of seven or eight years of experience in their field. They should have the ability to perform programming tasks and large engineering projects with Independence and expertise. Level five engineers, or senior staff engineers, are often responsible for guiding or mentoring other staff members, and regularly lead technical projects for the clients that their companies serve.

• Principal engineer VI: Principal engineers hold the highest position or level on the technical engineering career track. They are highly advanced software engineers who make important product decisions regarding direction and scope. They make strategic decisions about which team members should work on which areas of a project and they provide technical and professional leadership for the engineers who report to them.

Advancing on a managerial career track

• Engineering manager IV: Engineering managers regularly lead teams or projects, and they provide support for initiatives throughout many areas within a company. They regularly have seven or eight years of experience in software development, and they must have a broad understanding of all aspects relating to the design, innovation and development of software products and solutions. They should be able to prioritize workloads, tasks and assignments to efficiently manage team projects.

• Director of engineering V: are responsible for managing multiple teams and coordinating with team leads or engineer managers. This person must have a keen understanding of the broad picture behind the company initiative and the company development goals. They must also have an expert-level understanding of programming, code languages, troubleshooting practices and innovative design theories. People in this position often have eight to 10 years of experience as software engineers or developers and should also have two or three years of experience in leadership positions.

• VP of engineering VI: A person in this role is a high-level executive who manages teams of software developers, programmers and technology assistants. These people are responsible for designing and delivering products and solutions that meet the needs of their clients. The vice president of engineering must also have tactical and strategic expertise, as well as strong interpersonal and leadership skills. Typically, a person in this role has over 10 years of experience as a software developer and team leader.

• Chief technology officer: Chief technology officer (CTO) is the highest executive position within the technology or engineering department of a company. The CTO handles all final products developed by the engineering staff and is responsible for the professional and technical development and career growth of all reporting employees. They must have programming, software development, innovative design and strategic management expertise.

(Ref: Indeed)

#2

The framework relies heavily on radar charts to visually represent the different perspectives and expectations of a given position:

The framework has 4 different ladders:

• Developer: role also known as programmer or software engineer, requires a deep level of technical expertise

• Tech Lead: role also known as dev lead, is the owner of the system and requires a unique balance between hands-on development, architecture knowledge and production support

• Technical Program Manager: role responsible for coordinating and driving to completion initiatives that span multiple teams

• Engineering Manager: role also known as dev manager, is responsible for the consistent delivery, career growth and level of happiness of the team

The chart shown above has the following 5 axes:

• Technology: knowledge of the tech stack and tools

• System: level of ownership of the system(s)

• People: relationship with the team(s)

• Process: level of engagement with the development process

• Influence: scope of influence of the position

The influence axis can be seen as a different dimension since it is orthogonal and applies to all the other axes.

Each axis has 5 different levels of performance. It is important to highlight that every level includes the previous one(s). For example, someone that evangelizes technology, specializes and adopts it as well.

Tech Lead vs Engineering Manager

(Ref: engineeringladders.com)

#3

tl;dr 👇

Roles up to and including Senior, ladders are constructed around becoming the best at what one does that one might personally be.

At Staff level, the career expands to help others be successful with what you do and know, and scale yourself.

At Principal and beyond, you are trying to help others be the best that they can be, removing yourself and meeting others where they are.

The Engineering

• Engineer I

• Engineer II

• Senior Engineer

• Staff Engineer

• Principal Engineer

• Distinguished Engineer

• Misc: Tech Lead

Developer Experience

• DX Engineer I

• DX Engineer II

• Senior DX Engineer

• Staff DX Engineer

• Principal DX Engineer

• Distinguished DX Engineer

• Misc: Tech Lead

Documentation

• Technical Writer I

• Technical Writer II

• Senior Technical Writer

• Staff Technical Writer

• Principal Technical Writer

+ Sarah Dresden is explaining the rational behind this career ladder system in this post

(Ref: career-ladders.dev)

#1

How do you distinguish between authentic human writing and GenAI generated text?

• Spectrum of Human-Synthetic (AI) Generated Writing

  • Human writing

  • Human-in-the-loop writing (HITL)

  • Machine-in-the-loop writing (MITL)

  • Synthetic writing

• Before using AI Detectors (i.e. GPTZero), Consider:

  • How do AI detectors support your learning outcomes and goals?

  • What’s the purpose of using AI detectors, and can you articulate this purpose to your students?

  • How might AI detectors disrupt or enhance trust and transparency in your student-teacher relationships?

• Avoid surveillance pedagogy. Use AI Detectors to start a conversation.

Notes:
- GenAI usage is invevitable in university nowadays.
- There's an ongoing debate on whether rules for using GenAI should be established in the context of semester assignments, theses and so forth.
- No official guidelines exist today on a university, national or international level to the best of my knowledge.
- "Avoid surveillance pedagogy. Use AI Detectors to start a conversation." -> This is a really good approach. Education should push students to make good use of the available tools, not penalizing their use.

#2

How do you set the tone of the learning environment in your classes?

• Music playing; while people come to class.

• What uses of GenAI cause the following:

  • Critical inquiry (reward to critical enquiry and course values).

  • Pain point (fails to meet our values and expectations, a minor inconvenience).

    • i.e. Citations used in assignments by students do not exist due to AI hallucination.

  • Harm (use violates our scholarly values, removes human from critical inquiry and problem solving).

    • i.e. When the paper is fully done by AI this is a harm since no experience was gained by the student.

Notes:
- "Music playing; while people come to class." It is useful! I am playing Baroque music during the lectures as well and it seems to have helped students focus better.
- The challenge is to lead students (reward?) to want to use GenAI to benefit from it rather than "get the job done" and move on.

#3

How might academic integrity complaints without thoughtful conversations with students, about inappropriate generative AI use, be the antithesis of engaged pedagogy?

• File complaints after a process of understanding

  • the context of inappropriate use,

  • the student’s reflection on how GenAI use did or did not further the values of the learning community and

  • GenAI’s risk to student learning for self-actualization and world transformation

• How does the use of AI impact the learning of the student?

  • i.e. if the student over-relies on AI, they don’t learn from experience.

• Rhetorical listening

  • understanding the experience of someone’s perspective of the world to arrive at truth

  • the antithesis of passive listening, which often seeks to further evidence and win a conversation from your own single perspective

  • emphasizes understanding, diplomacy, and communicating across cultures to seek ethical and justice-informed decisions

Notes: 
- The concept of "Rhetorical Listening" is interesting!

#4

Other approaches:

• Metacognition

  • Before using GPT Zero: Ask students to annotate their draft for you, focusing on the rhetorical choices

  • After using GPT Zero: Students who meet a threshold of suspected GenAI use (for example, 6% probability), revise and annotate their draft for you, focusing on the rhetorical choices they made along the way

  • Reminder: The benefit of college education is doing deep internal work about your failures and successes, not just getting work done.

Notes:
- This seems to be a good first approach on solving the problem of not penalizing the use of GenAI but rather hold the student accountable for using it. 
- By using thresholds the educator legitimizes their potential request to the student for the essay to be re-written. 
- On the oter hand this tactic may lead the students to try and find better ways to "fool" the system, instead of doing the actual work.

References:

• Framework for the Future: Building AI Literacy in Higher Education (Moxie 2025)

3 Crucial Questions to Define Your Product Strategy:

1. Which customers or users do we want to target now?

2. Which of their problems do we want to solve with this project now?

3. When do we want to give those customers those solutions?

While the product leader should answer these questions, they don't always know the answers. That’s why I like it when the project manager also asks these questions to create a successful project.

(Johanna Rothman / May 21, 2025 / ProjectManagement.com - PMI / permalink)

Notes:

- How many times should these questions be asked as the requirement travels from the vision/strategy realm (usually top management) to the engineering department to be implemented?

- Why, while the first 2 questions are positioned in now, the 3rd one is about when?

- Is this about scope? Can the aforementioned questions - when repeatedly asked by different stakeholders as we move from requirement to be implemented feature - define scope better?

- If scope is identified correctly, could this help a company to better handle work in progress (WIP)? Could it perhaps lead to cleaner and more modular code? 

- How can we use them in our companies? Which roles of our Engineering department could ask these questions? Which roles in our companies (more broadly) could provide more clarity on these questions?

#2

Next time you’re about to share an idea—whether in Slack, a meeting, or a doc—pause and ask yourself:

1. What’s the point?
   Write it in one sentence. If you can’t, you’re not ready to share it yet.

2. Why should they care?
   Make sure the framing speaks to their priorities (not just yours).

3. Is it structured clearly?
   Put the most important thing first. Then add context or supporting details.

(Irina Stanescu / May 15, 2025 / The Caring Techie Newsletter (Substack) / permalink)

Notes:

- I guess writing Slack posts are like talking to people for remote teams! So yeah, the above probably applies here as well... perhaps even more so than a face-to-face meeting...

- "Make sure the framing speaks to their priorities (not just yours)." Easier said than done. Sometimes the manager's audience includes diverse roles and yet the message and the medium (i.e. same generic Slack channel) are the same for every target group :/ 

- Call to Action: These points are gold for change management situations. I should revisit past announcements related to change management to see if my message was clearly and appropriately framed for each audience.

#3

Before you stand in front of an investor, you need to ask yourself a few key questions:

1. Are you solving a real problem?

2. Do you have a solution that adds value?

3. Has anyone thought that before you?

4. Do you truly understand your market?

5. Do you have a strong team?

6. Can you tell a story?

7. Bonus: Pay attention to your visual image.

(Odysseas Spyroglou / May 16, 2025 / The Generalist Papers (Substack) / permalink)

Notes: 

- Odysseas is giving advice to founders / makers / teams interested to receive funds from VCs. Which means we are mainly in the startup realm.
- What if the same advice can be used in the context of larger, corporate-level SaaS companies, that want to add new, innovative features to their products and potentially unlock a new market, or better position themselves in a market they are already targeting?
- How could these points internally help the company's stakeholders think and operate like 'startups', regardless of the size of their products or businesses?
- Can this pitching template be a guide to an aspiring product manager, business developer or sales representative that wants to propose a new feature or product to their leadership?
- How can a company nurture such a mentality internally? Occasional hackathon? Occasional 'pitch' or 'fund your idea' days?

#4

Thoughts: 

❓ Are the kinds of agile methodologies at company practices, relevant / important today?

❓ Are the job titles or roles in engineering at tech companies, important or even relevant today?

❓ Is visibility of a product, an opinion, or its implementation a motivator for a team member?

#5

Let's briefly revisit the fundamentals. Westrum's typology classifies organizations based on how they process information:

• Pathological: Driven by power and fear. Information is hidden, blame is rampant, and cooperation is scarce.

• Bureaucratic: Ruled by processes and policies. Safe but rigid. Problems get stuck in formalities.

• Generative: Focused on mission and performance. Information flows freely, mistakes are learning opportunities, and collaboration is high.

DORA research has shown that organizations with generative cultures have 30% higher organizational performance.

(Mirek Stanek / May 19, 2025 / Practical Engineering Management / permalink)

Notes:

- Could it be that the 30% statistic is due to the sample consisting mainly of startup companies? 
- Could the generative model be efficient for larger software companies (complex in structure and encapsulating several departments and teams)? 
- When a company grows from a startup to a more mature or corporate institution, what is the balance between generative / bureaucratic elements?
- "Westrum's typology classifies organizations based on how they process information". (How) is information processing correlated with governance?

I recently participated in this fascinating discussion on LinkedIn initiated by Mr. . Here are my key takeaways.

TL;DR: If AI can do (fully or partially) the work of engineers, why lay them off instead of scaling innovation?

For years, at technology companies, we struggled with hiring and retaining engineering talent. Developers were the lifeblood of product velocity. Organizations built processes, teams, and entire operating models to optimize their software development life cycle and get the most from their development team(s).

Now that AI is gradually taking its place in the software development life cycle (SDLC), we can expect that this will amplify productivity. So, what should companies do when we reach a point where a single engineer can do the work of five?

Should they see this as an opportunity for compounding innovation? Or should they see a good reason for cost-cutting and reducing headcount?

If engineering is no longer the bottleneck - since AI enhances skills and increases capacity without the need for new hires - why are profitable companies cutting developers instead of aiming to be more innovative?

The Illusion of Efficiency Gains

Beware of this dangerous assumption: fewer engineers delivering the same output equals a more efficient company.

This assumes that value is linear, that productivity equals impact, and that once a feature is shipped, the job is done. But software isn’t a factory assembly line; it’s a living system.

If engineering becomes 5X faster (e.g., through AI integration in the software development process), but the company lacks a clear vision, strategy, and well-aligned goals across departments—especially product, marketing, and sales—then increased development speed adds no real value.

Productivity and value creation are not the same thing. Just because an engineer can ship faster doesn’t mean the market can absorb 5X more features or that the company knows what to do with the excess capacity.

Short-Term Thinking is a Silent Killer

Beware of this dangerous trade-off: Short-term gains over long-term sustainability.

• Sometimes, quarterly earnings dictate decisions. A company is a business that needs to be financially healthy. But sometimes, striving to make numbers look good for the next financial report instead of innovating can lead to missing the “next wave”.

• Sometimes, we mistake maintenance mode for innovation. Many companies today exist not to build the future but to sustain the present. They maintain legacy systems, avoid risks, and operate in fear of disrupting their inertia.

Hypothesis: What if, instead of shrinking engineering teams, we leveraged the extra capacity?

Companies that get this right will:

• Align engineering with strategic business goals. The question shouldn’t be “Do we need fewer engineers?” but “How do we deploy their productivity in the most impactful way?”

• Empower engineers to solve business problems. Instead of cutting headcount, give engineers a seat at the table to rethink workflows, processes, and revenue-generating opportunities.

• Break the cycle of short-term decision-making. Layoffs might create a quick financial win, but they cost trust, momentum, and the very innovation capacity companies need to survive.

Beware of this sad truth: the companies cutting engineers today are creating their own future competition.

We should look at AI as an accelerant, a high-tech prosthesis, if you like, that can upgrade the average professional’s skillset and give superpowers to a high performing professional.

AI, however, is not a replacement for good business thinking. This alongside strategy and good leadership, should come (for now) from the human factor!