My boundaries as an open source developer

An open source project (in most licenses) offers zero assurance of it being usable for production and that's what it means. If you want to use it for production you need to either (a) do whatever evaluations you feel necessary to ensure it will be stable for production for your needs, or (b) pay the authors for a signed support contract so they take on that responsibility.

My point was that my reaction to things like feature requests I didn't want to build was a signal that I wasn't interested in building just a user base for the project. If what I were interested in were building a project that people wanted to use, could sell to them, etc., then I would discard my notions about what I wanted to build and I'd build what people wanted. That was the epiphany I had. I realized I had been lying to myself about my motivations. I realized that my actions proved I didn't really care about getting people to just use the software.

Because I was so annoyed by the lack of contribution, despite the obvious signals that people were using the software, I (eventually) realized that my true goal was for people to interact with my code, not my program. There's a difference there. Any feature in a program can be implemented in any number of ways. But there's necessarily only one way that it's implemented in my program. Thus to be more focused on contributions than usage implies that I care more about how people see my implementation of the features than the features themselves.

I didn't start these projects thinking, "let me make a thing that will prove my prowess as a developer". I made the things to scratch some personal itch. The software on its own fulfills that particular need.

The act of open sourcing it was a different thing entirely. It's not trivial to open source a project; there's a lot of work in trying to prepare it for use by other people. Why go through all of that? What need did I expect opening the code to fulfill for me? Opening code doesn't attract users. So few users care if a project is open or not that they can safely be ignored as a rounding error. So why focus time on opening the code, verus any other action I could take with my time?

Thus the realization that I had been deluding myself.

Although I respect the author's boundaries, that is sadly just part of the job of putting your work on the internet. This does not just stop at open source, if you put anything out for the world to consume, do know that this is what you're signing up for whether you like it or not. People will "find a way" to contact you and won't read your boundaries or even know about them before they do.

I keep an autoresponder in a notes file that I copy and paste regularly as it's a full time job to keep up with the requests.

Exactly. When your colleague wants to write new code in your repo you do a code review. When a stranger writes a large amount of code shouldn't you also do a code review?

Occasionally happens to me. I mean, not dozens of times a week, but I've had a few weeks with more than a dozen times.

> fix bugs

"Please file an issue at http://the.issue.tracker/wherever"

> or build new features

"Please file an issue at http://the.issue.tracker/wherever"

> set up consultations

So, this one is interesting. I mean, it almost never happens to me, and certainly not w.r.t. my FOSS specifically. If I were looking for work, this would be a boon, would it not? And if I'm fully booked, then:

"I am currently not available for consultancy. You may inquire again, if relevant, in ____ months."

> or discuss business opportunities.

"I'm sorry, not interested. Good luck with your business."

Although I guess if there were dozens of these emails per week, I would create a private email box and keep the existing one only for FOSS-support-related business, attending to it every couple of weeks or so. And perhaps create an auto-reply with the above replies :-)