The main reason is that it takes a lot of time and energy to review pull requests—especially for this kind of software. For example, I have a server that continuously runs Litestream on a database that's constantly producing load. Every time I make a change in how Litestream works, I create and push up a new build to that server and run it for at least 24 hours. After that, I review metrics about performance and throughput and go through the logs to check for any abnormalities. Finally, I have a separate runbook that I go through for manual testing every CLI command and their various options. It's a slow process but it helps catch weird bugs that aren't apparent from automated testing.
As for the license, yes, the PR author agrees with the license but it makes it harder in the future to change the license and then I need to maintain a Contributor License Agreement (CLA) which is more work. I don't have any plans to change the license but I also don't know if that will change in the future.
Have you thought about having an application process to accept new members to the "core" team? The idea that people contribute isn't wrong in itself. It's usually the lack of commitment from the contributor that causes the stress on the maintainer side.
Unfortunately, I think you have to start that process before you get to that point. Otherwise you'll be overworked and attempting to onboard someone on a project for the first time. That probably won't go well.
Why would trying to create a process for theoretical onboarding of members be less work than actually onboarding someone? I disagree. Leave the consideration of onboarding someone until you need it, and then focus on just that for the month or whatever they need to get up to speed, and then switch back to main contribution.
It would certainly more work for you to maintain CLA for your project, but why does sqlite setup CLA? It is sufficiently big project and they could easily setup CLA if they wanted to.
Not OP, but here are the (non-license-based) problems I see with open contribution.
1. It limits tight design. PRs are often going to be for things that the user wants but that aren't on your design plan. Accepting these PRs causes design creep and leads to code complexity, even if each individual PR is written well.
2. It takes time to review PRs. People submit all sorts of code of various quality. Doing several rounds of reviews to get a PR up to snuff (or decide to reject it) takes time out of your day. If your team is small, this is a major cost.
3. It can set the wrong expectations. People get mad when their PR is rejected. Often really mad. Closing 50% of PRs, even for totally valid reasons, ends up with a nontrivial number of people sending you really terrible emails calling you nasty things.
I also want to point out that there's an emotional aspect to this.
Lots of open source is done as a passion project, and passion is a notoriously fickle beast. Things that inspire people to work on passion projects - a sense of ownership, velocity (no need for meetings and jira et al when it's just you. 100% efficient communication!), "shipping"/accomplishment, pride and respect - are all going to be really vulnerable to having to share headspace and ownership with someone else.
I'm personally feeling this. I have a project I'm working on for my homelab that I think other homelabbers, and maybe even some SMBs, will be interested. And I want to give back to the community / have no qualms about someone "stealing" my code. I have an AGPLv3 sticker on my laptop. But the main thing giving me pause is - "but what if people are like 'neat, now please do this feature next!'". Then I'm thinking about it and worrying about disappointing users. And plus, we know that "please do this feature next" is absolutely the *nicest* way that that request will ever be phrased on the internet.
I honestly would feel better if github had a way to let me say:
1. Here's the code, but please don't fork it (but leave the fork button functional. I don't want to actually stop anyone. I just want them to know what I won't be super thrilled.)
2. Please only open issues or PRs for small fixes. An extra if-statement, etc. Please don't add features or redesign anything or "fix my code" at a cosmetic or architecture level.
I know this sounds kinda whiny and entitled and anti-free-software, but I do think it's real and respectful from a human perspective. Locke said that anything you put effort into, you feel ownership of. And by that logic, if someone puts effort into something you currently own "100%" of, they're going to feel some sort of ownership too and you'll feel some part of loss of ownership.
> Please only open issues or PRs for small fixes. An extra if-statement, etc. Please don't add features or redesign anything or "fix my code" at a cosmetic or architecture level.
Another way of putting it might be to encourage them to describe the problem or other desired change rather than send code, and let you deal with it as you see fit.
For instance: instead of raising a PR to fix an open injection vector, raise an issue that says "when responding to X your code doesn't properly sanitise input Y meaning Z can happen".
> I know this sounds kinda whiny and entitled and anti-free-software
Not at all IMO. The word "free" covers many overlapping concepts, and your way of thinking about the freeness of your personal project is no less right than many others. You aren't stopping anyone doing what they want, you are just choosing to be selective about how you interact (which you are, or should be, free to do). Giving other people freedom to do things with your code does not mean you have to give up the freedom to do (or not do) what you want with it.
A long as you are up front and polite about it, there shouldn't be a problem. If anyone did have a problem with it, it is their problem not yours!
If I ever pull my finger out and make progress on my many possible personal projects to the point where there is something worth sharing, for the most part I'll probably take a very similar stance.
#2 is perfectly reasonable, but I don't understand #1 at all. You don't want to accept other people's changes, which is fine, but then you're also asserting a moral right to prevent them from making those changes on their own? It seems like open source is fundamentally not what you want.
I'm not though, they can still click it and have the right to. I won't deny them that freedom.
I just also want to express that I won't be thrilled about someone forking the project and trying to go their own direction with it or something. It'd be demotivating if someone thinks they can do your project better than you can, right?
> It'd be demotivating if someone thinks they can do your project better than you can, right?
If it is a labour of love, then maybe.
If you had plans to monetise then I expect it would be rather annoying too.
But if the project is at least partly "scratching an itch", to make something you want because it doesn't already exist in quite the form you want/need, then someone coming along and doing it better is great. Your itch is scratched and someone else is dealing with maintenance, so you can get on with your next plaything! And if you are counting life karma points, you can claim at least a few for having inspired the other person's/group's work.
Don't want to contradict you, but here is how I feel as a drive-by PR-er:
1. Some projects have a list of goal and non-goals. Rejecting a PR because I didn't read the non-goals is perfectly fine and should be encouraged.
2. I agree. But can't this be solved by putting the "burden of PR" on the PR-er? A long checklist of "I have read this" and "I have tested this" should raise the PR bar high enough to make the code review cost worth it.
3. I understand that bad people are a problem on the Internet, but this feels orthogonal to the "no PR policy". Won't those people "do shit" anyway?
> can't this be solved by putting the "burden of PR" on the PR-er? A long checklist of "I have read this" and "I have tested this" should raise the PR bar high enough to make the code review cost worth it.
People definitely do not read those. The less useful their PR is, the less likely they are to have read any of the stuff in the template.
And, also, it doesn't matter that much if the submitter has done all manual test steps (if any) -- the maintainer mostly needs to verify everything him/herself anyway
Reading code is harder than writing code. It is also not very fun. So when someone files a PR against your project, it means a bunch of not-very-fun effort. It also comes with a social obligation, because someone presumably put a lot of effort into the PR and you don't want to have wasted their time. Obligation + not fun work on a side project that you're probably doing to help stave off burnout turns that project into just another source of burnout. Project management in general just isn't very fun.
If you feel a large degree of ownership over the codebase, you'll also be irritated at including someone else's code/design style. Like having someone else's voice in your head. You could go through the PR and request changes to conform to your code/design preferences, but that would take a lot of your time and also a lot of the contributor's time (and be very likely to frustrate the contributor). It would probably just be easier to rewrite it yourself in your own style. Or just let all that stuff slide. But then your project is less "your" project, and you might not get the same sense of gratification working in the codebase.
Suppose you go to clean up your local park and a monk walks up to you and hands you a book. They then ask you for a small donation. If this kept happening, would it discourage you from cleaning up your park?
The next week, the cleaner returned. The monk offered him the book again, whereupon the cleaner held out his trash bag, that he might toss it in. At this moment, the monk was enlightened.
And the cleaner collected many such books, from various monks, in his trash bag, until eventually he had enough books to start a reasonably large fire, burning the park down, his cat enjoying the heat from the fire
The person going to clean the park is the maintainer of some Open source software, offered for the public good.
The monk handing over the book is the person who has done the work to write a pull request and gift it to the maintainer.
The request for a donation is the cultural expectation of reciprocity. A maintainer now feels pressure to accept the work of reviewing the PR. Yes, they can say no, but it feels bad and can motivate someone to stop maintaining open source software.
That makes no sense, the analogy is wrong on all counts.
An open source project I initiate is not a "public good". I'm sharing it; I still own the copyright.
The monk handing over the book in the park has done no work on the park, they are a user NOT a contributor. In fact, probably a bunch of the trash I'm picking up are those pamphlets. I'm an atheist so the pamphlet is equivalent, at best, to a spam pull request.
> The request for a donation is the cultural expectation of reciprocity.
This is a completely different expectation that the open source expectation. I, personally, feel no guilt at all for telling people proselytizing to go away as I've done nothing to give them the expectation that their proselytizing would be welcome and most people proselytizing expect to be rejected constantly. Contributing back to open source is expected and usually desirable so the expectation that the contribution will be accepted.
Also, the monk is ASKING FOR A CONTRIBUTION not giving one.
I think there should totally be a commonly agreed philosophy of developers being able to say:
"Here's my hobby project, that I write for my own satisfaction. I'm happy for others to use it, and to license it under my choice of open source license. I am not though, going to feel obliged to change anything about my work on it in response to demands, requests, ideas, advice, or pull requests - or even acknowledge or read any of those. This repo will continue to be my hobby project to accomplish my goals in my timeframes for my personal amusement. If you find it useful? Great! If you want something different? I hope you make it yourself and maybe share it to, or at least find what you are looking for somewhere else, good luck."
There's a fundamental difference between "scratching your own itch" and "becoming a software project manager and community leader". I'd much rather people who only ever want to do the first of those, don't feel the need to keep all their code hidden out of fear of being pushed into the second of those.
The crux of the biscuit is: If it entertains you, fine. Enjoy it. If it doesn't, then blow it out your ass. I do it to amuse myself. If I like it, I release it. If somebody else likes it, that's a bonus.
I wonder if Bandcamp or Soundcloud artists get driveby commenters saying things like "It needs more cowbell" or "Here, I recorded a string arrangement for the second chorus, please add it in and republish!"
Efforts from non-experts would likely hamper a complicated project like a database. Even though the hypothetical denied efforts being earnest well-meant efforts, I can't suggest a riff to bands I like.
On the same note, I recently shared a link[0] to his great beginner talk on functional programming languages. This was by far the best introduction to monoid, monads and few other functional programming terms.
Direct youtube[1] for those who don't want to click twice :)
Right. The 'alias' word is a shell built-in[1], so is interpreted by the shell, which is anyway the first process to parse any command line that you type at the shell prompt. It is only after the shell has done its processing of the command line that the processed line is passed to the actual command being invoked (such as sudo or mv or ls or ...), which is done in the argc/argv pair of arguments (using C terminology) to the invoked program. (In Python it is the sys.argv list.)
And the above is also why the shell metacharacters (such as dollar, asterisk, square brackets) that you may use in any Unix command invocation, get expanded by the shell, not by any individual command[2], which is why these metacharacters work for any command, old or new, built-in, external or user-written (in any language, as long as it supports argc/argv-like conventions),
. This is unlike MS-DOS, for example, where some commands supported wildcards but others did not. There, the support was programmed into (only some of) the individual commands. (CMD.EXE of later Windows versions may be different, and IIRC, is more Unix-like.)
