Development Philosophy

Terminology

Before we proceed to describe the components required to define the development philosophy, it is crucial to establish a shared understanding of the terminology.

While the term “development philosophy” includes the word “philosophy,” it still represents something tangible. If the choice of terminology seem meaningless for any reason, it can be helpful to perceive “philosophy” as a collection of fundamental principles. Defining “philosophy” does not imply a lack of pragmatism here; instead, it serves as a means to grasp the underlying principles that drive our decision-making processes and behaviors, rooted primarily in our intrinsic motivations. By embracing the term “philosophy,” we encourage a deeper exploration of the fundamental factors that shape our actions.

Considering the etymology of the word “philosophy,”¹ it encompasses a range of meanings, including the “love of knowledge,” the “pursuit of wisdom,” and “systematic investigation.” It even extends to concepts such as “alchemy, occult knowledge.” The latter suggests that valuable knowledge might have been deliberately concealed as sacred or deemed dangerous, not necessarily due to its inherent nature, but because it bestowed power upon those who possessed it. It is possible that the negative connotations associated with the learning process of new and unfamiliar subjects contribute to why some individuals find the term “philosophy” off-putting.

Taking all of these aspects into account, I invite you to embrace a genuine appreciation for the pursuit of knowledge and to approach new explorations with an open mind.

Meta principles

Most if not all projects adhere to the “Problem → Solution” principle. Due to this, some leaders think that defining development philosophy is an endeavour of dogmatism rather than pragmatism. However, if we apply this logic recursively, the lack of development philosophy can be classified as a problem which needs to be solved in and of itself.

Many healthy open-source projects define their development philosophy in various ways, shapes, and forms, not necessarily using words alone. It’s a matter of defining and revealing our vision, mission, goals, non-goals, purpose, direction, intention, principles etc, alongside more fundamental information like values, beliefs, assumptions, and expectations with the community of developers, as we have covered in Organizational Culture section.

There’s no true way to define development philosophy. The task here is to come to an agreement, a mutual arrangement accepted by both leadership and contributors, so that everyone has correct assumptions and expectations regarding a project. This way, leadership respects contributors’ own values. This will greatly minimize all sorts of interpersonal conflicts between project maintainers and potential contributors. It definitely shouldn’t be about attracting people from all around the world and taking advantage of the work they do for free. The lack of informed consent may backfire against a project, leading to a division of community caused by a conflict of interest.

Let’s go through this in the context of the “Why → How → What” model². Just as there are no perfect solutions, there are no definitive answers to these three fundamental questions. But the need for good answers is there, as is the need for good software.

Development philosophy doesn’t have to be the Bible. It could be an explanation, a story about the vision of the project by its leaders. This document should not prevent anyone from contributing to the project, but should help to better understand which contributions are most likely to be accepted. Since we are naturally hard-wired to pursue goals, it is beneficial to establish a meta goal of defining a set of principles and acknowledging the necessity of having a plan to accomplishing project’s goals.

Vision and mission

Why?

💡 A* search algorithm for collaboration!

While development is mostly driven by problem-solving, these problems stem from our needs. Not all problems can be solved using our sole efforts alone. Due to this, developers must feel a shared purpose, and this is done by shedding light regarding project’s direction and concrete goals.

If the purpose is not clear, a project may start accumulate proposals which go against the flow of development, making it more difficult to actually focus on things which can benefit a project in its current state. The answer to this question shouldn’t be just a way to sell something. A project may not necessarily have a clear vision just yet, but what is our intention?

If we address the lack of clarity regarding the project’s motivations, it may be helpful to seek answers to the question “Why?” by utilizing root cause analysis techniques, such as the Five whys technique. This approach may seem unusual initially since these techniques are typically employed to identify software bugs, for example. However, as the saying goes, “It’s not a bug, it’s a feature!” 😁

We can also define non-goals. These signify things that may undermine project’s roadmap, hence project’s long-term success. Non-goals reflect the fact that they do not provide meaningful value to a project and may come with negative consequences or risks.

Non-goals are precisely the goals that do not pertain to a specific project but may be relevant to another project. This is the point at which alternatives can be considered. While providing alternatives may impose additional work, doing so prevents alienating someone and potentially creating a negative impression. Instead, it serves as a means of communication. In fact, certain organizations, such as consulting companies, focus solely on providing alternatives without any additional services. Even this book provides alternatives!

How?

💡 You can’t have your cake and eat it.

This describes how we’re going to achieve goals exactly.

What is the solution to the problem? The same problem can be solved in different ways and to different degrees. Why is one solution better than another? Perfect solutions are unattainable, but how are compromise solutions born?

This is where values help to shape the “How” as well. Values are not industry-specific. Values help to build a sustainable path towards a common goal. Without values, the “How” is chaotic.

It is also advisable to utilize estimations because, despite our best efforts, certain things are difficult to measure or even impossible to quantify. Employing estimations facilitates the involvement of all participants in making informed judgments and contributing to a project. However, it is equally crucial not to conflate estimations with promises: estimations are educated guesses that provide an approximate understanding of what to expect, while promises are explicit commitments that create a sense of responsibility.

Some might even argue that answering the question of “How” is what actually sets apart one project from another. This is where intuition comes into act. There’s no one true way to answer this question.

What?

💡 If you run after two hares, you will catch neither.

What constitutes a problem and what does not? Which problems does a project fully solve, which ones does it partially solve, and which ones does it not solve at all?

When and how does a user request transition into a problem that the project aims to solve? It’s important to note that community support for a request does not always mean that the project leaders perceive it as a problem. Sometimes, suggesting alternative solutions that are not currently provided by the project may be sufficient.

Developers who come across a particular project come from diverse backgrounds. Consequently, they often request similar features to be incorporated into your project, even if they are not necessarily aligned with its scope.

The answer to this question is determined by the project’s mission, which focuses on the present. It can be likened to a day-to-day job description. What tasks are you performing, and what is your primary focus to achieve the project’s success?

Conclusion

It doesn’t matter if your development philosophy is short or not, as long as it actually delivers your message to the public to the fullest extent possible. Use a particular language suitable to express these kind of things. Remember that not everything stems from pure logical reasoning, especially if you’d like to lead a project which is hedonistic in nature, such as a game engine.

If you don’t have a plan, people may feel uncertainty and be paralyzed by indecision which stems from the lack of understanding of existing development philosophy as seen by project’s leaders and seasoned contributors. There always exists the development philosophy that you follow, even if you think you don’t. “I have no development philosophy” is also a development philosophy.

While it may be easy to build up enthusiasm by promising something, beware of situations where you cannot fulfill your promises. You certainly don’t want to end up with a situation where you’d have to reject 95% of ideas, proposals and requests, especially the bigger your project becomes. If this happens, this is a direct sign that you should clarify or start defining your project’s vision and mission.

Note that not everything has to be defined right from the start, and development philosophy shouldn’t be something that you must strictly adhere to, especially when our vision tends to change over time, since development decisions are mostly based on user needs. We just need to share the same vision to make the development process as smooth as possible for everyone involved, and try to adhere to declared principles.

Having a clear set of criteria regarding development philosophy can help people accept the way a project chooses what features are essential to realize its vision, which may or may not be in alignment with each individual’s vision, and save the time it takes to implement them.

References