This is something I’ve been struggling with for a while: I start up many small projects often, and I do NOT want to maintain the projects. I do think that the projects have educational value, however, but I do not want to offer support, wrangle patches/contributions, and write documentation.
Is it good to publish everything publicly? If so, how would I handle organization/resource use (ie on a code forge)? If not, where should the line be drawn?
I think the decision to open-source a project and to have contributions are mostly unrelated. Licensing software onder a FOSS license doesn’t require you to run an issue tracker or mailing list for the project or wrangle patches. That’s just what the big code forges are set-up to do you when you host a project there.
Disabling the issue tracker in a Github repository doesn’t make the software not open-source anymore. I think there’s a great value in publishing your own small software projects because they might be amazing references for people writing other software. That’s why I have a graveyard of abandoned projects at Github still up for everyone to use.
Recall this text from the MIT license, which can be found similarly in many other licenses:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
There is no expectation whatsoever that free software has to come with a community around it, born from the womb with competent moderators and code review and workflows for newcomers to participate and all of this extra labor and shit. You are not actually necessarily signing up for that.
I’ve published loads of software which I have no intention of supporting. SourceHut is explicitly designed to allow for this workflow by letting you publish git repos without accepting contributions or bug reports or any kind of bidirectional interaction with the recipient. This is a totally valid way to approach FOSS and the majority of the stuff I polish falls into this model.
And as the maintainer of a software forge I can tell you that this kind of thing does not bother us in the least in terms of resource usage.
I did forget to mention how source forges can be used as a portfolio for job-seeking. As someone who is actively looking for a job at the moment, I ask myself, “Do I want an employer to look at every single bad no-name project I have created, or do I offer a curated view of what I have been working on that best represents my abilities?”
Consider places like Sourcehut, where there is no easy way to pin/rank manually the projects/repositories. If your projects are meant to be a representation of your capability of being hired, would your answer change?
Well, I think that the whole forges-as-a-resume thing is pretty toxic, but at least on SourceHut you can separate your misc. unsupported garbage repos on git.sr.ht and only create projects on sr.ht for the good stuff. That’s how I do it. Compare:
Although the forges-as-a-resume thing is terrible, it is unfortunately something that happens. I do the same thing as you—highlight “projects” instead of the source repositories. Thanks for the feedback :)
I use to develop in the open, I am not “famous” of any sort so my repositories don’t get traction on their own if I don’t push them.
Now the enthusiasm and the time I had a few years back when I was developing many libraries shifted and I don’t feel this pain that much anymore but I will keep releasing my code somewhere to keep track of it and because who knows, if somebody can get inspired by that I am happy!
If you think there’s value in publishing the project - do so! You are not obligated to offer support, nor to accept patches, nor to write documentation. A README clearly stating that is good enough, I’d say.
Some forges allow you to disable issue and pull request creation, too, making your intention to “just dump it here for educational value, take it or leave it”. Both SourceHut and Codeberg can let you set up a project like this: with code only, no bug trackers, no mailing lists, no pull requests. Just code.
While perhaps you should consider publishing a private project without any explicit channel for contributions, support, or the like, there is no moral obligation to do so. Similar to how it is a fine thing to play an instrument for your own enjoyment without allowing others to get involved, it is a fine thing to write software for your own use or enjoyment or whatever without allowing others to get involved.
What I dislike is publishing software that is explicitly non-Free.
You publish something as Free software without contact channel? Great!
You publish something without a care for copyright, not providing an explicit license but allowing others to download it? Uh, thanks for that, although it’s less useful than Free software.
But you publish something but explicitly prohibit others from using it? From modifying, from distributing it? That’s not good. Don’t do that.
A good way to diffuse any such concerns is to add a one-line readme saying:
Personal hobby project, not intended to be useful for anybody else
License text draws a boundary on what is legal, but readme is where you tell your (non-)users what to expect within (pretty wide) boundaries of legality.
I think the default expectation is that no support is offered, but also that the software is not actively deceitful and harmful (eg, publishing malware which masquerades as a normal useful project is not cool).
But, if you have any anxiety, you can spell out your personal expectations.
For the cases where you do want to give some bounded amount of attention/support, I find these two interaction protocols useful for diffusing tension:
Friendly Fork Protocol: positively encourage forks. If someone wants to do something with your project, but you are not sure if that’s the right direction, encourage them to fork and mention a fork in your readme. Maybe you are wrong, maybe you are right, the best way to figure is out is to let everyone to do the thing they feel passionate about. There are a lot of tricky boundary cases here for larger projects that accumulate social capital which can’t be forked, but for most low-stakes things this works perfectly.
Optimistic Ping Protocol: If someone wants to ping me about any software I’ve written (or about anything else) for whatever reason, big or small, they are free to do it whenever, they don’t need to worry that they might be pinging me in the middle of the night, monopolizing my attention or some such. At the same time, I reserve the right to not respond and to not feel bad about that. This protocol optimizes for communication happy path (and the sad path is bounded by the friendly fork protocol — if I completely ignore something where my attention is required, forking the thing in question would remove the need for my attention).
Personally I don’t actually see a point in developing any software privately (except for just trivial “play” and test code) and not making the source available under a FOSS license. It doesn’t make me much work, I want to host it anyway on some source forge for convenience. And if someone finds it useful that’s cool. If I get the occasional unexpected patch on some small code that’s cool as well. And if I don’t want or expect any contributions I can make this clear in the project description.
My line of thinking is pretty similar to phw’s. Having my project on a forge somewhere is useful because it’s basically an offline backup and makes it easy for me to find in unexpected circumstances (like if I want to show someone something on my phone when I don’t have my laptop with me). Arguably we could design technology in a way to prevent the need for this solution, but that would have its own tradeoffs.
I was drawn into computers for two reasons: making computers do cool stuff is fun/satisfying, and free software has a culture of sharing and collaboration. When I post my code online and make sure people can use it without legal risk, it makes me feel good. When I keep code private and tell people they have do me favors in order to get a copy of it, it makes me feel bad. I like feeling good. =)
I have recently come to the conclusion that a big reason why I enjoy using SourceHut so much is the lack of publicity and project features by default. If I coded a little thing and put it up on GitHub I get and issue tracker, a wiki, pull requests, discussions; people can like and follow my project and what not. This all raises expectations
On SourceHut I can just upload without all this stuff. I can make the project public, but still only provide a simple git repository. I don’t have to put any contact information there, I don’t need to accept (or decline) patches. If all I wanted to do is to make the code public for my own personal convenience and for others to use if they find it useful then this is all I need. Not every little code needs to be a project. And just because I made my code available as free software doesn’t mean I must care about making it runable on some person’s system.
I can then decide for myself how much I want to make my code public. And if the little code actually turns into a project and gains momentum I can enable the issue tracking, mailing list, accept patches etc.