The aforementioned application "ecosystem" is the most moving-est of the moving targets in this ideation of Free GUI. It is kind of a blind list of disconnected wants that likely overlap with each other, and are very hard to express in words (as UX design already is, let alone when it's a venture into new territory.)
The point is to hone in on the purpose that these ideas intend to collectively accomplish - a beating heart that ties them together to make them jive and click to produce something special. A killer whale is big, but a beached whale is too big and too slow, not to mention pretty morbid boys.
A Leap in Tooling
Perhaps the most concise way of rationalizing the word "ecosystem" is in describing a consequential impact of approaching the tooling and infrastructure in terms of complete freedom of motion in design concepts. The presumption that this would necessarily brake compatibility is very likely in at least some capacity, but how much so?
Answer: Never so much so that traditional applications could not take even exclusive precedence if preferred, over these new custom applications, on top of the desktop environment. The desktop environment still uses the same techniques for UX customization however, as in some common way for widget positioning.
No Pre-Existing Applications
Unlike a packaging technique like Snaps and Flatpaks, you cannot simply repackage old applications to work with this. These other ecosystems get to start with full-fledged office suites and other applications just by creating a new way of packaging the same things.
This "ecosystem" idea is more of an entirely new way of constructing and consuming applications altogether. And for this reason, it really cannot be built with the intention to work in place of these other ecosystems, and especially for quite a long time.
It is possible that more complex office suites could be built using these tools, but it is also possible that some of these concepts will not fully transfer that effectively.
Ecosystem by Consequence
The ecosystem exists out of necessity after the fact of the way that is intended to operate from top to bottom. It doesn't exist to be troublesome, or in order to do things using just a slightly different methodology, like Snaps vs Flatpaks.
As a sidenote, it's possible that Snaps or Flatpaks might actually work for packaging such things, but it will still likely require its own store interface for sharing and downloading extensions, configurations and/or profiles.
Ecosystem Operations
So what are these ecosystem operations?
If you are integrating:
- a distinct kind of multi-repository system
- or a system-wide plugin management system (and store and sharing features)
- or a system-wide standard configuration system (and store and sharing features)
- or a system-wide profile management system (and store and sharing features)
- or a system-wide toolbar and widget positioning syntax
- or a system-wide GUI positioning syntax
- or a system-wide compilation technique
- or other potential features
then you would tend to be forcing these applications into their own distinct ecosystem.
Note: "system-wide" means available system-wide, not enforced system-wide
Note: These operations also clarify the context about the level of technical difficulty for many players to collaborate on making other desktops and system compatible.
Ecosystem Evolution
If an ecosystem like this would ever become a fully functional ecosystem, it would take a lot of time and steady work.
It Takes Time
Such an elaborate ecosystem would not only take a long time to design, but also take some time to evolve into one that had a significantly realized momentum once it was created.
The concept is a positive feedback loop building momentum steadily. The ecosystem relies on revolutions of sharing and creation and stages of escalation to higher and higher levels of curated refinement.
And, you have to expect low participation for at least . . . about many years.
Setting Up Quality
The key to building momentum is in the progressive curation of quality content, while also allowing quantity in distinct spaces, and individual customization in distinct spaces that have passageways between them.
Skill Tiers
One key idea towards facilitating participation is in designating various distinct thresholds of technical skill that make perfectionism and quality in those areas more achievable and creative and fun. The tasks being performed are more understood and defined, especially depending on the tier of skill being used.
There're a lot of reasons to think about distinct skill tiers, but this is one.
Success is Functionality
Despite the goals to achieve solid levels of participation and usage, there is no objective to amass the highest possible number of users. The objective is to create something that functions. And some number of people, with some level of participation, accomplishing some level of momentum, where people receive a sense of value out of it, are all required to have it function . . . eventually.
Some people never contribute a single item, and they treat it like the most convenient and easy selections of a custom system they like. Nobody minds, and it's a cool thought. That's functional here.
Being functional also means that it is monetarily sustainable.
Ramblings About Money
Sustainable . . . Straight . . . Privacy respecting . . . Liberating . . . In other words: Tricky.
The key problem is these combinations of values and conditions. You have independence, longevity, sustainability, and predictability. You have privacy and freedom of motion that's enjoyed by being able to install something five times on any machine you want, and then try it six more ways the next day. There are so many easy ways that a payment system can mess that type of liberty up severely. And that's a huge problem.
Plan the lowest consistent overhead, while foreseeing and being able to freely plan the evolution of the system. Also know what to do with any level of higher functionality in receiving payments and funds.
Random donations are less preferable to at-cost sustainability, but obviously not off the table. Regular donations come from institutions and people who are actually in love with keeping the idea alive.
Primarily, the prospect of asking for donations, rather than providing some form of straight, upfront payment system is the main thing to attempt to distance from. And having an upfront payment system still carries with it a different tone than a regular store. It is a high-respect system, negligibly affordable to be functional. Large donations might serve as some low parallel to venture capital.
Generally, the Linux community creates distributions and application ecosystems that regular desktop users do not pay for. This is actually preferable and great in and of itself, but there are fishy and unclear stipulations I personally have on institutional dependence and sustainability that I need to make some sense out of. It would be nice to have a self-sustaining institution, or to be a self-sustaining arm of another straight-dealing product.
Minimal broadly averaged fees directly for what costs money: for services rendered and general connection.
Not specific item, or specific download transaction fees.
Services rendered for hosting and connecting. How exactly? Closer to respectable technical companies that provide services to smart people, like . . . I guess the only company that comes to mind is what Linode seems to be, or has been. Am I wrong?
Don't get me wrong, Linode is not attempting any kind of at-cost situation. It's just they function respectfully and provide a respectable, smart service to people without dramatic BS. By technical people, straight to technical individuals, who know what they want. That's my perception.
This matters in terms of modeling respectful and straight forward charging methods. But it's very much a forever conundrum I think, because nothing can ever seem to be good enough of a fit for a particular brand of freedom, sharing, and openness that is some essence of the value proposition here.
No comments:
Post a Comment