The People Have Spoken

Hey everyone, thanks for the great discussion over in This newsletter is a formal acknowledgment of that discussion, and an announcement of some of the changes I'm going to implement as a result.

As always, I apologize for the lack of development that's been going on around here. I'm going to try to keep things moving as best I can, and I think some of the changes coming down the pipeline are going to make it easier for me to get help so this isn't just a one-man show.

The People Have Spoken!

First off, I just want to say that I appreciate all the suggestions I got the other day. Clearly there is a lot of room for improvement on my part, and I want you all to know that I am committed to making Telodendria the best it can be. The project goals themselves (written in C, minimal dependencies) are still solid and unchanged, but it has become apparent to me that the way we go about achieving those goals needs to change a bit to actually be successful. It has come to my attention that the development process in specific is extremely unfriendly. This needs to change if Telodendria is going to have a strong community around it. Additionally, I realize that Telodendria's target audience is ill-defined. This also needs to change if we hope to "market" Telodendria to the masses. I know we can't appeal to everyone, but by clearly defining and targeting a specific audience, we will get quality contributors that share our interests. Finally, I want to place a stronger emphasis on convention, and less on strict standards compliance. Up to this point, Telodendria has striven for strictly POSIX compliance, which has caused some noticeable divergence from the typical conventions of projects of this nature. We need to fix this so that new contributors are not burdened by having to learn an unfamiliar, custom build system, for example.

It was also mentioned that I haven't been very transparent in my personal development of Telodendria. While I strive to write newsletters detailing all of my thoughts, this is not enough. My release roadmap is poorly defined, my development checklist is sloppy, and I have no real, hard timelines for anything. You all rightfully expect better from me as the lead of what I hope will grow to into a healthy, sustainable project. I want to be more professional and do things correctly; it was always my goal to build an open-source product that is useful to others, and not just some small casual side project, so I apologize for conducting operations as casually as I have been.

I value the community's input, and I've really contemplated it because I don't want this to be a one-person project; I do want a strong community that can help move the project forward when I inevitably run out of time to put in long hours writing code. Even though some of the changes requested go against my initial personal convictions and ideas for how I initially wanted this project to be developed, I want to be flexible and realize that project needs change, and what worked for me, a single developer, isn't going to work for the entire community. With that being said, I am genuinely excited to announce some changes that I hope will move Telodendria forward by making it easier for contributors to get involved, easier for end-users to read documentation, and easier for the common person to understand what Telodendria is all about and why we, the community, feel that it's important.

Development Process Changes

There are a number of large project management level changes that I have implemented, am in the process of implementing, and am intending to implement:

  • Migration to Git: Git is the de facto version control system. It has the highest adoption, and for good reason—it is a spectacularly useful piece of software. Other version control systems are more specialized and more obscure, making them hard to use for most users. For that reason, effective immediately, I am migrating the entire project from CVS over SSH to Git over HTTPS. Here's what this looks like:
    • Gitea is our new code forge. Our instance is available here: It should be fully operational, and registration is open for all—whether you're planning on becoming a hardcore developer, want to submit issues and feature requests, or just want to feel like you're a part of the action, create your account as soon as possible to ensure you get the username you want! Note that there is a repository limit of 1 per user; the intention here being that the one repository would be a fork of the Telodendria repo that you can use to submit pull requests. Please be courteous and do not create multiple accounts; respect the space and others that may want to use it.
    • GitHub: For the moment, the GitHub mirror has been deactivated. The code is still up to date at the time of writing, but no new changes are being pushed right now. I will eventually set up Gitea to automatically push changes to GitHub as well. I also want to note that I will for the time being still not allow issues and pull requests at GitHub. All issues and pull requests will have to be made on the Gitea instance to be recognized. At some point in the future, if I can figure out how to sync issues between Gitea and GitHub, I may do that so that users can submit issues via GitHub, but that will be a future project.
    • The choice between the two was hard: I didn't take the decision lightly to exclusively use Gitea. A lot of thought went into this, but ultimately, I decided that a self-hosted Gitea instance is better than GitHub because I really don't want to depend on a large, centralized corporation for this project. I want the metadata surrounding the project to stay just as open as the code itself, and not be locked into a large vendor. That goes against everything Telodendria, and in fact, Matrix itself, stands for. The only downside that I could find for not using GitHub is that new contributors will have to create an account on our Gitea instance, whereas they may have already had a GitHub account. Other factors were continuous integration and GitHub Pages, but I think rolling our own website will be easier.
    • Patches Room: Our patches room,, will be shut down as soon as I get around to it. It won't be needed anymore, because pull requests will suffice.
    • Issues Room: Our issues room,, will also be shut down. It won't be needed anymore, because Gitea issues will suffice.
    • Releases Room: Our releases room,, will be shut down too. It won't be needed anymore, because Git releases will suffice, and I am fairly certain that Gitea provides an RSS feed for that if notifications are desired. I can also just post release announcements to the main room.
    • CVS Repository: Anonymous CVS access is still available, but the CVS repository will not be updated anymore. All references to it will be removed from the documentation as quickly as possible so that people don't try to go there to get the code. As far as I can tell, this won't be an issue at all because everyone hates CVS.
  • New Website: We will need a new website eventually. The current website design is not a great appeal to potential contributors or the general public. I'm thinking something along the lines of a single static page that has some pretty CSS and does the following in order:
    • Markets Telodendria as the lightest, easiest to configure Matrix homeserver. Our target audience is those of small, maybe even embedded deployments. The website should appeal to these sorts of users.
    • Provides links to downloads and user documentation, both of which will be hosted on the Gitea instance. The man page documentation will be going away. Documentation will become markdown files that are rendered in Gitea instead. The user documentation should be distinct from the developer documentation.
    • Provides links to accept donations.
    • Answers the following questions:
      • What can Telodendria do?
      • When will I be able to chat with my friends using Element? The website needs to clearly target end users and potential new contributors. We can't mix up our developer audience and our consumer audience. The Gitea instance will have the README, which will target our developers.
    • Note: The migration to Gitea is going to break our current tarball repository at Tarballs will just be made available as Git tags. I won't delete the current /pub directory, but I'm not going to deploy tarballs there anymore.

Among the changes will also be the deletion of the, because there are no active users in that room. We can just use the main room for discussing ports if necessary. will stay for the time being, but I may try to figure out how to move newsletters to the main website for better visibility.

Repository Structure Changes

With the management changes, there are also going to be some substantial repository structure changes:

  • The TODO.txt file will be deleted. Gitea issues will be created for everything that's currently in there, and I'll be sure to set up the projects and milestones in Gitea to accurately reflect the information currently in TODO.txt.
  • All documentation in man will need to be converted to Markdown and placed in a new /docs directory in the repo. We'll have /docs/user and /docs/dev for user and developer documentation respectively. I am opting not to use the Gitea Wiki feature, because using plain Markdown files that live in the repo allows us to ship the documentation with each release automatically, allowing it to be used offline. Additionally, mirrors of the code (such as the GitHub mirror) will automatically mirror the documentation too.
  • Proposals will become Gitea issues and be removed from the repository.
  • Releases will be published as Git tags and an appropriate Gitea release. Change logs will be maintained as markdown in the repository, but copied to the release page when the release is made.
  • The build system will be switching to Make. If we can only maintain two Makefiles (one for Cytoplasm, and one for Telodendria), that would be ideal, but if we have to ship a GNUmakefile as well, we can do that as necessary. The current system of shell scripts works great, but it's not conventional. Using Make will make Telodendria much more familiar for people that develop in C, and everyone in general seems to be more comfortable with a project that uses the standard tooling available to it instead of building something custom.

Project Lead Changes

Here's what I'm committing myself to:

  • Transparency: I want to be more transparent. Gitea will make this easier, I think. I will utilize all the features of Gitea that are available, including Projects and Milestones, and I will keep these as up-to-date as possible. I will open issues for everything that comes to mind, and I will make changes to the main repository in the same manner that I expect everyone else to—fork the main repo and make pull requests. I will frequently update with the things that I am currently working on or thinking about.
    • TWIM: I'll try my best to make more TWIM announcements as I make progress. I think a TWIM is definitely in order for this week, as there are a lot of big changes happening, but I'll try to make this a weekly thing, even if it's as simple as stating that there were no commits in a given week.
  • Defining Project Goals: I'm going to work hard to try to define a new set of project goals, including who the target audience is and more importantly why such an audience should care about Telodendria.
  • Timely: If you submit a pull request or issue, I will review it and provide feedback in a timely manner.
  • Involved: I am very busy, but this project is really important to me, so I'm going to be as involved as I can in leading the project in the direction that it should go.
  • Open: Your opinion matters. Don't ever hesitate to share it with me so we can discuss it. I'm not promising that I'll change my mind or change the project direction on a whim, but I will at least consider all the opinions of the community if they are respectful and constructive.

Stay Tuned, and Get Involved!

This whole process is going to take some time, so please be patient as things progress. My first order of business from here is going to be to migrate everything out of TODO.txt and into Gitea issues/projects/milestones. From there, I'll start converting documentation to markdown and adjusting it as necessary. You all are more than welcome to pitch in and help out in this process as well. Now that we're using Git, you all can use the standard pull request procedure that you're familiar with. And don't hesitate at all to start opening issues on the repository! That is a valid and much needed form of contribution too.

And, as always, if you want to financially support the project—time and computers aren't free after all—you can find the links here and on the main website:

That's All

That's it from me for now, but share your comments with me! In particular, let me know if I missed anything important.

Previous Post Next Post