💾 Archived View for auragem.letz.dev › devlog › 20231204_2.gmi captured on 2024-08-25 at 00:54:35. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
Originally written 2022-08-13. Released later as part of my goal in speakig out about the exclusivism within tech communities.
I originally wrote this in 2022 as a response to an article. For some reason I decided not to publish it (actually, I think I posted it for an hour or so, and then decided to take it down). Reading it back now, I do not really know why I did this aside from maybe my critiques of the Open Source community. I have removed one phrase that I think was needlessly provocative, but aside from that, I do not think I am being too harsh in this post. Well anyways, thanks for reading!
Response to:
"If X You Shouldn't Release Software" (ew0k)
Hello, small-time developer here who doesn't even have a job, gets absolutely no money from this, and is going to college full-time. I wanted to give my perspective on this, because I generally don't agree completely with ew0k, although I understand where he is coming from. I generally prioritize and care for my ability to quickly fix bugs and add features other people want to my capsule, so that will be where I am coming from. This doesn't mean I need to care about everything or take all suggestions, but it means I generally try to think of what other people would want than just myself.
Note that I try to balance between things that can be done and things that can't, so things later in the article affect and contextualize things earlier in the article.
The first thing I will say is that you shouldn't get users invested in using your project if you are not going to provide *necessary* (as in, the software cannot function without specific...) features/fixes for at least a little while. If you created software solely for your needs, and it's generally limited to your specific needs, workflow, computer, OS, keyboard, language, and others, then nobody actually needs you to post it online. By publishing your software, especially without some notice or documentation of what exactly your software does and supports, you are creating an expectation that the software will fit the needs of at least *some* other people. However, a lot of the time, this happens to not be the case. There are many projects that I have seen that are literally broken, or what the project does is very limited, even though it gives the impression that the project is intended for something much bigger. These projects are not actually useful and just create more clutter when people try to find something actually useful, because now the user has wasted time trying to look into your project just to find out that it's broken or very limited, and then they have to give up all of the work they put into trying to use your project and move onto something else. This is especially a problem for libraries, in particular.
There is a saying here that I think is sometimes useful - "just because you can, doesn't mean you should". But, I would like to expand this saying into something more contextual - "you should if you should, not just because you can". Meaning, just because you can do something, doesn't mean you should *unless* there's a significant enough improvement.
The above is, however, very different from projects that have a fixed feature-set that clearly documents and outlines that feature-set. These are perfectly legitimate to publish online. AV-98 has a fairly fixed feature set that works and follows the spec quite well, afaik. The features added in the fork are fairly minimal, which perfectly demonstrates how much of AV-98 still works.
This certainly helps with users that are tring to find something for their needs, but what if their needs are not met anywhere?
Small developers *can* do all of the things ew0k mentioned are generally hard or time-consuming to do. I've seen small developers do them. To undervalue your abilities and the abilities of small developers creates a culture where the standard of what a small developer does is so low as to be problematic for software as a whole.
Lagrange has RTL langauge support. It has this because it uses libraries that provide this feature (freetype, harfbuzz, and FriBidi). It's not as if a small developer needs to create all of this from scratch. If we continue to undersell what developers can do, then we won't have the self-esteem or courage to do the things that are needed for the betterment of all software.
Another problem that affects small-time developers is the time that they have. Many small-time developers have jobs or college or families, so they don't have a lot of time to program, and so they have to be choosey with what time they do have. Sometimes a developer thinks that they don't have the time to do something, so they don't try to do it at all. However, if something is worth it, even proramming a little bit of that feature at a time in the time that you do have can help, even if it ends up taking a long time to get it done. You don't have to have a feature complete in a day or a week. Use the time you have and be persistent in setting aside that small amount of time everyday for a month or a few months or however long it takes. It is hard to do, and I can't even do this myself, but it will improve your ability to finish projects, your patience, and it will be worth it in the end.
ew0k suggests that the reason for not suporting accessibility or right-to-left languages, or other features of that sort, is not due to indifference, but I think this is only partially true. By definition, if one only cares about the features that are useful to them, then it *is* indifference, by definition, to not care about features that you don't need. The result of this indifference is that many *users* will almost never, or very rarely, get the features that they need, because no programmer wants to cater to them.
Everyone does have the right to not care about what they don't want to care about - that's true. But this is also the typical argument from people who prioritize their own freedom over social responsibility 100% of the time. Yes, you have a right to not care, but that doesn't mean you don't have a social responsibility to do the things we are able to do or that we shouldn't care more about things.
For example, for all of the developers working on Gemini browsers and servers and capsules, etc., how many support RTL or any type of accessibility? Not many. That means people who need RTL or accassibility cannot use Gemini. This limits the community, and it's a bias against the very people that Gemini would especially be useful for (what is more accessible than text-only content for deaf and blind people?). We are missing opportunities here. We need more people to care about these features.
Part of the indifference is the expectation that if a user needs something, then they will add it themselves. However, this only works if that user is a programmer who can understand your code, has the time to implement their features, AND **has the physical ability to program**, too! I do not believe that all users of computers must be programmers, especially when programming is generally pretty hard. Knowing how to run and use a computer is *VERY* different from knowing how to program. To gatekeep the usage of computers to just programmers is... weird. To assume that gatekeeping communities to just programmers creates a more intellectual or sane environment is just plain narcissistic to me, and undervalues the content people of other fields can end up providing us; one must clearly think of themselves very highly if they think that only people who are like them or have their abilities are smart, and this is basically the definition of superiority that undervalues the inherent worth and dignity of all humans, as well as the need for all skill sets and fields. And this type of gatekeeping to just programmers ends up resulting in less diverse content on Gemini, especially Gemini developers only talking about Gemini or their personal lives (a common criticism of our community) and people talking about fields they aren't trained or knowledgeable in. Non-programmers of other fields besides Software Engineering could bring exciting content to Geminispace, so let them.
Unfortunately, not everything can be fixed by small-time developers. Some things are just so broken in the very heart of computing and would require the whole industry, corporations, or big organizations, to fix.
What can we all do? One person doesn't have to fix everything. We each can do our part based on what we are good at. Here are some suggestions: