Software undeniably has an increasingly important place in our society. As such, its importance grows accordingly. However, the means we allocate to it are blatantly out of proportions; and I mean it the sad way.
We rely on technology for more and more, and for nearly everything already. Yet, thanks to hidden costs of the current technology giants such as Google or Facebook, we expect it without any monetary charge. Or at the very most for a small fee that is related to the necessary hardware, the software coming either for free or "bundled" with it.
However, software is a critically important part of our technology, and while it it easier to design and implement than hardware, it isn't necessarily exactly easy. As our demands and the related technologies increase in complexity, the difficulty of implementing them grows exponentially. To such extent that it isn't possible to realize anything without a team anymore. Any technology I can think of reuses the work of a team (in very rare cases of a single person), and is made by a team (and similarly in very rare cases by a single person). Even the top tech companies (the aforementioned ones, but also Apple, etc.) rely on the work of other teams, by adopting parts of or entire software such as Linux or BSD versions.
Yet, those communities, while sometimes timidly supported by donations, sometimes having a few of their members employed by corporations; are mostly composed of amateurs and professionals working voluntarily, gratis; investing their already limited free time into the Software of their choice.
Those communities, composed of random strangers, who often have little in common aside their interest for a given Software (for reasons that also often differ very wildly), need to work together comprehensively in order to achieve results and minimize the overhead and wasted time; that time being indeed a scarce resource.
In communities, it is always hard to decide who should take decisions, and who should follow. There are multiple approaches to this problem: the Democratic vote, the benevolent dictator for life, the technocracy, the meritocracy, rewarding seniority; and more often than not, defaulting to listening to the loudest participant(s).
The first important point is that none of the solutions listed above actually works for everyone, all the time. Even worse, not a lot of them actually work at all for anyone; let alone for enough time to get Software done, and supported. The most restrictive ones (such as the BDFL one) stand the test of time much better at the cost of openness and agility; while the most open ones do not scale, since some members try to dominate each other as the team grows.
Since nothing can be done without teams, they are of crucial importance. Since they are of crucial importance, enough care should be taken to ensure their survival; and ideally their success.
Unfortunately, given the lack of means, such teams are, with exceptions so rare that I can not readily think of one, composed of ad-hoc members, recruited by chance, whenever the need for a member and the presence of a suitable candidate both occur. Suitable, here, does not necessarily mean that the candidate has adequate skills, or has goals aligned with those of the project; but instead that they appeared to the people in charge, for whatever reason, to be valuable.
One can easily imagine, under those conditions, that the teams are extremely heterogeneous, composed of members who can teach and members who can learn; composed of skilled professionals and eager amateurs.
One could not be farther away from the reality. Skilled people are not only rare, but have much more profitable options available; and so they will only participate in such communities if their philosophy drives them to. On the other hand, eager amateurs are plenty.
So we can already see that there is a strong imbalance in communities; communities we rely on to provide us with essential Software.
And so far we have entirely ignored the larger problem by very far in the equation: ego. Geeks, Nerds and other Techies all (rounded up) have terrible egos. Me included. Since you're reading this, potentially including you too. And one of the traits of insane egos is to consider themselves "quite unexpectedly sane in their social position".
Those egos, tortured over the years by "friends" and family, coworkers and superiors, acquaintances and complete strangers; constantly drive us to seek companionship, yet prove our technical superiority, all within the few communities we partake in.
Now, since software can arguably be seen as legislation for computers (in this scope, the developer is indeed a legislator, describing what a computer shall or shall not do, under their law); the step to politics isn't a very big one.
Legislation is an important element is any social system, and politics are essentially the mathematical derivation of that legislation over time. Or, to put it the other way around, legislation is the integration of politics over time. That means that what we believe to be a relevant and important concept at the time of writing our programs ultimately determines the way we write them. And how. Including the paradigm, language and subset of that language, tools we use to write them, test them, translate them to the machine's dialect, share them with our peers, etc.
So, small differences in political beliefs can, over time, yield incredibly large differences in Software. Determining their performance, number of features, number of bugs, general quality and so on.
But political discussions cost time, progressing exponentially with the number of differing point of views, in turn linearly growing with the team. And they yield very little, if anything at all.
Alright. Let's take a step back. We've seen so far that:
- Software needs teams.
- Those teams aren't balanced, and have ridiculous means.
- Those teams are composed predominantly of people with wounded egos.
- Those teams need leadership, and hierarchy; or at least rules governing them.
- No existing leadership model works reliably and flawlessly over time.
- Politics, even if we reject them, are what we use to decide how we write the Software that is the initial goal.
- Politics, and all related debates, are preventing and hindering progress.
So now, what are the solutions?
I can only see one: While recognizing that politics are a personal matter, and should not be discussed (actually, should be banned) in the scope of a project (since they put the short term (immediate progress) as well as the long term (cohesion) at important risks); a project should lay down their political beliefs from the very beginning, so that contributors can judge beforehand whether or not it aligns with their own views. Those political beliefs should include, but not be limited to, what is the reason for the Software to exist, what problem does of solve, how it is expected to solve them, why it is better than other comparable solutions, what are the recommended approaches, what are the discouraged ones, and why.
Should a project fail to state that, it is arguable that they are lying by omission in order to get artificially more popular than they ought to. Remember, it is for you and you only to chose how you invest your time; and communicating clearly is the least a Software project can do to stay alive.