Projects

On this page, you’ll find the open source projects I currently maintain or contribute to.

All other projects or experiments can be found on my GitHub account.

• Paw: Simple, Modern and Privacy-Focused Open Source Password Manager
• Fyne: An easy-to-use UI toolkit and app API written in Go.
• Fyne Cross: A simple cross-compilation tool for Fyne applications.

Maintenance policy

Link: https://lucor.dev/projects#maintenance-policy

Updated: April 2024

This policy explains how I work on my open source projects, what you should expect from me as a maintainer, and how to contribute.

How I work on open source projects

I work on open source projects in my spare time.

This means there might be extended periods during which I am not actively working on a specific project. This does NOT mean the project is unmaintained: I still read every issue filed, and would react promptly to urgent issues, such as security reports or any breakage that makes a project not work anymore for its current users.

If a project is unmaintained, it will be archived.

Projects have a precise scope

Most of my projects are meant to be simple solutions to a specific problem, and I generally try to resist scope creep.

I understand that might make them not a good fit for you, and that’s ok. Feel free to open a discussion or a feature request, but please understand if we conclude that the issue is out of scope. Forks are welcome!

This is critical both to keep the UX simple, and to keep the maintenance burden manageable.

Well researched issues are gold

The most useful contributions are detailed issue reports. The more you can tell us about environment and expectations the better. I truly appreciate when users investigate further, or do the work of checking how other implementations behave, or what the relevant specifications say.

Even if you can’t do the extra work, feel free to open an issue. I don’t resent any issue, they’re all gifts (but as gifts they don’t entitle you to a response).

Experience reports are gems

Even if something might look like it’s working as intended, or if you’re encountering a non-technical issue, I invite you to file an experience report.

It can be as simple as “this error was confusing, even if I figured it out” or as high-level as “getting started was a mess, here are all the things I tried” or as specific as “when I try to use this for this workflow it’s very clunky”.

Focus on your experience, not on the solution. Oftentimes the solution will need to take into account the needs of other stakeholders, or solve multiple issues at once, but having a clear idea of a problem is the first step.

Maybe we will conclude there’s nothing we can do within the project’s scope (see above), but every experience report informs how I think about the project.

If you want to contribute but don’t know where to start, try to use the project from scratch keeping a friction log of all the things that you found confusing or difficult or unclear, and then share that.

PRs might get reimplemented

Unlike some projects, I do not prefer PRs to issues, for a number of reasons.

• Working in batches (see above) means you might have to wait a while before I review a PR, and you might have moved on to other work by then.
• I don’t have the bandwidth for long review cycles, but I am also very particular about the code I accept into a project, since it will be on me to maintain it.
• Contributors naturally focus on their use case and circumstances when writing patches, which might need to be adapted to serve other project users.
• I am generally not trying to build large contributor communities around most of my projects, as they are small scoped tools (see above).

All together, this means that detailed issues are usually more useful to me than PRs, and while you’re welcome to open a PR as a way to demonstrate an issue, you should expect it to be reimplemented rather than merged. Please don’t take this personally. I try to use Co-authored-by lines liberally to share credit where possible.

There are some exceptions, like support for operating systems I am not familiar with, or features I am not well-equipped to implement. We can discuss those cases in the issue tracker. I am also usually happy to merge trivial/short changes.

Funding

I don’t rely on crowdfunding for sustainability, so I generally don’t solicit donations from individuals. However, if you would like to show appreciation or support my efforts, you can sponsor me through the GitHub Sponsors page.

Conduct

Most of my projects don’t have a formal code of conduct, but I uphold the values of the Contributor Covenant and I have a zero-tolerance policy for toxic behavior.

Comments that create an unwelcoming environment will lead to a ban.

Security

Please email me privately at [email protected] to report a potential security issue. If you’re not sure if something is a security issue, reach out! You should expect a reply within a week, usually much quicker.

I am happy with standard ninety days disclosure timelines. I will produce security advisories and file CVEs for any issue I consider a security issue.

I know projects are not entitled to free security research or coordinated disclosure, and I appreciate the contribution of reporters. I do not offer bug bounties at this time.

Attribution

This maintenance policy is adapted from the Filippo’s open source maintenance policy, version fbd61ab, available at https://filippo.io/maintenance