August has been full of surprises at my work, and I couldn’t even fathom how I managed to overcome and bear it day-to-day. One of the unexpected events which startled me was that there were 2 users who sent me an issue towards my email regarding this project that I’ve been working on so far
This project, maestro-reporter, as you can see, is somewhat a straightforward tool for orchestrating and hiding all the abstraction layer when we are going to manage test specifications until its integration when using Maestro (mobile app test framework). To be honest: I didn’t put so much expectation that this ‘small’ utility would be used by at least those 2 users. You read that well, 2 users
That’s the main reason this project wasn’t committed on GitHub (as a common open-source repository). I pushed it on my own GitLab repo instead, believing that, well… nobody was going to use that anyway, so there wouldn’t be any issues coming. And guess what, I was wrong HAHAHA
The email content honestly gave me a big surprise and made me feel alive again. It consisted of a thank you for the utility I’ve been working on, and straight to the core of the content: there’s an issue in my library.
I started to investigate further, and it was true: there were subtle issues in my library. The fix was shipped alongside regression tests, and fast forward, it was already prepped on the v0.7.0 release branch. The patch was merged and released around 13 August 2026, and just one or two days after that release, different users emailed me (again) about another issue: whenever the Maestro test framework returns a non-zero exit code, the report still gets returned in the log if it exists.
At first, I thought it was the same problem I’d just fixed in v0.7.0, since it kinda overlapped with the create-directory issue. Turned out I was wrong (again), it was a different issue. After some investigation, I found at least two core problems I hadn’t accounted for while building this library to fit my own workplace:
- I never expected a user whose workflow was managing test specifications for Maestro piled up together under the same directory. Quite different from how things are organized in my own codebase.
- Maestro itself, when creating reports, automatically generates a report within the root directory using a default file name like
report.xmlor similar.
Because of this, there were A LOT of lessons learned that I never expected to take away:
- Never belittle the things or stuff you’ve worked on. Even if it feels invisible to everyone. Invisible doesn’t always mean it won’t be used by someone. By all means: the probability of someone using your work is never, ever zero.
- I always knew this rule of thumb and held onto it in good faith: nearly 100% test coverage doesn’t mean your app/work has no issues. There’s always some subtle issue you wouldn’t know about.
- During this period, while investigating and preparing a new release for these users, I started to realize that maintaining an open-source library can be tricky and consumes a lot of time and effort. I’m starting to think that’s perhaps one of the main reasons many great open-source projects get discontinued, lack of time to manage them while preoccupied with daily life.