Apr 23, 2023 9 min read

Is OSS a SDLC Methodology?

Does Open Source Software belong in the history of Software Development Life Cycle Methodologies?

Some time ago, I began to wonder if Open Source Software (OSS) could be considered a methodology for producing software that one could "follow." Interestingly, OSS is sometimes listed as a methodology like this (e.g., https://en.wikipedia.org/wiki/Systems_development_life_cycle). My questions led me to delve deeper into software development methodologies to gain a better understanding of how OSS fits into these histories.

When it comes to researching software development methodologies there is no other place to start than the Systems Development Life Cycle (SDLC - sometimes also called the Software Development Life Cycle).

The All Important SDLC

The Systems Development Life Cycle is a framework that outlines the stages involved in the development of software, from its initial planning and analysis to its final deployment and maintenance. The main stages of the SDLC include:

Requirements gathering and analysis
Design
Implementation
Testing
Deployment
Maintenance

The SDLC serves as a high-level 'birds eye view' of the software development process from conception to deployment and maintenance.

The SDLC does not provide detailed guidance on the specific activities that need to be performed at each stage, how they are to be performed, or what the process of transitioning from one stage to another looks like. This responsibility is assumed by software development methodologies such as Waterfall and SCRUM, among others. These methods are often referred to as SDLC methods.

The history of SDLC methods is essentially a story of people endeavoring to discover more effective ways of developing software that suits their particular needs. This pursuit has led to the emergence of diverse practices, with some methodologies prioritizing rigid planning and compliance with predefined processes, while others emphasize adaptability, collaboration, and continuous improvement.

So,..lets dive into a brief history of some software development methodologies that fall under the SDLC framework. I have included below some links to additional materials that I found particularly intriguing during my research on these methods.

Waterfall Model (1970): The Waterfall Model is often claimed to be the earliest SLDC method, follows a linear progression through the SDLC stages. Although straightforward and comprehensible, its rigidity and lack of adaptability are notable drawbacks, particularly due to the placement of testing at the end of the process.

Joint Application Development (JAD) (1977): JAD, introduced by IBM, is a collaborative methodology that involves all relevant parties in requirements gathering, design, and decision-making. JAD sessions often feature facilitated workshops where stakeholders, experts, and developers work together to define project requirements and priorities.

Spiral Model (1986): Barry Boehm's Spiral Model is a cyclical process that uses four critical steps (requirements, identify and resolve risks, development, plan the next iteration) which are used repeatedly. As the project goes forward more knowledge is gained about the project and it iterates forwards in progressive cycles.

Rapid Application Development (RAD) (1991): RAD is an iterative methodology that is sometimes driven by user interface design, often involving input from end users themselves. RAD emphasizes the quick development and delivery of prototypes, allowing user feedback to be incorporated throughout the process, which enables rapid adaptation to changing requirements.

Extreme Programming (XP) (1996): XP was started by Kent Beck as a response to the need for faster software design and production. XP, an early precursor to Agile values, emphasizes "trusting yourself" as a programmer and focuses on optimizing code quality and enhancing programmer satisfaction through its various practices and methodologies.

All of the methods listed above offer a well-defined approach to software development, with clear guidance for navigating the SDLC stages. Each methodology emphasizes distinct processes to tackle specific challenges, and examining methodologies such as JAD and XP can offer valuable insights for software development teams. Some of these methods are thoroughly documented in books such as Extreme Programming Explain published in 1999 by Kent Beck. Other, older, methods, such as JAD, require a little forensic web searching. Some methods have become industries.

So, you might be wondering why Agile is not listed above - more on this below.

Is Open Source Software a Method?

As mentioned above, Open Source Software (OSS) is sometimes categorized as a SDLC methodology. But is it? To address this question, it's helpful to understand Agile's origins and development.

The Agile Manifesto

Agile began as a set of principles outlined in the Agile Manifesto (2001).

Nowadays, the term "Agile" not only refers to these core principles but also encompasses various methodologies that adhere to some of the Agile manifesto principles while borrowing the name to describe their particular approach to software development.

The Agile Manifesto serves as the foundational document for Agile methodologies. The four core values of the Agile manifesto are:

Prioritizing individuals and interactions over processes and tools, which encourages strong communication and teamwork.
Valuing working software over comprehensive documentation, as functioning software is more crucial to users than extensive paperwork.
Focusing on customer collaboration over contract negotiation, ensuring that the development process is aligned with customer needs and expectations.
Responding to change over following a plan, allowing for adaptability and flexibility in the face of evolving requirements.

By embracing these values and principles, Agile methodologies aim to cultivate a collaborative, adaptive, and customer-centric development process. Lean, SCRUM, and Crystal are all SDLC methodologies that embody these principles (as a side note for those interested in the manifesto and the industry of methods that has sprung from it I very much recommend watching this video by 'pragmatic' Dave Thomas). It's also important to point out here that while there are Agile methods that cover the entire software development life cycle, many also focus on parts of the cycle, nevertheless they are all considered SDLC methods.

The evolution of Agile provides a useful lens for understanding Open Source Software (OSS) since OSS, too, can be viewed as originating from a core set of principles.

The Four Freedoms

The foundational principles of OSS are originally encapsulated in the 'Four Freedoms', as defined by the Free Software Foundation:

The freedom to run the program for any purpose (Freedom 0).
The freedom to study how the program works, and change it to make it do what you wish (Freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (Freedom 2).
The freedom to distribute copies of your modified versions to others (Freedom 3). By doing this, you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

The Four Freedoms, either directly or indirectly, along with the Debian Free Software Guidelines, formed the basis for the Open Source Definition by the Open Source Initiative (OSI). These principles have been instrumental in shaping the understanding and expectations around open source software, providing a foundation upon which the broader open source community has grown and evolved.

Cultural-Methods

In essence, the Agile Manifesto and the Four Freedoms serve as core principles or values, and each set has inspired its own culture of software development. While these principles influence the way software is created, they do not prescribe how software should be made, which is the purpose of a method. Instead, the principles allow for a multitude of methodologies to emerge from, or operate within, these core values. Thus, the Agile Manifesto and the Four Freedoms provide the foundation for diverse approaches in software development.

Consequently, I believe OSS is not an SDLC method. Rather, OSS is a set of values that inform a culture of production, much like the Agile Manifesto has. Various SDLC methods have emerged over time from this culture, and they can be described as culture-methods – methods derived from a principled culture to address a specific task (ie. software development).

The Itch-to-Scratch Method

While there are many ways to create open source software, there is a dominant OSS SDLC culture-method. The ubiquity of this model is probably the reason why many people have conflated OSS with it, seeing the two as one. However, it is essential to disambiguate the two.

The dominant model in OSS development is the "itch-to-scratch" approach first described by Eric Raymond in 1999. Adopting the common practice of creating acronyms for method names, we could conveniently refer to this as the ITS method, or ITS for short.

Every good work of software starts by scratching a developer's personal itch.
Eric Raymond, The Cathedral and the Bazaar

In my opinion, ITS should be categorized as an SDLC Methodology in the histories of software development.

ITS emphasizes the following stages:

Requirements assertion (itch) – Developers identify an idea and assert the requirements.
Build (scratch) – Building begins, which might be preceded by some simple system design or more likely proceed towards a proof of concept.
Use – users/developers use or try the software.
Interaction – Interaction between initial developers and newcomers, leading to potential use or contributions. This iterative growth fosters the development of the project's community.

Providing an explicit description of a methodology (even with minimal high level details as above) not only aids in understanding it but also offers a way to evaluate its strengths and weaknesses. Comparing ITS with the SDLC methods mentioned earlier is intriguing as it highlights the differences between them. While ITS boasts several strengths that contribute to its success, there are also notable issues and areas that could benefit from improvement. Some interesting characteristics to consider include:

Projects are developer-initiated and developer-led.
Requirements consider the needs of other developers only after the initial build.
Adoption strategy, if considered at all, occurs late in the process.
Minimal forward looking design in the initial phases.
The model is suitable for technical building blocks but not necessarily for end-user products.
The developer-centric nature often excludes (or makes difficult) other types of contributions.
Design, scope, and strategy is generally guided by the founder's decisions, combined with input gathered through techno-meritocratic and technology driven considerations.

Although the ITS methodology has its limitations, it has had a significant impact on the world of software development. This approach has fueled the growth of open source software and paved the way for new software development processes, making it an essential method that deserves recognition in the history of SDLC methods.

By acknowledging ITS as a specific method with its own set of practices, it can be evaluated for its impact on the software development process and appreciated for its contributions. Conflating ITS with the broader open source movement/culture can obscure its unique features and limit its potential to inform and influence the evolution of software development methodologies. Therefore, it is crucial to distinguish ITS as a specific method and recognize its place as one of the most important SDLC methodologies.

The Importance of Exploring other OSS Culture-Methods

While ITS has had an enormous impact, I believe it is crucial for the OSS movement to explore and recognize other SDLC methods employed within open source development. OSS faces numerous challenges, and while the ITS method has been effective in producing technical building blocks over decades, it may not be the best at addressing other issues.

ITS does not, for example, account for the role of the non-technical user or contributor. How have these been incorporated in other open source SDLC methods as they have been throughout the history of software development practices?

The ITS method's effectiveness is also limited to solving code-related problems and issues within a developer's expertise and interests.

The historical association of ITS with the bootstrap model for starting and scaling projects also somewhat limits conversations about successful alternative approaches, such as non-developer initiated models that secure resources upfront for open-source projects.

Furthermore, we all know sustainability is a crucial issue in OSS. The ITS model has established a clear understanding of sustainable practices in technical building block projects. However the restricted opportunities for newcomers to learn about and imitate other prosperous models or gain insights from their errors constrains the potential of the open-source culture to solve a larger variety of problems sustainably and at scale.

After receiving feedback on various drafts of this article, friends have asked me to suggest other open-source SDLC models. However, while I know many open source projects that do not use the ITS model, I am struggling to present these models succinctly here due to a lack of established discourse and terminology surrounding them. Nevertheless, by way of illustration I will take a stab at one example - tentatively called the 'Expert Driven Development' model.

The Expert Driven Development (EDD) model might be classed as a non-traditional open-source SDLC method, where a domain expert (or group) initiates a project as the founder(s), without necessarily having any background in software development. This approach is well-suited for open source projects that originate, and require expertise, in a specific 'non-software' field, such as healthcare, finance, or education. The primary objective of the EDD model is to leverage industry experience to create a product that addresses real-world problems in these sectors. To kick-start the project, the founding person or group raises funds (via philantropy, donations, or development commissions for example) to hire a development team. The development team works closely with the industry stakeholders to understand the domain requirements and convert them into functional specifications that the team can work on. By combining the expert stakeholders domain knowledge with the development team's technical expertise, the project can create a product that is well-aligned with the target sectors needs.

I present the EDD model as an example of one type of 'non-traditional' open-source software development life cycle (SDLC) approach that does not depend on the ITS method, which I am also aware is prevalent. However, this is only a brief illustration of one of the potential models available, and there is a need for further scrutiny and examination of this and other OSS SDLC models.

It is evident that open-source projects utilizing alternative SDLC models require greater attention and analysis to understand their characteristics and extract valuable lessons. Without efforts to highlight and examine these models, the open-source community will continue to lack a comprehensive understanding of the range of successful open source SDLC models available.

Conclusion

Software development methodologies are essential tools for navigating the complex process of software development. The history of these methodologies is a testament to the ever-evolving nature of software development and the ongoing pursuit of better approaches.

While the SDLC provides a framework for understanding the stages of software development, it is the methodologies that provide the detailed guidance necessary to move from one stage to the next. Among the various methodologies, the ITS approach has emerged as a distinct and influential approach to software development, contributing to the growth of open source software culture and paving the way for new software development paradigms. By recognizing ITS as a specific method and appreciating its strengths and limitations, we can better understand the impact of open source software culture on software development and continue to push the boundaries of what is possible.