5 ms·

Hi, Litestream author here. I'm happy to answer any questions about the policy or the project itself. I was apprehensive about adding the closed-contribution po

Hi, Litestream author here. I'm happy to answer any questions about the policy or the project itself. I was apprehensive about adding the closed-contribution policy but I've seen overwhelmingly positive support for it since I released. Some commenters have noted that I could use another free code hosting platform. That's a valid criticism. However, I like the tools and workflow that GitHub offers personally. The GitHub Discussions feature in particular has been a nice step toward improving communication. GitHub Actions have been really nice for a CI workflow too.

__henil 6y ago
Can you ELI5 why open-contribution is a problem? Doesn't the person opening a PR on your project agree with the license your project is licensed with? (sorry for the unintended tongue twister)
- jhare 6y ago
  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.
- benbjohnson 6y ago
  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.
  - __henil 6y ago
    Thanks for the explanation. 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.
    - __henil 6y ago
      why does sqlite does not setup CLA*
  - imtringued 6y ago
    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.
    - benbjohnson 6y ago
      Yes, that'd be a good option and something I would consider if the workload increases to an unmaintainable level.
      - jancsika 6y ago
        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.
        ashkankiani 6y ago
        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.
- ahelwer 6y ago
  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.
  - afarrell 6y ago
    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?
    - imtringued 6y ago
      If the monk constantly talks about how the park isn't clean enough [0] then yes. It certainly would. [0] Your software is missing feature X = your park isn't clean enough
      - afarrell 6y ago
        Even if the monk wasn't doing that, I'd be annoyed.
    - Igelau 6y ago
      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.
- UncleMeat 6y ago
  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.
  - __henil 6y ago
    Those make a lot of sense. Thank you!
  - cashewchoo 6y ago
    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.
- bigiain 6y ago
  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.
  - wrycoder 6y ago
    Some in the music business are more candid: 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. -- Frank Zappa
    - bigiain 6y ago
      Heh. 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!"
jansan 6y ago
No question, just want to say that I fully understand and support your choice. I run a tiny open source project and literally the first PR was just a terrible experience. A one liner that fixed a bug but introduced new issues. So we wrote our own fix and then got insulted to not use the original PR. Yes, being able to switch of external PRs would be a bliss.
- lbill 6y ago
  Yep, you still have to deal with all kind of people when you do OS, and that isn't always nice. I once made a PR to a project I use a lot at work. The PR was about the documentation of the project, so no change to any feature, no new thing, just an improved version of the tutorial... Or so I thought. The maintainers refused my PR. My first instinct was to be upset about it, but then I thought "this might be a natural reaction because they said 'no', but maybe, just maybe I can avoid acting like a kid and use my brain". So I re-read their reply: it contained a valid reason and provided me with a good solution to my problem, I thanked them and moved on. They were just right to refuse my PR.
- hk__2 6y ago
  Four years ago I got a PR on a small side-project. It was a nice new feature, although it wasn’t exactly the scope of the project. At that time I thought it would be better to accept the PR since the contributor put some efforts into it, and it would have been rude (or so I thought) to say no. Four years later, I’d say 50% of the burden on that project is due to the feature that PR introduced. I often think about that time, and during these four years I’ve learnt to say no to PRs, mostly after seeing more-experienced open-source leaders doing so. The key aspect is maintainance: contributors come with a feature, they add it to your project, and then the maintenance burden is on you forever. Too much maintainance means you burn out, and the project is dead. It’s important to keep that in mind when deciding to accept or refuse a PR. To avoid misunderstandings and angry people, you should be as neutral as possible: is it a good addition on the long terme? How much maintenance cost does it add? Will it make the project easier/harder to evolve?
bachmeier 6y ago
> I like the tools and workflow that GitHub offers personally. Worth a side note since you mentioned sqlite that Fossil was built to support the "open-source, not open-contribution" workflow. One of the leading criticisms of Fossil is that it's not designed to support the open contribution approach.
tomjen3 6y ago
If I had a feature I wanted to put in, I would just fork your project and add it, right? Then your project (presumably with out that feature) would be competing with mine, but each time you added another release I can just merge it into mine, but you won't do that? If so, don't you see yourself getting outcompeteted by forks?
ashkankiani 6y ago
I think that most experienced open source maintainers would probably understand this approach, and it's definitely something I've considered making explicit rather than implicit. I don't find rejecting people too difficult or mentally taxing, though, personally, so I haven't felt the need to reach for an explicit policy. I can point to this as an example, at least, if I ever do. I found your wording to be sufficiently explanatory. Good luck with the project.
passthejoe 6y ago
Your position is extremely reasonable and realistic. I commend you for stating it openly.

__henil 6y ago

Can you ELI5 why open-contribution is a problem? Doesn't the person opening a PR on your project agree with the license your project is licensed with? (sorry for the unintended tongue twister)

jhare 6y ago
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.
benbjohnson 6y ago
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.
- __henil 6y ago
  Thanks for the explanation. 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.
  - __henil 6y ago
    why does sqlite does not setup CLA*
- imtringued 6y ago
  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.
  - benbjohnson 6y ago
    Yes, that'd be a good option and something I would consider if the workload increases to an unmaintainable level.
    - jancsika 6y ago
      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.
      - ashkankiani 6y ago
        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.
ahelwer 6y ago
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.
- afarrell 6y ago
  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?
  - imtringued 6y ago
    If the monk constantly talks about how the park isn't clean enough [0] then yes. It certainly would. [0] Your software is missing feature X = your park isn't clean enough
    - afarrell 6y ago
      Even if the monk wasn't doing that, I'd be annoyed.
  - Igelau 6y ago
    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.
UncleMeat 6y ago
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.
- __henil 6y ago
  Those make a lot of sense. Thank you!
- cashewchoo 6y ago
  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.
bigiain 6y ago
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.
- wrycoder 6y ago
  Some in the music business are more candid: 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. -- Frank Zappa
  - bigiain 6y ago
    Heh. 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!"

jansan 6y ago

No question, just want to say that I fully understand and support your choice. I run a tiny open source project and literally the first PR was just a terrible experience. A one liner that fixed a bug but introduced new issues. So we wrote our own fix and then got insulted to not use the original PR. Yes, being able to switch of external PRs would be a bliss.

lbill 6y ago
Yep, you still have to deal with all kind of people when you do OS, and that isn't always nice. I once made a PR to a project I use a lot at work. The PR was about the documentation of the project, so no change to any feature, no new thing, just an improved version of the tutorial... Or so I thought. The maintainers refused my PR. My first instinct was to be upset about it, but then I thought "this might be a natural reaction because they said 'no', but maybe, just maybe I can avoid acting like a kid and use my brain". So I re-read their reply: it contained a valid reason and provided me with a good solution to my problem, I thanked them and moved on. They were just right to refuse my PR.
hk__2 6y ago
Four years ago I got a PR on a small side-project. It was a nice new feature, although it wasn’t exactly the scope of the project. At that time I thought it would be better to accept the PR since the contributor put some efforts into it, and it would have been rude (or so I thought) to say no. Four years later, I’d say 50% of the burden on that project is due to the feature that PR introduced. I often think about that time, and during these four years I’ve learnt to say no to PRs, mostly after seeing more-experienced open-source leaders doing so. The key aspect is maintainance: contributors come with a feature, they add it to your project, and then the maintenance burden is on you forever. Too much maintainance means you burn out, and the project is dead. It’s important to keep that in mind when deciding to accept or refuse a PR. To avoid misunderstandings and angry people, you should be as neutral as possible: is it a good addition on the long terme? How much maintenance cost does it add? Will it make the project easier/harder to evolve?

bachmeier 6y ago

> I like the tools and workflow that GitHub offers personally. Worth a side note since you mentioned sqlite that Fossil was built to support the "open-source, not open-contribution" workflow. One of the leading criticisms of Fossil is that it's not designed to support the open contribution approach.

tomjen3 6y ago

If I had a feature I wanted to put in, I would just fork your project and add it, right? Then your project (presumably with out that feature) would be competing with mine, but each time you added another release I can just merge it into mine, but you won't do that? If so, don't you see yourself getting outcompeteted by forks?

ashkankiani 6y ago

I think that most experienced open source maintainers would probably understand this approach, and it's definitely something I've considered making explicit rather than implicit. I don't find rejecting people too difficult or mentally taxing, though, personally, so I haven't felt the need to reach for an explicit policy. I can point to this as an example, at least, if I ever do. I found your wording to be sufficiently explanatory. Good luck with the project.

passthejoe 6y ago

Your position is extremely reasonable and realistic. I commend you for stating it openly.