tait.tech/_drafts/2022-08-24-open-assistive-technologies.md

title	draft	layout
Open Assistive Technologies	true	post

I haven't been on this earth very long, but I can notice a trend when it's right in front of me. Open-source and libre assistive technologies are being abandoned in front of our very eyes.

Exceptions

This is not to say that the tremendous effort of Federico Quintero is not appreciated. Nor is this an insult to the outstanding efforts of Joanne Diggs who works on the Orca screen reader.

The GNOME Accessibility Team has done fantastic things with the funding that has been provided them. I applaud their efforts at focusing on creating a free and open desktop that is accessible. But even then, just last week I heard that one of the primary architects in the accessibility world did not have their contract renewed. And one at a time, funding for accessibility continues its decline.

Microsoft, Google, Apple

The biggest technology companies in the world are able to spend a fraction of a fraction of a percent of their revenue to put together an accessibility team. Global, multi-trillion dollar companies are easily able to fund the accessibility of their platforms. Their efforts are divided; their efforts are duplicated; their efforts are dwarfed by their primary goal: to make a profit from their users by selling their data.

Your preferred company is complicit in this. Despite their fantastic accessibility and "focus on privacy", now even Apple is offering ads on their users' phones. Since Apple locks down their accessibility infrastructure, there is nobody who can extend this functionality to better and greater things. Only Apple, not their customers have a say in how accessibility functions on their device.

Proprietary Technology

This principle does not only apply to the tech giant. All public for-profit companies benefit exclusively from driving up dividends for their shareholders. They do not profit from accessibility; they do not profit from putting the user first; they only profit by selling your data. People who require accessibility features, those I will from now on call "the needers", since they need accessibility tools to complete day-to-day tasks--they do not have a choice in their system. In theory, they could choose Android or they could load their computer with Linux. But the option is not attractive for a variety of reasons, including accessibility.

Inside the Linux bubble, there are those who want to see Linux take off as a desktop computing experience. This is a surprisingly popular opinion. To them, software freedom is defined by the freedoms as they are defined by the FSF.

1. The freedom to run the code for any purpose.
2. The freedom to modify the code as they see fit.
3. The freedom to redistribute copies so you can help others.
4. The freedom to redistribute your modified version of the code.

These may seem very abstract for a non-technical person, but I will help it make sense for you as a user.

1. The freedom to run an app for any reason you want.

• Does not allow any individual or company to stop you from running the apps you want.

2. The freedom for others, let's say your technically-inclined child or sibling, to help you modify the program to fit your needs just that little bit more.

• You know that feeling when you think "Man! Do I ever wish that ABC could do XYZ!"
• This would grant you that freedom, as long as you know somebody knowledgeable enough to do it.

3. The freedom (and requirement) to share copies of your changes. This also encompasses freedom 4.

• The changes created by your friend, colleague, or family member must be shared to the public; you can not take that change for yourself. You must give back.
• This clause is generally why big companies don't like the GPL.

Selling Openness

Here's a fact: it is not profitable to sell free software. It's in the name! Although free-software fanatics would prefer your use the term "libre" or "gratis" instead of "free"---it misses the point that software that is free to download is very hard to sell, and especially so to technically-inclined users that know how to build programs from their source code. That said, there are at least a few companies 12 which have managed to make it using the SaaS and EaaS models. Specifically, SourceHut uses the SaaS business model: the software is free, but to host on their servers is not. Also note that this is a payed-only service. This is something you don't see much of in the open-source game. I think normalizing the cost of services to the consumer is a great idea! Maybe a free trial for a code sharing service would make sense, but not everything needs to be a charity, and making money through open-source software is possible if you structure your business a certain way. Let me talk about a few of the ways open-source businesses can create better products, especially if they don't have a free trail.

Advantages

1. You do not need to rely on advertising to subsidize their free tiers of service. This makes the experience better for the consumer, from a privacy, simplicity and an UX standpoint.
2. The software can be improved by people who care about your mission, and you don't even need to pay them. Obviously, a small stipend to amazing people sending large patches should be considered. You essentially get free marketing and development work from the community.
3. Freedom to follow what's best for your users. Without venture capital or sponsors telling your how to run your service, you get to take feedback from your users and actually implement it. You don't need to balance your users' needs with those of who actually pays you.

Disadvantages

With any upside, there is a downside. Let's begin with the most obvious.

1. Investors are extraordinarily hard to find. Open-source projects like SourceHut or RedHat generally don't have a business model that can sustain exponential growth, and this takes away from a lot of the possible initial funding.
2. (Due to 1), the upfront cost before you can receive buy-in from average users is very high. Nobody wants to use a git server that doesn't have merge requests, an advanced permission system, etc.
3. Licensing. Licensing as an open-source business can be complicated. We'll give this its own section, since it is quite involved.

Licensing

Depending on the type of license chosen for your codebase, there are some complications as to how you can use this to make money. It also adds restrictions on how others may make money with your software. Let's discus three categories of licenses: permissive, copyleft, and file-based copyleft.

• Permissive -- a permissive license generally allows other individuals and companies to use your code as they please, with the only restriction being a notice that you wrote some of the software. Licenses in this category are the MIT license and most BSD licenses.
• Copyleft -- a copyleft license allows others to take your code for their own purposes, but with the exception that any modifications that they make to the code must be made public. This (usually) includes calling libraries functions from other code.
• File-based copyleft -- this type of license is more-or-less unique to the Mozilla Public License. It makes a compromise: anyone can use your code for any purpose, including a closed-source, for-profit system, but they may not modify your original code; they may only add new files to the program. Changing a file which was created by you is allowed, but only if they share those changes that you created with you so that you may improve the software.

For individual hobby projects, and even for small commercial projects, the GPL makes a lot of sense. It allows anyone to use your code, as long as the advancements and improvements generated by others can be openly shared. For large-scale enterprise software, however, it can be a little complicated. I mentioned earlier the different models of open-source businesses: Support/Software-as-a-Service, and Enterprise-as-a-Service (where you implement custom, proprietary functionality to your own tools, for profit). The Software/Support-as-a-Service models are compatible with copyleft licensing. It's simple: we offer software for free, and those who want to deployed instance and want to support the development will pay the developer to make it happen. Things get quite tricky for the Enterprise-as-a-Service model, however. Implementing custom features and proprietary components to a system can be incredibly profitable, especially for tools where you do not maintain the original codebase, but only extend what is there. A copyleft license does indeed stop this from happening. Some may say that this is the entire point of the copyleft license: to stop a big company like Apple from taking your work, including it in their operating system, and not paying you a cent. Others say that there are points to be made for private, internal business use-cases where it makes sense to have a license that allows modification of the software in a proprietary context. So let's reach a compromise.

TODO: CITATION NEEDED

The Mozilla Public License allows for the addition of new files to a project, or extensions for the project to be created using any license deemed acceptable. The only thing it does not allow is for anyone to modify the original files supplied in the codebase. Modification, or addition to these files must be shared with the original author to make their codebase better for everyone. Personally, I find this very convincing. TODO WHY?