I Made a Keyboard Nobody Asked For: My Experience Making TapType
29 points by ubernostrum
29 points by ubernostrum
The source decision itself is simpler than people seem to want it to be. I made a deliberate choice not to publish it, and the real reason is merge requests, not scrutiny. I do assistive technology training. I do freelance consulting. When I'm not doing either of those I'm planning the next thing, and when I'm not planning I'm doing the life admin that doesn't do itself when you work independently — invoices, scheduling, equipment, the background noise of life. The hours are spoken for. Merge requests are not the same thing as feature requests. A feature request is someone telling me what they want. A merge request is someone else's labour sitting in my queue, representing decisions they made about my code, with a social clock ticking every day I leave it unacknowledged. I did not agree to that. I released a keyboard, not a project, and the difference between those two things is something I thought the absence of a source directory would communicate clearly enough and apparently did not.
I see this sentiment frequently, and it makes me sad, because there's no fundamental reason that publishing source code has to mean that you will accept merge requests, pull requests, patches. It's just something that has become a default social expectation in the GitHub world (I guess because historically you could not disable PRs on GitHub?) but it doesn't have to be this way! Look at SQLite, they simply do not accept external code contributions.
The reason I want to see the source is to understand how it's doing the clever things it does, to make it work on my special and unique configuration of computer, to build onto it the things I wish it had, for myself. Some people want the source to look for malware, or to create reproducible builds, or whatnot. None of this requires you to integrate my work!
Turn off PRs on github, or hell, just upload tarballs in the release. Throw a line in the readme to set expectations. Problem solved?
… one more thing is that a community already burned by disappearance, and also by API churn from platforms, might be more at ease if somethnig can be updated by third parties in the worst cases, including platform changes bad enough for the original author to switch away, but not bad enough to make old code useless for porting forward.
This post was really good, I related to a lot of what the author describes.
I do think the author should reconsider sharing the code. I personally would probably not use the software if I heard a rumour that it was malware and then found the source was kept hidden.
You don't have to release it on github. You can compress it and host it on your website, with a captcha that asks the downloader to type "this project does not accept contributions" or some such thing.
Someone should start TarHub. Just tarballs of source with no expectations that you can contact the author in any way.
I think for Zenodo it would be close to its natural use!
(Many Sourceforge projects are deliberately this way, but mailing lists are also often seen there)