← Back to context

Comment by RossBencina

5 hours ago

Interesting. The post is about whether a license prohibiting SaaS competitors is "open source" and whether it might work out as a good way to ensure project sustainability. In this context "source available" means that you have the source code but you can't use it to compete with the project owner. [Kinda puts Omarchy in a different light don't you think?]

There is another, I think different, form of "source available" that I've seen a bit lately, similarly from corporate/commercial sponsors: the source code is released under an OSI approved license (e.g. BSD, GPL licence) and the owner maintains and develops the code in an ongoing fashion, but there is no way to easily interface with the developers, contribute changes back to the project, nor is there any public facing bug tracker or developer/user community. To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.

> There is another, I think different, form of "source available" that I've seen a bit lately, similarly from corporate/commercial sponsors: the source code is released under an OSI approved license (e.g. BSD, GPL licence) and the owner maintains and develops the code in an ongoing fashion, but there is no way to easily interface with the developers, contribute changes back to the project, nor is there any public facing bug tracker or developer/user community. To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.

No, that's very much open source - in fact, it was the way most big name open source projects were developed back in the early days. See the famous "the cathedral and the bazaar" essay. Public bug trackers and widely soliciting contributions to mainline are relatively new phenomena, but you always had the right to fork and maintain and share your own fork, and that's the part that's essential.

  • I agree that it started that way, but that does not mean norms and expectations don't shift. To me, acting like it's 1980 is weird. The majority of maintained open source projects today are single-source-of-truth projects, not source code drops from unreachable invisible teams. There is a reason for that -- it's part of what makes the projects usable and dependable.

How easy do you have to make it to contribute to be considered “open source”. Obviously, no project accepts every single pull request. Where is the line between “open source” and “no open source” in your definition?

  • Intent. Do you intent to be a genuinely open community and is it set up around fostering that dynamic as a central aspect of development? It's hard to measure intent, but we can do so indirectly by looking at the project structure:

    - Are there contributor guidelines?

    - Do contributors have to sign a waiver before they can contribute any code?

    - Is there a RFC process?

    - Does the project actually respond meaningfully to that feedback, or does it simply get filed in the special complaints folder for corporate.

    - Does the project encourage outside contributions in more than a cursory way?

    - Does the CLA grant the company unilateral relicensing rights?

    - Are governance documents public?

    - Can the community vote on decisions?

    - Does the community have a say in how it's moderated?

    - Are community members invited to actually join the organization?

    - Are architectural decisions made in open meetings?

    - Is there a public ROADMAP and is the community invited to contribute to it or influence it?

    - Can others build competing distributions without fear of retaliation?

    - Can the project be forked if there is community disagreement about direction?

    Those are just some signals off the top of my head. There's no bright line; the presence or absence of a few won't say anything one way or another. But if many of the answers to those questions are leaning toward the negative, then I don't think it can be open source.

    • Some of my favorite open source software is random stuff that the author just completely abandoned but had the forethought to make open source so that others could still use it, fix bugs, add features, and even fork it.

      RMS just wanted to be able to fix his printer driver.

    • Completely disagree. To me, and the OSI, none of those things other than redistribution and forking have anything to do with being open source or not. In fact, you could have a closed source project tick nearly all of those boxes, although that would indeed be very unusual.

      I'm not sure if there is a term for what you are describing. Perhaps "community driven project".

> To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.

I feel like this is a completely different conversation, but this is just as much a misunderstanding of what open source is as DHH's.

As long as the code is under BSD or GPL, you are free to take it as-is and do what you want with it. You could run your commercial service using it. You can certainly write patches and apply them to your own servers. You could even email the maintainers with them -- worst case is that they will ignore the emails!

Open Source does not guarantee that your contributions will be accepted or merged back to the project -- indeed, if you think about it, that would be absurd. I might want some random thing in the Linux kernel, but the maintainers will always have the final word on whether they want my patches or not.

The O'SaaSy license says that (essentially) 37Signals will sue you if you try to host this on your own servers, and try to sell it as a service. That's totally different, and a legal rather than a technical hurdle.

> To me this is just as much "not open source" as a specific no-compete with the primary project sponsor.

It’s massively different from source-available in that anyone can fork it for free and start developing it themselves however they want. Just because one fork of the project (the original one) follows a closed development model doesn’t change anything about the code, what you can do with it, and how others can develop it.