1. 26

  2. 13

    “What’s funny is that my friends in the know tell me this is how private warez torrent sites work: you invite someone, and now you’re responsible for their behavior. If they mess up, you deal with them, or you might be out, too.”

    I know of a really awesome and legitimate site that works that way, too. Maybe someone should tell her about it with an invite. ;)

    1. 4

      Except that lobsters isn’t operating under Las Vegas rules. Everything on here is publicly visible, and only the right to add to it is restricted at all. It’s not very hard to get an invite here, either, and the stated reason for being invite only is to keep the community from growing too fast for the moderators to keep up, not to make a programmer Fight Club.

      t’s closer to SQLite than the warez universe.

    2. 7

      This article seems a bit silly. There is no need to interact with anyone in open source if you so wish. You can put your code online and disable the issue tracker and merge requests.

      There could be an entire “shadow ecosystem” of invite-only source repos being shared among friends who are responsible for those they invite, including possibly having whole “trees” pruned if they turn out to be troublesome.

      There is next to zero demand for such a thing and it would quickly fall behind the public versions of repos.

      1. 6

        While it’s clear that the author doesn’t know this, most actual open source development occurs in the kinds of “shadow ecosystems” she describes – not because projects or forks get hidden in order to protect them from the toxic community norms of randos but because people simply don’t care. Github is full of substantially-patched personal forks of popular projects, not updated for years or decades (because the fork runs fine & the author doesn’t need any of the features introduced by trunk).

        Avoiding the responsibility of managing a community is totally valid. Communities are a lot of work & rarely worth it. As you mentioned, that’s not a great excuse for avoiding an open source release! Most open source projects have no community at all, and that’s great. There’s no point in putting the effort into keeping code proprietary (limiting the possibilities for archiving, among other things) when you can slap a 3-clause BSD license or a CC-0 or public domain declaration on it. If you’re really concerned about some user getting back to you and trying to intimidate you into accepting upstream patches, you could always release it anonymously (or under a single-use pseudonym).

        1. 2

          I was going to write more or less what you’ve said. You can have a network of people sharing modifications and pulling patches without any need for them to interact or for people to request that their work be pulled into someone else’s repository.

          However, thinking some more on the subject, the following occurs to me. Most people don’t consciously decide to create a community around their project. Imagine someone creates a new project or modifies an existing one to scratch a personal itch. They share it under a license of their choice, because, as you say, why not? Someone with a similar problem comes across the project, finds and fixes a bug or adds a new feature and shares their modifications with the original author in a similar way, “Here’s some code if you want it, but if not, I don’t mind because I have my copy which does what I want”. At this stage, this rather small “community” is basically no work and both beneficial and enjoyable to both parties. It’s nice to have someone take an interest in your work and it’s nice to get improvements to your code. It’s also easy to cherry-pick the patches you want. You don’t have to interact if you don’t want to, but there’s no point deliberately preventing it.

          Later, if the project becomes very popular, you get many more people involved, and they all have more motivation to get their changes included ‘upstream’, as having a common ‘core’ makes it easier to pull in other people work. With a community of this size, you might get more code contributions, but you also have a community to manage and a group of people expecting you to behave as a responsible steward rather than just an individual sharing a bit of code.

          So I think often you start with the relaxed, friendly code-sharing among individuals and occasionally it turns into a community. It’s not clear at what point along the way you need to adopt a code of conduct, abandon the project, fork it, or sever all ties and run away to live as a hermit in the wilderness.

          1. 1

            What I mean when I say ‘no community’ is ‘single developer’. Most open source projects have a single maintainer & few or no patches being submitted by users. Even large & important projects often fall into this category if they’re insufficiently sexy or if the amount of knowledge necessary to contribute is high (think OpenSSL prior to HeartBleed).

            When corporate management pushes for an open source release, they often have in mind getting some of their programming work done by volunteers & replacing engineer time with management time, so they often explicitly try to build a community & start with some kind of management structure. (This is also the case when they see an open source release as advertising.)

            I don’t know how often this really succeeds – my impulse is to expect that, like most non-corporate-sponsored open source projects, the repo or some source releases just get dumped on the internet & people keep their patches and forks to themselves if they ever even bother. This goes double for enterprise-type stuff. Where I work, we have substantial modifications of third party open source projects across the board, kept internally because policies about prior approval for release of code developed on company time require more effort than just keeping compatibility with whatever release was patched across the rest of the package set. (We’ve got a lot of 10-15 year old Google packages and even a couple nearly-30-year-old proprietary binaries we’re keeping alive with careful hex editing and periodic reimplementation of particular modules, sitting in the critical path for all production traffic.) I don’t think this pattern is remotely unusual, in companies that have been around for a little while.

            Basically, the weird confluence of open source licensing (where sharing information is good) & corporate capitalism (where sharing information is dangerous) has produced a kind of pathological situation where policies surrounding the release of internally-developed software discourage giving back to existing communities but encourage attempts to develop and grow new ones that management thinks can be controlled or branded.

            This is totally unnecessary: if something is a straightforward hack (i.e., useful but not marketable – like 99% of open source projects, neither sexy enough to be good advertising nor non-trivial enough to be profitable if sold), it makes more sense to release it under an open source license & not bother maintaining it or taking patches – to get the corporate PR equivalent of holding the door open for somebody, avoid the costs of trying to keep some trivial piece of code secret, & be able to reap improvements on the off chance that anybody makes any. If your competitor somehow doesn’t have a near-identical equivalent hack, they will only save a few engineer-hours adopting yours.

      2. 1

        It’s a huge relief to hear that I’m not the only one who does this.