Open-source, not open-contribution

Hi, Litestream author here. I&#x27;m happy to answer any questions about the policy or the project itself. I was apprehensive about adding the closed-contribution policy but I&#x27;ve seen overwhelmingly positive support for it since I released.<p>Some commenters have noted that I could use another free code hosting platform. That&#x27;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.

Github really needs to allow people to disable the &quot;Pull Request&quot; tab on repos, to reduce the stigma around not accepting pull requests.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;isaacs&#x2F;github&#x2F;issues&#x2F;1191" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;isaacs&#x2F;github&#x2F;issues&#x2F;1191</a> 3 years and counting.<p>Some people are resorting to adding bots which auto-close PRs with a message like &quot;Sorry, I&#x27;m not accepting PRs at this time&quot;, but that only triggers once the person has put in the effort to patch your project, at which poi t they may get annoyed to be suddenly told that PRs aren&#x27;t welcome.<p>Best solution is to keep code somewhere other than github. Is sourceforge still around?

This was a problem for us and the lack of the ability to switch off PRs continues to cause problems.<p>Community submissions are virtually always throw away, particularly on a complex code base. We ended up saying it&#x27;s a legal problem [1], which it partly is. But throw away not only because of quality issues, always because of project scope issues.<p>Yes, you feel the project is completely useless unless emoji icons animate in diagrams. That&#x27;s great, fork the project and kill ours off by adding the feature (which they won&#x27;t and it won&#x27;t).<p>When you know what the project scope is, tight enforcement of that scope is critical to prevent the complexity of the project from running away and ultimately killing the project entirely.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;jgraph&#x2F;drawio" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jgraph&#x2F;drawio</a>

I&#x27;ve disabled Issues in some of my popular UI libraries and I couldn&#x27;t be happier. Specially notorious was Picnic CSS[1] where many of the issues were on the level of &quot;hey can you give me the code for X&quot; or &quot;how do you do X&quot; where X was a general CSS question and not related to the library at all. I&#x27;ve also received unkind words when I closed some of my repos issues as a PR [2][3]:<p>&gt; If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM).<p>&gt; part of offering these to the public through open software is maintaining them and allowing feedback from users.<p>&gt; It seems umbrella.js project suffers the same desease.<p>I&#x27;ve noticed there was a strong push around 2016-2018 to recommend newbie programmers NOT to go to Stackoverflow, but instead to ask the questions straight in the Github issues. Turns out, the problem was low quality questions all along, and that just converted an issue that StackOverflow had solved long ago into burnout for open source developers on Github.<p>Github needs to step up their game and give authors more powerful tools, there&#x27;s so many entitled developers out there that will come and demand changes. It might make new devs feel less welcome, but the balance is tipped way too much to allow anyone to create massive spam for projects right now.<p>[1] <a href="https:&#x2F;&#x2F;picnicss.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;picnicss.com&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;franciscop&#x2F;picnic&#x2F;pull&#x2F;203&#x2F;files" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;franciscop&#x2F;picnic&#x2F;pull&#x2F;203&#x2F;files</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;franciscop&#x2F;picnic&#x2F;pull&#x2F;202" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;franciscop&#x2F;picnic&#x2F;pull&#x2F;202</a>

Question for the OP (farslan). I do apologise in advance if this is something you wouldn&#x27;t want to discuss, but do you think a notice such as this would have prevented you from burning out in regards to your open source projects?<p>You have contributed immensely to the go community and I expect the decision to take a step back from open source contributions was hard and that you probably have revisited it often. I wonder if you have thought of things that might improve the process for other maintainers. Would the ability for example to disable pull requests help? Maybe a way to ask&#x2F;find people to help moderate the issues or PRs before they reach you?<p>Thank you both (Fatih and Ben) for all the hard work you&#x27;ve put into open source.<p>---<p>ps. For people who might not know what I&#x27;m talking about, this might help. <a href="https:&#x2F;&#x2F;arslan.io&#x2F;2018&#x2F;10&#x2F;09&#x2F;taking-an-indefinite-sabbatical-from-my-projects&#x2F;" rel="nofollow">https:&#x2F;&#x2F;arslan.io&#x2F;2018&#x2F;10&#x2F;09&#x2F;taking-an-indefinite-sabbatical...</a>

Unpopular question: if this is the case, why put it on github?<p>There are countless web frontends[^1] to expose a git tree on the internet, without the community&#x2F;social aspect of github.<p>[^1]: <a href="https:&#x2F;&#x2F;git.wiki.kernel.org&#x2F;index.php&#x2F;Interfaces,_frontends,_and_tools#Web_Interfaces" rel="nofollow">https:&#x2F;&#x2F;git.wiki.kernel.org&#x2F;index.php&#x2F;Interfaces,_frontends,...</a>

While I respect this, it annoys me to no end when I can use a piece of software, see the code of a piece of software, fix a piece of software, but not contribute that fix back up. So I’m doomed to an eternity of either merging all upstream changes, or waiting for the maintainer to fix it on his own.<p>I generally just pick something else, but it isn’t always immediately clear.

This is a great decision by the author, and the way he states it makes it socially acceptable in the current climate, where hordes of entitled and clueless people have the upper hand over the experienced and productive classes.<p>The latter part is the real reason why people burn out;it wasn&#x27;t that much of an issue when you could just tell people to stop bothering you with unimportant issues.<p>These days it is like walking around in a train station where random people can ask you to carry their suitcases. If you don&#x27;t politely oblige, they shout &quot;privilege&quot; and report you to the station&#x27;s political officer.

I think this is interesting. Burn-out is real - I remember when Ben stepped away from boltdb. I guess he&#x27;s learned his lessons and isn&#x27;t as interested in contributions being part of his vision for his SQLite sync tool.<p>I&#x27;d be interested to see if this gets normalised beyond the SQLite community.<p>One of the things I did recently and haven&#x27;t regretted is turning off email notifications on GitHub.

It&#x27;s my code, i don&#x27;t want you to modify my codebase but I&#x27;ll give it for free.<p>Fair enough for me.

Being able to turn off pull requests would help for cases like this.<p>Though the default GitHub setup also makes contributions unnecessarily difficult to manage. For example, a project can tell if it has been forked but otherwise has <i>no</i> idea what the forker is currently doing! Is the forker working on a possible future contribution (and worse, could that work be duplicating something that is already in progress elsewhere?). There are also plenty of forks that seem to <i>never</i> evolve, not even taking the minimal effort of pulling recent upstream changes.<p>The contribution mechanism could be broken up into different phases, something like:<p>0. Visitor forks project but this should be <i>invisible</i>, i.e. it is not “your repository” for all to see, since you haven’t actually <i>contributed</i> anything to it yet.<p>1. Visitor clicks button stating “intention to contribute” that notifies upstream project immediately. This includes information such as the nature of the proposed change.<p>2. The project maintainer then has the opportunity to communicate immediately, e.g. “sure!” or “please don’t do this, $SOMEONE_ELSE is already doing it” or “I don’t think that is a good idea” or whatever. Then the project can put this into a visible state on the GitHub page so that everyone knows about this in-progress work.<p>3. Eventually the work is done, and is <i>converted</i> to a Pull Request as opposed to just appearing out of the blue.<p>4. Once accepted, the repository is publicly listed on your profile since you have made an actual contribution to it.

Reading through this thread, I&#x27;ve been introduced to a lot of excellent takes on this issue that I hadn&#x27;t thought about before.<p>In thinking about how to balance the two sides, I wonder if maintaining a master branch and a &quot;community&quot; branch would be one way to do it; all pull requests for new features could be added to the community branch, and the branch would always contain all the features of the master, but with the caveat that community would be untested. This would allow me to focus on the project goals as I see fit, but rely on the community to bug test and update the additional features. It would offload the work of maintenance without the need to split the codebase for every single individual feature request.<p>Curious if something like this is used for any larger projects! I&#x27;m sure it wouldn&#x27;t always work but maybe on certain types of projects it could.

It&#x27;s interesting how this flips the relationship between the original author and subsequent forks. Let&#x27;s say that a fork is created, and adds some substantial new feature. It&#x27;s properly tested, and perhaps even proven in production. So Ben decides he wants it to be part of the base project, and starts pulling the pieces in. Now which is the OG and which is the fork? Which should people trust more? It will be interesting to see how that plays out, in this or some other project organized in a similar way.

I feel this so hard. Accepting nd reviewing contributions is far more work than it is worth in many cases and there&#x27;s only so much benevolent helping time a person has. Especially if running multiple projects, sometimes you gotta cut the cord.

Tech companies have been extracting cash via crowd sourcing and open-source is no longer an exception.<p>A lot corporate software is sitting on top of open source and they are monetizing it and talk it down at the same time. And in some cases they have been able to take open source or ex free licensed software private too if they can muscle the take over by injecting cash incentives into hands of those who have inhered the means to change the rules via new versions.<p>How did Oracle get to take over java? I think that Microsoft is in the game too by purchasing Github.<p>They are billions of dollars in free code that they can take over.<p>So IBM owns Redhat and Redhat is taking over whatever it can muscleiin their space.

I&#x27;ve seen some repos put &quot;mirror&quot; in their descriptions. Like others, I wish GitHub has a way of blocking PRs.<p>But I think, what I can do eventually is have my version of your &quot;Open-source, not open-contribution&quot; paragraph. Hopefully the term will become popular and more widely recognized.<p>Furthermore, I think it is helpful to have a public roadmap of features not implemented yet. Others (especially colleagues) might feel ownership because they were able to guess what&#x27;s on your long mental to-do list and make that their &quot;ground breaking&quot; request.

&gt; Small contributions typically required hours of my time to properly test and validate them.<p>Exactly, a small patch can be very time consuming to review. Fully understand the author.

It&#x27;s not ideal, but the support for pull request templates is there, such that you can pre-fill the pull request with some text like &quot;THIS WONT DO ANYTHING, PULL REQUESTS ARE AUTO DELETED&quot;<p><a href="https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;github&#x2F;building-a-strong-community&#x2F;creating-a-pull-request-template-for-your-repository" rel="nofollow">https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;github&#x2F;building-a-strong-communit...</a>

The amount of rookie webdevs who think contributing to an open-source project is a normal part of learning now is so baffling.<p>How are you supposed to make significant contributions to any project worth a darn without any significant experience?<p>It sounds mean, but the trend should probably be discouraged. It&#x27;s unnecessary, anyhow. Open-source projects are not practice projects. You make those up yourself.

There is a middle way: continuous integration quality gates.<p>For projects with a small core team and lots of contributors, you can write tests which analyze the submission for quality. Linting tests, code quality tests, smoke tests, unit tests, functional tests, ChangeLog tests, etc. Each one will halt the PR and inform the user what failed and how to fix it. The user can then gradually improve the quality of their PR until it passes all tests, and <i>then</i> someone will review it.<p>I&#x27;ve used this method on projects before, and both as a contributor and a maintainer, I love it. As a contributor, it is a seamless feedback cycle that tells me how to improve my contribution before I bother anybody. As a maintainer, most contributors just don&#x27;t put in the effort, so I don&#x27;t get bothered.<p>You can also put other quality gates in place, like asking someone to sign your contribution agreement, confirming they have read documentation (&quot;what&#x27;s the secret phrase?&quot;) or that their change includes documentation. It takes some work to set up at first, but it really improves productivity and quality.

For a project where a sole primary maintainer is the only option, this makes perfect sense.<p>For long-term viability of a popular project, I think you&#x27;ll eventually need more maintainers, which brings back most of the problems of having multiple contributors.

Also if you do not accept contributions you can easily perform a license change later.

GitHub&#x27;s &quot;archive&quot; and this guy&#x27;s &quot;closed for contributions&quot; is easily solved by forking: congratulations, you&#x27;re the new maintainer. That&#x27;s all there is to it.

These types of things are funny to me, because I exclusively[1] contribute to other people&#x27;s projects and don&#x27;t really have any of my own.<p>[1]: The maybe-exception being projects I then get commit-bit too.

Wasn&#x27;t this the stand that caused people to be very angry with GCC, fork the project into EGCS, and eventually jump on LLVM as the the new favorite open compiler?

I&#x27;m curious why Elm gets such flak for doing the same?

Between this stance and the &quot;where&#x27;s the patch?&quot; crowd there&#x27;s a hostile sentiment brewing against open-source users on HN.

Duel licensing the contribution is always an option. you can add contribution agreement with statement like<p>&quot;all the contributed code will be under duel licensed, original commit will should grant all rights and ownership of it to the XYZ INC&#x2F;LLP. the copy of it will automatically be commuted to GPL licensed source repository under original contributor&#x27;s name. &quot;

One way in the middle is to significantly raise the threshold for accepting a patch but that makes it harder.

The README states:<p>&gt; <i>I&#x27;ve made the decision to keep this project closed to contributions for ... long term viability of the project.</i><p>Here&#x27;s hoping he will open it up if he stops maintaining it (or slightly earlier)

&gt; <i>simple one line changes can have profound and unexpected changes in correctness and performance. Small contributions typically required hours of my time to properly test and validate them.</i><p>Isn’t this a simple case of not having a good enough test suite?

I can&#x27;t help but think this is self-inflicted. If we really are to apply the spirit of open-source, wouldn&#x27;t the community-pro action here be to open the project up to additional maintainers to pick up the slack and delegate out the work? Isn&#x27;t that how popular projects grow? And when they do get really big, isn&#x27;t that the time they should be transitioned to an organization like Apache or Canonical to manage the day-to-day management efforts of a large project?<p>I think the idea that a founder of a project is responsible to maintain it into infinity and beyond is missing the whole point of open-sourcing code. That founder is putting unfounded pressure on themselves rather than letting the project grow and evolve in an organic way. Much like a helicopter-parent that micro-manages their children&#x27;s lives, rather than letting them make mistakes, learn, and mature into independent adults.<p>Obviously, there are a number of open-source project methods for handling this, forking being a common one that the community itself can apply. But I would think it would be beneficial to the project community to have an honest discussion about it an entertain offers to take the project over rather than breaking the community spirit of contribution that is core to the ideals of open-source programming. If there comes a time when no one is willing to step up, the community and more importantly repository providers, should offer a way to put a project into maintenance mode, and allow someone to come along and take over maintenance of code that has the time and willingness to do so.<p>This comment is not an effort to criticize the founders of the mentioned projects, but an open-ended question to the community at-large to ponder and reflect upon how we manage and grow the spirit of open-source, while taking care of the maintainers&#x2F;contributors that help keep it going.

&gt; <i>Writing databases &amp; low-level replication tools involves nuance and simple one line changes can have profound and unexpected changes in correctness and performance. Small contributions typically required hours of my time to properly test and validate them ... I&#x27;ve made the decision to keep this project closed to contributions for my own mental health and long term viability of the project.</i><p>While I understand the burden of accepting and evaluating code from others and the very real possibility of a burn-out due to it, can&#x27;t test-driven development (or even Behavior-driven development) reduce a lot of this burden?<p>(Related: How SQLite is tested - <a href="https:&#x2F;&#x2F;www.sqlite.org&#x2F;testing.html" rel="nofollow">https:&#x2F;&#x2F;www.sqlite.org&#x2F;testing.html</a> ).