The elephant in the room

This week, a discussion was sparked in the Solid #app-development chat 
room about how open source software generally lacks good quality user 
experience and interfaces. In this conversation, it was expressed that 
our developer community should "get our act together" and devote more 
time and resources to improve these UIs and make them comparable to 
those of proprietary solutions. We would like to introduce you to the 
elephant in the room.

Free and open source software is underfunded [1]. Maintainers are 
overworked and underpaid [2]. This situation makes it difficult for 
developers to provide suitable alternatives to the proprietary tools 
users currently rely on, thereby keeping them locked into platforms and 
services that often make unethical use of their data, subject them to 
algorithmic traps and dark patterns, and force them to relinquish total 
or partial ownership of their content. Proprietary tools are typically 
better funded and have ample resources to design and develop seamless 
experiences and interfaces. These are generally more attractive and 
pleasant for users, luxuries that many open source projects 
unfortunately cannot afford.

Both open source and proprietary solutions offer valuable benefits, 
supporting society as a whole as well as distinct user groups. 
Proprietary research and development have contributed significantly to 
the body of public knowledge, particularly in areas like design and user 
experience. These insights often inspire and enhance open source 
projects, which then adapt and build upon them to create alternative 
solutions accessible to all. And of course at a fraction of the cost, 
proprietary solutions benefit from open source solutions.

Proprietary systems are often designed with various forms of vendor 
lock-in, regardless of which portions of the software can be publicly 
verified to conform to open standards. Additionally, considerable 
lobbying and communication efforts often result in practices such as 
standards washing, open washing, community washing, or commons washing 
[3][4].

Having said that, open source software is not exempt from vendor 
lock-in, especially if it fails to implement open standards where 
possible. The term "open source" is broad and encompasses various 
aspects and characteristics of projects, and fulfilling one of these 
characteristics does not guarantee that a project is conducted openly 
and transparently, or that the software is free from vendor lock-in or 
non-standard solutions.

Dokieli [5] has been attempting to provide a solution for some of these 
pressing issues affecting people today for over 10 years, with very 
limited resources. Initially (c. 2012) it grew out of a frustration with 
the scholarly community, where researchers did not ultimately control 
their own research communication. It quickly evolved beyond just 
research communication (around 2015) to include any kind of article and 
annotation on the web by finding alignment with the Solid project, along 
with the availability of an ocean of web standards at its disposal. Dare 
we say, it was spite-driven development from early on to make a point to 
the world - which continues to this very day. In a way dokieli is very 
similar to the first web browser, WorldWideWeb [6] and Amaya [7]. At 
every step, dokieli has been used to exemplify how far web standards can 
get us to enable individuals and communities to control their content 
and express themselves, and have used this experience to inform the 
standards process. More background at [8].

We are currently working on a project funded by NLnet [9], whose support 
we are very grateful for. This funding allows us to spend some time 
improving the user experience, accessibility, security, and addressing 
tech-debt, among other important tasks that will help towards dokieli 
being usable by anyone.

Although this is helpful and a significant milestone for dokieli, we are 
looking into sustainably continuing the exciting work on the project. 
There is a long way to go in terms of UX research and development, 
implementation of critical features, maintenance and audits, among other 
tasks. Not to forget the complexity of coordinating with other classes 
of products that are largely and intended to be out of its control.

We want to make sure that our sources of funding are ethical and 
transparent, and do not compromise the principles and goals of dokieli. 
Dokieli is free from commercialisation or corporate interests. There is 
nothing to sell, no exits, no shareholders to satisfy. There is no 
vendor lock-in, and users are free to walk away with their content and 
use another standards-conforming application that suits them.

In the spirit of open source, open standards, and (shamelessly) asking 
for support, we'd like to invite you to help dokieli on its journey to 
becoming the best version of itself. Whether it's feedback, code 
contributions [10], financial support [11], or just spreading the word, 
your support can bring us closer to creating an open source experience 
that's polished and competitive with proprietary alternatives. And hey, 
even a little cheer from the sidelines helps keep our spirits high! 
Every bit of involvement brings us closer to achieving our shared goals.

Let's make it so!

-Sarven https://csarven.ca/#i
-Virginia https://virginiabalseiro.com/#me

[1] https://stackoverflow.blog/2021/01/07/open-source-has-a-funding-problem/
[2] https://xkcd.com/2347/
[3] https://en.wikipedia.org/wiki/Openwashing
[4] 
https://netcommons.eu/index.html%3Fq=content%252Fcommonswashing-information-technologies-and-online-platforms-semantic-appropriation-commons.html
[5] https://dokie.li/
[6] https://en.wikipedia.org/wiki/WorldWideWeb
[7] https://www.w3.org/Amaya/
[8] https://csarven.ca/okieli-dokieli
[9] https://nlnet.nl/project/Dokieli/
[10] https://git.dokie.li/
[11] https://opencollective.com/dokieli

Received on Friday, 25 October 2024 13:25:36 UTC