Toolforge
"We are conducting research to better understand how people use Toolforge and gather feedback that will help shape its future."
Since a long time ago, I have dreamed and imagined the possibility of creating new apps, especially web apps.
I may not have strong technical expertise in coding, but I enjoy thinking about new features and services from a user’s point of view. It often starts with a simple thought like, “I wish this app had this specific feature so I could do this more easily.”
In the past, I sometimes pushed myself to turn those ideas into reality. I would start from imagination, then bring it to life through code. As the final step, I needed to host it somewhere. I rented a server, deployed my code there, and considered it done.
Or maybe not.
Usually, I end up being the sole user of the app, and eventually I can no longer afford to keep the server running. The app goes offline, and the idea is shelved indefinitely.
Still, there is a small hope to continue. Some services provide free hosting, although with limited functionality. Some only allow you to host static HTML pages (such as GitHub Pages). Others used to include a PHP–MySQL stack (though one of those services has already been discontinued, and I only recently found a replacement). Because of these limitations, I adapted my apps to fit stricter requirements. Since then, I have consistently built web apps with minimal tech stacks. Some use PHP and MySQL, but most rely on static HTML pages. Thanks to recent developments in Web APIs, it turns out there are many things you can do using just a single HTML page.
Some of the apps I have created are related to Wikipedia and Wikidata. I host them for free on GitHub Pages, where they are accessible through a github.io domain.
At some point, I noticed that these apps were quite slow to access via GitHub Pages. That made me think that deploying them to Toolforge might improve performance, since they would likely be hosted closer to the Wikipedia and Wikidata APIs they rely on.
So one day, I tried using Toolforge for the first time.
The documentation is clear and helpful. Even though there was no exact example that matched my use case, which is deploying static single-page HTML apps, I was able to reverse engineer an existing example and adapt it to my needs. I documented what I learned in a Substack post so that I could refer to it later when deploying other tools.
It worked, although the process is more complex than using GitHub Pages.
On GitHub Pages, you simply upload your files to a repository and enable the feature.
On Toolforge, I have to log in to toolsadmin, create a new tool, set up a new repository in GitLab, upload the code, adjust configuration files, connect via SSH, and then run the tool.
Later, I received an announcement that API throttling would affect apps hosted outside the Wikimedia domain. That meant I needed to migrate my tools from GitHub Pages to Toolforge to avoid those limits. I started migrating them one by one, especially the ones I use most frequently.
By then, I had already forgotten how to deploy tools on Toolforge.
Fortunately, I had written a guide for myself in that Substack post. I followed my own instructions carefully, and it worked.
Here are the tools I currently develop and maintain on Toolforge.
Each of them has its own background story. For example, I built wd-nearbyitem while participating in a Wikidata datathon. I built wdlite during a Wikimedia Hackathon. I built wdquery after reading the weekly Wikidata Status Updates, where I learned about the newly launched Wikibase GraphQL and decided to test its capabilities. Meanwhile, wplmon was built to support a research project I am currently working on.
“Functional gaps or new features I would like to see in Toolforge”
I would like to be able to view user statistics for each tool I deploy on Toolforge. Knowing which tools are popular and receive a lot of traffic would be valuable feedback for developers.
As of this writing, there are 3,959 tools hosted on Toolforge.
I wish it were easier to explore them. Perhaps there could be an interface similar to an app store, or a website that includes reviews, forums, developer interviews, and practical guides. Features like “tool of the week” or “tool of the month” could also help highlight interesting projects.
“Opportunities for better supporting tool maintainers”
It would be helpful to have a shared group chat for tool maintainers, similar to Slack or Mattermost. For example, in the OpenStreetMap USA Slack group, there is a #dev channel where people share progress, help newcomers learn, discuss trends, and even have casual conversations. A space like that could make the experience less solitary and help build a more active and supportive developer community.