Open source does not mean accepting everyone's work or even accepting contributions at all. From the article, it seemed like this was the major concern.

I found the part that said "yes open source provides transparency but we have a roadmap" a bit weird.

It's their product, so if they don't want to open source it then they shouldn't. No need to write a silly article with almost as many emojis as words.

Many of us are old enough to remember the kinds of projects that were freely and openly licensed and yet all you ever got was www.foo.org, foo-user and foo-devel mailman lists, a foo-1.2.3.tar.gz of source code, and a foo package or port in your free OS of choice.

Within each of these projects was an elite cabal of committers — those with access to the source tree, it’s history, and the ability to commit to it. Mere mortals couldn’t just become committers! You had to be proposed and seconded off the back of a prior history of helpful patches you’ve emailed to the lists over the past months.

Nowadays anyone can commit to any project because a git commit is always in a fork of the repo. Every single git working copy is a fork, even if most of them are just a means to be able to push commits back to your own master on someone else’s machine, usually GitHub’s.

I wonder why the author of this post can’t enforce the old social model with the new tools? Is it a sense of social pressure to accept patches they don’t want? (Edit: in fact they do say this out loud — it really is about the emotional burden of having to reject contributors and interact with strangers — fair enough, I feel that too sometimes!)

One other extremely understandable problem with having a public repo to which it is easy to submit patches: the project owner’s level of plausible deniability for having seen copyrighted code drops to dangerously low levels. If the Yaak author was also worried that someone was going to put up a commit implementing something that was already on the project’s private roadmap, and that the external contributor would then claim some kind of IP ownership of the feature once it shipped, then I would be sympathetic to that stance as well.

From that post:

    The benefits of open source must make up for the fact that:

    - It’s hard to deal with unappreciative or rude feedback
    - It’s hard to manage long back-and-forth feedback cycles
    - It’s hard to decline a contribution that was submitted without approval
    - It’s hard to say no to most things once the project has matured
    - It’s hard when a good contributor leaves
    - It’s hard to accept that people are working for no pay
    - It’s hard to feel good about 1000+ open issues
    - It’s hard that it never stops.

The list is made up exclusively of "it's hard to..." points, every single one of which reflects the personality of the person who wrote it, not the project's distribution model.

Hard to deal with unappreciative feedback? Ignore it, plain and simple.

Hard to reject contributions? Then you're doing it wrong, plain and simple. No project can be all things to all people, and rejecting contributions which do not fit the maintainers' vision of the project is just part of the process. In contrast to the OP's ideals, that's _especially_ true once a project matures. (SQLite may be the most well-known example of that.)

Hard to accept that people work for no pay? Believe it or not, the overwhelming majority of FOSS contributions are not commercially backed. i've written far, far more code "for free" (because i WANTED to) than for pay (working on behalf of someone else's agenda). If you're not enjoying contributing then don't contribute. Likewise, if someone contributes to your project without you having offered to pay them, it's a fair bet that they got at least some small level of joy out of having written the contribution in the first place. (If they then bemoan the fact that it's not merged into the trunk, i can recommend that they read up on "egoless programming.")

Hard to feel good about 1000+ open issues? Then close the ones which are out of scope and address the ones which aren't (even if "address" means flagging them as "won't fix"). Feel good that other people are taking the time to contribute tickets in the first place.

All of that said: i'm not the slightest bit anti-closed-source, i'm just annoyed that the author doesn't acknowledge that all of the supposed shortcomings are personal quirks, not limitations of the FOSS model.

> The benefits of open source must make up for the fact that:

    It’s hard to deal with unappreciative or rude feedback
    It’s hard to manage long back-and-forth feedback cycles
    It’s hard to decline a contribution that was submitted without approval
    It’s hard to say no to most things once the project has matured
    It’s hard when a good contributor leaves
    It’s hard to accept that people are working for no pay
    It’s hard to feel good about 1000+ open issues
    It’s hard that it never stops.

> The list could go on, but you get the point; open source is hard and it takes a toll on your emotional well-being. The only way open source can work is in a corporate setting where full-time maintainers are paid to manage the project, can take breaks, and be replaced if desired.

I think a better answer lies in Rich Hickey's piece [0]. Making a project open source is not about making it a community project. You don't need to have contributors, or accept ideas. You don't even need to take feedback. I think Github's model of open source encourage the same kind of issue that social media have. By default, it encourages everyone to provide their opinion and ideas to something that is essentially yours. It does not work in the real world, and it does not work here.

You only need to add an issue trackers, if you care about tracking issues. You only need to accept contributions if you want to accept others' work. I still think email's collaboration and exchanging patches make more sense in community projects. PR and issue work best when there's a fixed set of collaborators and not external inputs.

[0]: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

This is what happens when programmers engage in too much Yaak shaving.

You can still release your source code without accepting public contributions. Sounds like Yaak is up to some shady shit.

I guess they depend 99% on open source projects…