Despite the growing popularity of both Agile development and open-source practices, it’s not often that they come up in the same conversation. When these two concepts do intersect, it’s often to highlight the contradicting viewpoints that these two models supposedly represent.

While there are core differences, Agile doesn’t have to be the enemy of open source—in fact, I would argue the opposite.

RELATED CONTENT: The many faces of Agile

Layering the core concepts of Agile development on top of open-source development can not only drive more transparency and collaboration across a project, but drive higher engagement, thereby increasing the value of the project for everyone involved. 

Are Agile and open source really at odds?
Much of the way we approach Agile programming today comes from the Agile Manifesto—a charter that highlights the core tenets of what it means to be “Agile.” Above all else, the Agile Manifesto emphasizes four key principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

It’s these first two principles that often seem to clash with the way that most open-source projects are structured. 

First, while Agile programming heavily emphasizes co-location and the importance of face-to-face interactions, open source is built on the very idea whereby anyone, anywhere, with any level of background can meaningfully make contributions to a project.

Second, Agile emphasizes working code over comprehensive documentation, but open source requires documentation in order to help provide history around the project and to help potential contributors understand where to get involved.

Despite these differences, Agile programming doesn’t have to be viewed as a juxtaposition to open-source development. In fact, bringing these core tenants of Agile into open source development can result in a number of benefits.

Establishing and understanding process
Given the distributed nature of open-source projects, maintaining order and focus is one of the most difficult jobs for open-source maintainers. For collaborators, knowing what to work on and understanding the guidelines for contributing to a project are similarly important. In this way, creating a lightweight process around how work is prioritized and progress is tracked is critical to every stakeholder involved in the project.

Integrating a simple Agile framework (like Scrum or Kanban) into the project helps contributors better understand the process that work has to go through in order to be merged into the project. When paired with a set of contribution guidelines, a simple framework goes a long way in helping to build confidence among potential contributors to get involved and to know where to make the biggest impact.

Providing stakeholders visibility 
Few things are more off-putting to potential collaborators looking to contribute to a project than not being able to understand if the project is still active and worth their time for a contributed effort. Integrating agile components into projects provides potential collaborators with a quick pulse regarding the activity of a project, good first Issues to contribute to, and which Issues could be the highest priority for the project. 

For example, agile elements such as a lightweight task-board provide visibility into where a particular Issue or pull request (PR) lives within the workflow of the maintainers. Rather than submitting a PR and waiting for a comment or notification that the PR was merged, contributors follow along with their Issue in real time on the board and understand how it’s being prioritized against other merge requests that have been submitted to the project.

Measuring velocity and improving predictability
While it’s true that the distributed nature of open-source projects prevents them from moving as fast as their commercial counterparts, it doesn’t mean that open-source projects shouldn’t aim to continuously improve in velocity and become more predictable in their releases. While it might not be realistic for certain open-source projects to organize work into sprints or iterations, there are other agile metrics, that, when leveraged properly, can help projects measure and improve velocity and release predictability.

One such example is lead time and cycle time. These two metrics provide teams with the ability to measure how long it takes from when an Issue or ticket is first created (or first worked on) to the time that it’s completed. Lead time and cycle time can also help maintainers to identify outlying or stale Issues. If an Issue has been open longer than the average lead or cycle time, this might signal that the Issue is no longer relevant, or should be flagged as needing additional support from the community.

Bringing Agile concepts into open-source projects
Today, most major open-source projects are hosted on GitHub.com, and if you want to contribute to a project it’s likely that you’ll have signed up for a GitHub account. 

Beyond having a thriving community of nearly 38 million developers, GitHub has gained popularity within the open-source community as it provides the fundamental building blocks that most teams and projects need to collaborate and communicate in a distributed way.

In addition to the fundamentals that GitHub provides around Issues and PR’s, there’s also built-in functionality within GitHub (and through its ecosystem) that can help teams incorporate agile elements such as task boards, reports, and more into their open-source projects. 

GitHub Projects is a native feature within GitHub that provides teams with a lightweight Kanban board on top of GitHub Issues. GitHub Project boards can be customized to allow projects to model out a simple agile process and communicate to the community the different stages that work has to go through before it can be approved and merged.

Because GitHub Projects are built into GitHub they are the natural choice for most lightweight open-source projects that want to provide stakeholders, and the broader community, with updates around the project. For open-source projects, GitHub Projects are easy to create and are a great first step in bringing a more Agile way of working into GitHub. 

In addition to GitHub Projects, a robust marketplace of third-party tools is available to augment GitHub with project management features on top of Issues and PR’s, providing teams with the ability to organize Issues into Epics, assign Estimates, track analytics, and more.  Like GitHub, some of these tools are also free for open-source teams. 

Because these tools exist without any limitations of cost or learning curve, they can advance many valuable community-based projects, leading to better, faster results, and provide a framework to help Agile development and open-source practices to come together.