FLOSS Realms of Usage

"Usage scenario" is a bland term used in software development to describe very specific use cases of any kind of software system including of course operating systems, commandline applications, GUI applications, and GUI desktops. A "usage scenario" might involve several features but it is typically not about defining the whole software system. Instead, a "usage scenario" is typically about one particular way a software system can be used.

I am going to use the term "usage realm[s]" or "realm[s] of usage" as a riff off of the term "usage scenario" to describe a broader contextualization of one single software system, or a broader contextualization and soft classification of multiple software systems. 

Software systems of course include any software like full operating systems, desktops, and applications. It also describes programming languages, development ecosystems, application ecosystems, and any classification of software infrastructure.

Usage Realms are About Communication

Usage realms are about fuller descriptions of software systems that combine multiple aspects of software beyond one or two technical aspects. As opposed to a "usage scenario" which exists for one team of developers, a "usage realm" is about identifying something that a lot of people can see from random and chaotic directions.

A "realm of usage" is about achieving a goldy locks zone of clarity and definition between overly hard specificity and overly unclear generalization.

Simple But Detailed


The rationales for this concept are light but numerous. Although the concept is simple, and somewhat self-explanatory idea, I still see the potential for positive impact to be complex enough to justify some more detailed writing.

Pre-Existing Usage Realms

As opposed to a usage scenario used for design, a usage realm can be a place holder for a very temporary construct of a class of software systems that happens to already exist. Additionally describing a software realm can very often have its requirements fulfilled at the moment of its conception, if it happens to only require existing systems. This is often the case.

Not Unfamiliar: Development

A usage realm for a developer for instance might be created by a developer's manager, or by other members of a software team, or git project lead. 

A developer usage realm typically gets taken for granted after the fact of a project's definition and conditions.

A usage realm of development might include:

  • dev tool parameters such as:
    • the operating system
    • the language
    • a compiler
    • a set of libraries
  • license parameters such as:
    • GPL3 compatible
    • OSS compatible
    • Proprietary compatible
  • software usage platform parameters
    • the operating system
    • the web
    • server
  • intended userbase
    • technical skill level
    • intended function
    • user time investment
    • age demographic
    • etc.

These parameters of a realm can often vary between being very soft or hard depending on how many alternative options exist for a given software's intended uses.

These parameters can vary widely in prioritized importance to a project coming from external or internal forces.

Not Unfamiliar: Existing Distro Types


In the case of the Linux operating system, existing realms are very familiar to most people. Often by describing one or two aspects of a distro, people understand what type of "thing" it is.

Pre-existing Linux distro usage realms might include:
  • Scripting distros
    • Guix
    • Nix
  • Rolling distros
    • Arch
    • Tumbleweed
  • LTS distros
    • RedHat
    • Debian
  • distro by user skill level
    • GUI Updates
    • Some terminal
    • Configured
    • Highly configured
    • Custom kernel and services
    • Distro from Scratch
  • Immutable distros 
    • Fedora Atomic
    • etc.
  • Purpose of distro
    • gaming
    • multimedia
    • taxes
    • death

More Assertive Usage Realms


Exclusively referencing features to refer to software systems can be an advantage at times for technical people and FLOSS people, because in some sense of consumption and mixing and matching software for these capable people, they really do not need to be told how to think of software systems. They know quite well what they personally want to use their software for.

I think however, this can serve as a detriment to communicating enough about priorities of development for significant enough advances in the software, even according to what existing developer communities can accomplish at the present moment.

Pre-Existing Usage Realms Mostly Describe


(This is of course by the definition of the term "pre-existing.")

In a the sense that usage realms serve to passively describe what already exists, they are helpful to fill out pictures of focus in more complex ways than just single parameters of usage, like just immutable Linux distros - or just beginner distros. Usage realms help to softly describe a fuller picture of purpose of a software system without getting so specific that it bogs the thing down.

This is a benefit of describing pre-existing software in terms of usage realms.

More Assertive Usage Realms


Usage realms can also be used to be slightly more assertive in how they describe a general intention of software usage, in that calling attention to an intended usage highlights missing or week components towards that intention.

Weaknesses might include available licensed components, available alternatives to components: anything that can be included in the definition of any goal of software usage.

Frequently most of the components of an intended use case for software might already exist, while other components are completely missing. Also (self-evidently) there are also many many situations where the components that would work towards an intended context of of software usage are critically incomplete.

More Innovative Usage Realms


This is about usage realms that go beyond even being more assertively improving existing usage concepts, into more explicitly and jointly engaging with those cases where greater innovation is a goal to impress upon general FLOSS communities. 

As a disclaimer to defend the FLOSS community that fights against innovation in specific cases, most software ideas at the grassroots community level (which is what this is really about) should not necessarily be about large innovation per se, especially just for the sake of innovation and gimmicks.

The proprietary software world is riddled with examples of innovation that exist for the sake of innovation, and in some sense, community software almost pushes against that (even if circumstantially). The culture of FLOSS developers is rightly concerned about this as a general unwritten rule.

Highlighting general usage realms assists random, disparate individuals and communities in seeing something independent of more intimate communications. Different communities can utilize their own independent technical knowledge to assess the feasibility and desirability of such intentions.

Not Controlling


"Everything is relative"

Potential for positive impact without being controlling.

I anticipate a point from others that usage realms have something to do with restricting developer and community freedom.

Usage realms are like a candle on a hill. They are like community propositions. They might come from anywhere, and they might be taken by anyone. They exist as concepts independent of available software. They can come and go: in, out, through, and beyond existing software systems and components.

Usage realms are not about licensing an idea, other than maybe licensing a document itself, and probably even still with a FLOSS license.

Fulfilling Practicalities


The idea of usage realms is very much about attempting to fulfill a perceived set of deceptively simple problems with the advancement of FLOSS community effectiveness.

So for example the idea that usage realms are like a candle on a hill, or like community propositions is about fulfilling lost practicalities amidst the tradeoffs of decentralized and disconnect communities of strangers and convening online collaborators.

The practical intents of establishing the idea of a usage realm is similar to why people establish ideas about anything in software in non-grassroots, non-community, non-decentralized, organizational, institutional, and  contexts.

More to be Said


I am going to call it good here, but there is more to say about it.

There might be some graphics or something that can make documenting and spreading usage realms like memes.

Usage realms can range from informal to formal.

No comments: