FOSS can get unnecessarily political. It can get too religious. But there's a better alternative to being the opposite extreme of those things, which is barely acknowledged or understood, disjointed, and non-existent.
FOSS needs a motherload of attention and infrastructure and teamwork of a grassroots community of individuals and small organizations that are conscious of
- a novel, FOSS-pertinent developer compensation model
- a developer contribution model to fit with the compensation model
- an ethically charged zeitgeist
- an equal measure of pragmatism
- common sense vision
- (a goldy locks zone between overly specific and disjointed.)
General Awareness
FOSS has such an incredible lack of general awareness and attention from the world that with Linux distros for instance, there are only one or two FOSS distros that may or may not be very functional as daily drivers. When you combine all the functions users implement in their OS, developers and users can only really do the things they want to by heavily compromising on FOSS values. I am pretty sure that a hypothetical assessment would reflect this is true of 99% of Linux users.
This same description is close to how I would describe the situation of choosing developer tooling as well. It is true that developers have little option but to be conscious of licensing, but that does not always mean very much with a lack of general concern over the why, when, how of it.
There are many software licenses, enough so that lines are very blurred between all ranges of capabilities and compatibility. Here is the big reason that awareness of the general zeitgeist on the topic bares importance. It is because a zeitgeist flies over and across the technical and legal details of all these numerous specific project and licensing scenarios. Yes, awareness has to be about more than just knowing all the bitty details of all the licenses and stuff.
Leadership Never Replaces Comprehensive Awareness
This might sound like a general truth broader than software, but the point here is that it is more true for FOSS than it is for OSS. This is because the industry machine as a whole greatly favors OSS. This has created an industry tendency towards OSS over FOSS. This means that OSS does not really need to be understood by many people in order to survive and even flourish amidst corporate usage. Neither added leadership, nor special increase in mass comprehension, ultimately have close to the same urgency for OSS as it does for FOSS. And, it's likely to remain that way.
OSS stays alive regardless of the grassroots comprehension, but FOSS slowly dies without it.
This point might get confused with a point that FOSS should be overwhelmingly grassroots as a replacement for large levels of contribution and participation, from large organizations. As I touched on before, the broader point is that rather due to its form, that its success will frequently get pushed down to the grassroots level's ability to carry its values to fruition in different times and places. The more comprehension, representation, support, leadership, and enabling from larger organizations, the better.
Identify a Problem?
What are the nuances of the needed comprehension, and how are they to be applied to individual projects? The complexity of the FOSS problem - which I guess is what is to be comprehended - might be irreducible, or intractable, or just overlooked. I think for now, I am just going to sporadically approach the issue from various angles. (sorry)
Shared Comprehension
For practically any business or institution with goals, it's generally superior to have participants on board with shared comprehension of the organization's goals. In the context of needing more grassroots comprehension than OSS projects and corporate and company teams, that shared comprehension only becomes more critical to success. Problems have to be shared between the leadership and the community in a unique manner as compared to more top heavy organizations.
Distributed Decision Making
The relationship between distributed decision making and shared comprehension that I picture requires more elaboration with some more thought, maybe in another blog post. My take is that the human component of distributed decision making is critically lacking due to cultural bias towards top heavy organizational structures that create a vacuum of training to distributed self-organization.
I think it is good for FOSS to be connected with an awareness of distributed culture if it can be accomplished. That might not have anything to do with specifically how FOSS is defined, except that it is symptomatic to its other defining and circumstantial characteristics. I do feel that it is somewhat obvious that the world - instead of becoming more friendly to teamwork oriented culture - has become more individually isolating and anti-social, which would suggest that more effort would have to be made to intentionally foster ideas around this stuff.
I might write another blog post about my take on distributed decision making. Ultimately, I think fostering skills around distributed decision making can be touted as an important circumstantial extension of FOSS principles. Similarly, other things I write about have not been set out as being strictly FOSS principles.
Distributed Decision Making Inherent to Design
By comparison to human skills in distributing decisions, describing software design, and development processes are more avoidance tactics, or even Band-Aids. However, these things can be very important in tandem with good human skills. Additionally most of these design methods can have other important beneficial side effects, like choice, personalized options, freedom, and of course making software more apt to a given purpose.
Modularity
This might be my opinion, but I have always assumed that one way to reduce dependence on high level decision making is through the modular software design that is promoted as a FOSS design principle. Monolithic projects are not just about the practicalities of developing the software under this thinking - but it starts to also overlap with the human problems of monolithic power, monolithic dependency, and monolithic decision making.
Among all the compromises that can be made on FOSS however, I tend to think that the monolithic issue can be compromised if it is compensated for. If compromise is done with comprehension of the rationales for modularity, then there's actually a potential to reach past the point of compromise to possibly even make the software better on the same axes as the rationales - or to accentuate multiple other axes of rationales that benefit in configurability and ease of development.
Configurability
A different way of shifting centralized decision making through design is by making software so that it is not restricted to one set of decisions. This is done by making its options and UI highly configurable. Additionally, this is greatly amplified by making it convenient to swap high levels of custom configuration for the UI and deeper options.
Convenient Config Swapping
If a UI or other critical options can be easily altered or swapped by the user, then the software's ability to maintain those controlling manipulations over the user is diminished in those regards. For this reason, it makes so much sense for most software applications to be equipped with some kind of profile importing/exporting/swapping mechanism, such that a UI and configuration options can be switched with relative ease. (At present, this is very much not the case with modern GUI applications, even on Linux.)
Along with the existing software "stores" that show application previews to users, there should very much be sections in those stores for application config DLC per application, that allow users to preview curated configuration imports. Users are able to handle such things for DLC and mods for games, and they could handle configs alternatives for applications.
As a sidenote, development is saved by making applications capable of reducing the need for forking them for every change developers or users desire. If an application can more drastically morph in form, then it can reduce the incentive to create forks of the application. If designed with this purpose in mind, mass config changes can replace the need for entire alternate applications.
If infrastructure provides supportive means to do so, more and more native FLOSS applications can be implemented with higher GUI configuration. At present, there are few-to-no attempts at GUI tooling and systems created to specifically accommodate high GUI configuration as a goal. This is nuanced, and I want to make a separate blog post about it.
Beyond Single Applications
Config swapping can make sense on configuring multiple components together beyond the level of a single user application, but it can require special accommodations in infrastructure beyond application-specific config files, like for instance Nix, Lix, Tvix, Aux, Tangram, Brioche, and Guix for environment configuration.
I'm talking primarily about individual application configuration and sets of programs and applications (as opposed to primarily about development environments). A good example is the various modular components with the Sway desktop, for the toolbar, and the application search menu - the theming for these chosen components - and anything else. When these components get swapped out, it changes more than just the individual configs for each component.
So again with a software center or software store, regular applications and something like the Sway or Hyprland desktops should have multiple configurations available to choose and install. These will make sense for enabling distinct user workflows, and potential distro specifics, and Software Centers should be able handle choosing and installing different configurations.
As a general rule of thumb, these configurations should very much be as easy as possible for non-professionals to create from scratch, while still being able to handle these types of configuration. (This is why I mention the priority of applications over development environments, because it might be a simpler set of use cases.) However creating these from scratch should still be expected to require the typical cumbersome slogging - or perhaps even more - in cases of tradeoffs between easier skill acquisition and an extensive config feature set.
General Agenda
FOSS as a whole can be characterized as being, or having, a large, general agenda. But do individual FOSS projects have that whole agenda, or parts of it? Do they see themselves as carrying FOSS as a purpose at all? Is FOSS an umbrella? How can the FOSS agenda be described in terms of the FOSS projects, which have their own agendas? Does that make it irreducible, or intractable, or does it simply translate to why it's irrelevant to most people? Should institutions have a "FOSS fulfillment committee?" (no, probably not)
It's very much true that projects that are thought to support FOSS values, can actually steer them in bad directions, or be steering FOSS in a bad direction. Yet at the same time there can be a difference between a malicious misdirection, and a temporary setback of an organization. When the stituation is especially bleak for FOSS org representation as a whole, that should carry some weight in what sometimes feels like the FOSS/OSS community's first instinct to burn down misbehaving individual leaders and orgs. It feels like hysteria.
More About Awareness
If it's achieved, grassroots comprehension can actually have a couple advantageous trade-offs compared to greedy mass marketing. Greedy mass marketing frequently has the drawbacks of having to gain appeal by being overly generalized and dumbed down.
Successful and responsible FOSS leadership can mean the difference between administering the right projects that large organizations contribute to - instead of the wrong organizations administering the wrong projects that exploited developers contributions for purposes that only halfway fulfill good free software.
For developer communities comprising individuals and communities involving orgs, it is the classic cat-herding and money problems, and a lack of shared comprehension of the what, why, when, how. However all these points should culminate in a realization that much of this is very much outside of placing blame on developers. It's far from being devs' "fault". Who's fault it is, is not really the most approachable issue when different parties are simply "doing their own thing" and FOSS gets neglected in attention and financing.
It's also worth noting that it doesn't just take money to make money here. After or before or aside from money, FOSS is ideas and philosophies, barely scraping by. And the thing is that "nobody" has a clue about how complete or incomplete its native and web stacks are when people don't even barely have a single thought in their head as to the difference between OSS and FOSS. If they do - it's about the license - and some drab and pedantic sounding stuff. (But it is actually more than that.) Additionally, the confusion between OSS and FOSS is said to be intentional, and there is probably a lot of truth to that.
It makes sense to default to FOSS licenses when possible - if for no other reason - to spread awareness of the tooling and the ecosystems - or for the need for the tooling and other types of high priority FOSS alternatives. And spread a common understanding of FOSS values and culture.
OSS is a Doppelganger to FOSS
I have a pet theory (or like a pet assessment) that a big reason corporations vastly prefer OSS is because of its ability to effectively become closed source by combining it with critical components which are closed source.
The problem is that many times these closed components in OSS applications and systems remain dependencies for fulfilling the larger intended uses - and as frequently touched on by FOSS advocates - for their malicious functions - effectively ruining the openness of the software where it matters for developers - and for users who trust the security of open code review. It's open more for the sake of receiving. This is what I think must be a big how and why of the corporate incentive to have contributors and users be uninitiated as to the differences between OSS and FOSS.
I think volume of lines of code can be extremely misleading on this issue. After all, a blurb or a blob is so small. Therefore it's criticized as more of a pathetic stipulation. However the reality is actually the opposite extreme in that it really takes a relative few lines of code to sabotage the aspects of openness that are supposed to count for something - in it's real implementation - and in its inspirational zeitgeist.
With OSS, you should assume by default that contributions large or small will effectively equate to mere accessories to the software's critical maliciousness, if not at first, then progressively over time. Those malicious purposes might come in the form of "enshitified" psychological UI games, and technology obfuscation games for contorting strange forms of developers', or users' dependency - or of course the many contortions of spyware. This matters to the developers who give a crap about their altruistic time and work for the sake of the supposed OSS ethos, logos, pathos. It also matters to the users of the software who care about the supposed benefits of openness.
Yes Individuals Choose OSS
For many many people, there's little thought of this big picture crappy corporate stuff, and on top of that it's the lesser number people that care the most about contributing to something for the sake of altruism and widespread use that get burned when they realize the work can effectively be swept out from under them.
Naturally this blog post is about capturing a general distinction that is very broad, and it applies to people who care about a set of values in the context of what is a technology topic in a bigger world - that of software development, software privacy, software openness, and software freedom. This ain't a discussion about world peace. (Still, software as a whole is no slouch on the world stage.)
I guess its worth acknowledging: if anybody does their homework, and they know the institutions/people they're dealing with, it's a free country. It's just that it's fine actually at the end of the day, to do what you want or need for your purposes, OSS or FOSS or proprietary, etc.
Anyway, individuals choose OSS for any reason. Developers choose OSS projects to try to get a job with a company/technology. Sometimes people will develop a project and make it popular specifically to try to sell it to a corporation. Also, it's fun to be a part of something big that has a head start through big corporate support.
OSS Hype is Really FOSS Hype
There has been a misunderstood level of open source hype in entertainment. Simply stated: FOSS is pretty-much what is being discussed. Typically, the term people in the media and entertainment use is "Open Source". Technically FOSS is Free and Open Source, so the term is inclusive in any case. It's just that all by itself, the term "Open Source" does nothing to discourage conflating FOSS and OSS.
FOSS carries the torch of these higher minded values. Yes, hype is hype. But it's clearly FOSS hype.
When you contrast the two, you have to ask: What exactly is the equivalent OSS hype? Are you in love with the idea that corporations can work with other corporations to share software between them? . . . Maybe . . . But really? . . . It's not a community in a real sense. It's not about "the little guy." Insofar as it's about individual developers, they're donating their time for big business. When it's not for exploiting developers specifically, it's about building systems that exploit regular users with cloud subscriptions that have strenuous rationales for sneaky data collection that can launder their personal and private information. Those are not FOSS values, but the doppelganger OSS values. The FOSS world takes great care to point out that this stuff is no less than malicious.
Modern FOSS Compensation as a Novel Problem
I think this is where I have a unique perspective to bring to this issue.
Unless a model for developer compensation can mold specifically around the form and realities of FOSS, then it has not been considered in a real way. That problem has changed form in the last 40 or so years. The landscape of software contributing and delivery capabilities has expanded and morphed over this time. Distinct from that is also that technology in general has afforded potential for new innovations outside what has been already.
FOSS was not devised as a corporate methodology. Although FOSS was not defined specifically as non-corporate either, it has always, always existed as an action, or a reaction, in the context of corporate exploitation and inequities of developers at least second-hand. This stuff is a symptom of the general state of corporate incentive to exploit.
The reality of corporations' general tendencies towards greed is quite difficult to deny with just a smidgen of intellectual honesty. It's those corporations that refrain - and the time they refrain - that is shamefully what must be deemed praiseworthy, but arguably much less: the exception. That saying about the greatest lie being that the devil does not exist is apt in the context of corporate power. It's more than reasonable to exercise skepticism in these very high powers, which are corporations.
OSS specifically exists to mold better towards the natural corporate incentive to exploit workers than FOSS. That has to also play into the vision of a FOSS payment model. It's not that it strictly cannot or must not involve corporations. Rather, its definition must overwhelmingly prioritize individual developers receiving compensation for their work amidst sharing and reviewing code freely.
The methods of payment and selling have to specifically take FOSS time-frames and techniques into account - or even more bold - they have to mold a development model to meet payment and selling techniques halfway from the typical store and company model - potentially from typical development models.
But it could very well be a hard problem to make FOSS translate to individual developers getting paid - while also fostering social contribution and teamwork - and not replicating exploitation and inequities in compensation. What methods have been designed around FOSS to this point, as opposed to just being used by FOSS, where FOSS is a non-goal? That could manifest into quite a critical point for optimism. ie: Git exists, but what are the massive ecosystems around git? Answer: Not infrastructure and ecosystems that exist for the sake of prioritizing FOSS values.
Brainstorms on Enabling FOSS
It's [at least initially] difficult to imagine a micro-payment system that effectively attributes money by merit of contribution level. That can easily become a rabbit hole of garbage. But paying a few project leads for work that is done by 200 people is a bad precedent.
A good compensation system certainly would not exclude typical funding - meaning getting investments ahead of time - but I think this is what touches the difficulty of what I'm suggesting. The dream of such a payment system should include situations where grassroots projects happen with 200 random contributors who just decide they like a project. If the projects becomes profitable, then those 200 contributors get compensated retroactively. "I don't think it's impossible." is both a statement of hope, but also an acknowledgement of the challenge of it. I want to do another post on this. (I'll just say that doing it through a git system should be a very tentative thought.)
No matter what such a solution would be - it will be impossible to make it fully bullet proof against problems in equity, merit, and distribution of compensation. After the best attempts to formulate such a solution, the developers will still need to have a culture of being informed of its weaknesses. And that has to play into its conception.
As an extension of the thought about developer expectations, I ask the question: What are the reasonable expectations to place on contributors to these projects that forms a balanced social contract between them? How much of that social contract is formal, and how much is purely cultural. How do developer expectations impact the thought that goes into designing such a payment system? How does that play out backwards through infrastructure and security technologies to construct it?
Does the system hold to the zeitgeist of privacy for developers, and FOSS tools to do so? What about other aspects of FOSS developer values and culture? While anybody might scoff at the importance of the values, a system that maximizes FOSS values and culture could engender much more crucially genuine adoption from a "real" FOSS community, as if the values were not firstly warranted on their own anyway.
A positive point of not being corporate is that the customers and users of the system can be the same individuals that "actually" appreciated it, rather than what might occur with a system that is attempting to harvest every user they can. Not everything is bad about changing the game from a primary focus on greed and overly generalized appeal. The scale of these systems can grow slowly, as they "genuinely" grow - and well - perhaps - not require as much grand upfront investment if that is also internalized as a factor in a success strategy.
It's critical to slowly circle these issues in gentle terms in a manner quite distinct from advocating one specific plan from one single person.
A Compensation Liaison
In terms of developer compensation and contribution models, whatever solutions might be devised will not likely be "good" enough (or perhaps rather "bad" enough) to fit a greedy corporate incentive to take it on. As such, those solutions should not plan to be corporate. But I mean again, it's not a rule by the definition of FOSS to refrain from good corporate support. I think it's pragmatism and healthy caution towards corporate assistance, mainly about the conditions to get assistance.
Additionally, by contrast, FOSS compensation and contribution models should be conceived under the plan to gain independent long term survival. A major goal is to have a sustainable model that at least works at cost - and furthermore seeks to modestly compensation the administration of these models as per a transparent understanding from developers.
If these models are done right, then the organization or organizations transferring compensation to developers should never amount to a massive accumulation of wealth by people at the top of a corporate-like structure - or a few investors. The whole point is to transfer the bulk of that wealth to the developers. And of course the situation is such that most contributors can use every ounce of money they can get. (I imagine there could be some kind of additional cost for popular project, but only at levels that stand to fit the social contract of reasonable developer expectations.)
Organizational and Legal Structure
Can a foundation exist that is non-profit that also seeks to be a profit liaison between contributors? And regardless of project? I guess I see it as a potential hurdle to why this stuff has not been done yet. But I can't help but think that some combination of orgs could scrape out the legal issues between profit, non-profit, or not-for-profit.
Can a for-profit company conceivably do it as an AT COST endeavor? Once again, probably not a corporation. I would guess that it would have to be a company like System76, or Raspberry Pi, or Framework - that had some other product that they sold.
I at least know that for a foundation, that multiple businesses can contribute to it, and the foundation survives on its own goals and purposes.
Taking a step back from the whole thing, an organization does not have to produce an attempt or an implementation, but they could develop infrastructure for others to attempt it with some personalized variation between them.
What would those tools look like? A free-licensed contribution platform with integrated payment system? A free-licensed storefront server application that can be themed and configured? A company could attempt to profit off of these tools' development for other interested parties to implement in their own way.
A Modest Plan
- This idea is basically of a very modest plan.
- focuses heavily on casual hobby compensation
- can some people graduate to freelance?
- can some groups graduate to a business selling full applications?
- It starts off trying to get it functioning for a particular subdomain of software development.
- Its point is to scale up gradually with genuine interest - not to prove itself highly profitable within a 3 year time-frame.
- Does it function in the real world?
- Is it comprehended by those who use it?
Giving Attention to FOSS
You know this stuff I have written about runs the full gamut of high level stuff all the way down to the developers and users. But actually it's primarily high level stuff that can only be done if some wealthy entities just happen to be inspired by my pitiful blog post. Even still, if it can be done from the grassroots level, then of course that's awesome.
But on a developer level, and if it translates to a user level, I think you default to FOSS when the project is fun. Default to FOSS when it's for the feels, and when it is altruistic. If it's for money - then realize you're going to have to get creative - but that it might actually be possible - and that contributing to a big OSS project is just enticing - but with these enticing OSS projects, the end should be assumed to be the same tragedy . . . by default.
If FOSS communities can identify existing assets and shortcomings and common values, then they can commonly understand a standpoint of critical decision making
- have a cohesive culture and understanding
- develop methods for monetization that aptly fit with FOSS definition and values
- team up to do larger priority projects
- know when and how to prioritize and join new projects that might already have larger, non-FOSS equivalents
- Fork major projects past corporate takeover - even when a project takes a hit in funded contribution
