As TPM there is no Hiding from the Code

Two distinct paradigms have emerged in software development: the "corporate" approach and the "open-source" approach. These two environments represent fundamentally different ways of building, organizing, and managing projects. Within the corporate world, the technical project manager (TPM) position is often set within a layer of protection from the outside world. In this walled garden, teams operate safely behind layers of process, proprietary tools, and internal repositories. In contrast, the open-source maintainer operates in a public space where talent is drawn from a global pool, and the success of a project depends on sustaining that talent and keeping the quality of contributions at the highest level.

This article tries to explore the critical differences between the traditional corporate TPM and the open-source maintainer, focusing on why the maintainer’s approach - rooted in hands-on interaction with code and daily engagement with contributors - might become future of effective project management in the age of generative AI.

Safe in the Walled Garden

The traditional corporate TPM exists within a "safe" and controlled environment. They oversee teams that develop software inside walled gardens. Repositories are locked behind corporate firewalls, CI/CD pipelines are managed internally, and project management tooling is tailored to the company’s unique processes. In this world, the focus is on predictability, managing resources, adhering to timelines, and ensuring that teams stick to well-defined processes. The rules and the hierarchies are clear, and success is often measured in compliance with pre-set milestones rather than the innovation or creativity of the developer team.

In such an environment, a TPM can often hide behind these processes. Their job becomes managing people and numbers, ensuring deadlines are met, resources are allocated, and budgets are adhered to, without the need to dive into the technical details of the codebase. The development happens at arm’s length, and the TPM can avoid engaging in technical discussions or code reviews by relying on other roles (engineering leads, architects, etc.) to handle the technicalities. In this approach, the TPM becomes a gatekeeper of the project’s progress but is not necessarily a critical player in the day-to-day evolution of the product itself.

This "walled garden" approach fosters a (possibly fake) sense of safety but also leads to stagnation. Developers operate within set boundaries, corporate processes often constrain innovation, and the TPM’s role becomes administrative oversight rather than technical engagement. It’s a model that works in the corporate world, where established products drain predictable cash from well-trained communities of customers. Still, it does little to nurture creativity, agility, or deep technical understanding, which are becoming essential in today’s fast-paced, AI-driven product development landscape.

Custodians of Innovation

In stark contrast to the traditional TPM, the open-source maintainer lives in a completely different world where there is no safety net of corporate processes, and everything is built in the open. Open-source projects are highly visible, and the code is available for anyone to see, critique, or contribute. The success of an open-source project depends on the community’s trust in the code's quality and the maintainers' leadership, who must guide the project without the authority or safety of a corporate structure.

In this environment, a maintainer has no choice but to engage deeply with the code. They must review every commit that comes in, ensuring that each change maintains or improves the quality of the project. Unlike the corporate TPM, who can delegate code reviews and focus on process, the maintainer is at the forefront of technical decision-making. They ensure that every contribution aligns with the project’s vision and standards and, by doing so, earn their cognitive share in the overall fabric of the project.

Maintainers must actively participate in the global developer community, engaging in discussions with contributors worldwide. These developers come from diverse backgrounds and skill levels, bringing new ideas and fresh perspectives. To attract and retain talented contributors, maintainers need to foster a sense of collaboration and shared purpose. This means constantly conversing with contributors, understanding their motivations, and providing guidance that maintains technical quality and inspires innovation.

In an open-source project, the maintainers don’t manage people or numbers; they manage relationships, ideas, and code quality. They must earn the trust of their community through transparent decision-making and technical leadership. This requires them to be in the trenches, reading every line of code and making technical decisions that will affect the project’s future. In this way, the maintainer’s role is far more hands-on and technically engaged than a traditional TPM.

Why a Maintainer SHOULD Read Every Commit

In the open-source model, the maintainer’s success is directly tied to the capabilities and willingness of contributors to engage with and enhance the project. Unlike in the corporate world, where a TPM can replace underperforming developers with more capable candidates if the budget allows, the maintainer has no such luxury.

Therefore, a reasonable strategy for any maintainer is to read every commit. Maintaining technical quality is not simply a matter of maintaining technical quality; it is also about sustaining the health of the project’s community. Each commit represents a contributor’s time, effort, and ideas. Ignoring or glossing over these contributions would risk introducing bugs or subpar code and alienating the contributors essential to the project’s long-term success.

By reading each commit, maintainers demonstrate that they value the contributions of every developer, no matter how small. This fosters a sense of trust and ownership within the community, encouraging more people to contribute and invest in the project’s success. In this way, reviewing commits becomes a form of community building—an essential task for any open-source project that hopes to thrive.

There is no Hiding from the Code

As generative AI tools become more prevalent and development speed increases, the distinction between traditional project management and open-source maintenance will blur. In the age of GPTs and AI-driven development, no project manager - whether in the corporate world or open source - can avoid engaging with the codebase. AI tools like GitHub Copilot and GPT-based assistants will increasingly automate many manual coding tasks, making it more critical than ever for TPMs to understand the direction in which a project’s code is headed.

This shift means that traditional TPMs, who rely on corporate rules and processes to manage projects, will need to evolve. They will need to become more like open-source maintainers, engaging with the code, participating in technical discussions, and understanding the implications of every commit. In the future, effective project management will be defined not by the ability to manage people and processes but by engaging with and guiding a project's technical direction.

The walled garden of corporate software development will not survive in a world where AI-driven development moves at breakneck speed and talent is global, distributed, and constantly evolving. In this new world, the TPM must become a hands-on leader unafraid to get involved in technical details. The maintainer’s approach - deeply engaged, technically savvy, and community-focused - represents the future of technical project management.

The Maintainer’s Model as the Future of TPMs

The traditional TPM role, rooted in corporate structures and processes, is increasingly irrelevant in a world where generative AI and open-source models drive innovation. The future belongs to those who combine technical expertise with leadership, are not afraid to dive into the code, and understand that managing a project means managing relationships, ideas, and quality, not just numbers and timelines.

The maintainer’s role in open-source projects offers a model for the future of technical project management. By engaging directly with the code and fostering a global community of contributors, maintainers embody a more dynamic, agile, and technically grounded approach to project leadership. As the lines between corporate and open-source development continue to blur, TPMs must adopt the maintainer’s mindset or risk becoming obsolete in the fast-paced world of AI-driven development.