At the inception stage of open-source projects, it is important to identify the right client. However, the traditional view that open-source projects automatically benefit from unfiltered requirements and guidance is probably not true. There is a lot of benefit that traditional projects gain from working with people in a vertical structure.
Traditional commercial projects are conceived and implemented by the "caretakers" in any organizational setup. Organizational caretakers are people who represent the organization at different levels. They solve a vital problem of representing a large group of people when they organize to deliver a good or service.
Human society organizes itself at different levels. Earlier societies were defined by traveling distances. Communities and villages were defined by walking distances, cities or towns by driving or riding distances. Regions were defined by primary markets and the areas that served them. This could involve distances that could be covered when transporting perishable goods on a routine basis.
Later on, as the early empires were formed, administrative regions were defined. These were defined by areas where tax could be uniformly collected as well as welfare tasks such as education, health, law and order could be provided so that people did not rebel.
At the outset of nations in 18th and 19th century during the industrial revolution, the distance that could be covered by railroad determined the areas that could be joined to create the first nations. These new entities started sharing defence, budgets, currencies, foreign policy and international trade policies.
Why this does not work for open-source projects
Open source projects represent a larger playing field than most nations or empires can hope to achieve. However, open source projects work at the level of the individual end user. This means that requirements do not come from organizational representatives but individuals. This provides a new challenge. Key individuals have greater insight into an organization due to their functional roles and large amount of time these individuals spend in analysing the organizational needs from their functional perspectives.
There needs to be a way to bring these perspectives into open-source projects. Functional requirements from the people who understand them best in addition to a shared peer review is probably the best way to develop open-source code.
