- From: Sarven Capadisli <info@csarven.ca>
- Date: Fri, 25 Oct 2024 15:25:29 +0200
- To: public-solid@w3.org
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