3 ms·
You don't need to run your own infrastructure---you just need to use services that are compatible with free software. This highlights the difference between "o
by mikegerwitz 11y ago
You don't need to run your own infrastructure---you just need to use services that are compatible with free software.
This highlights the difference between "open source" and free software: by using and recommending Slack, you make a statement that the freedoms of those who would collaborate with your project are not important. In general, projects that identify with the free software philosophy or the "open source" development methodology can collaborate with either community just fine---there are shared interests and goals. But if you use a freedom-denying service, then you cripple a community of contributors.
It does not matter if RMS personally says that he is okay with a particular project---the four freedoms are clear and basic; we don't need his personal endorsement. Further, just because you use Slack, that doesn't mean that your project is less free than another---if it's free software, then it's free software. But the community surrounding your project is shaped by your actions. And if the pressure is great enough, there may be no choice but for free software users to fork the project, and perhaps hope for better collaboration in the future.
- tobz 11y agoSo there's the issue of software being "open", as in being able to see the source code. Then there's the part about who is running the software. Do you personally feel more safe, or better, whatever the adjective you want to use would be... about logging in to a remote server that uses software you can read the source for versus software you can't read the source for? It seems like a sticky problem because even if Freenode purports to be open, and you can read the source code of what software they say they use, you can't actually see the source code powering their service, right? Like you can't just SSH to the boxes, and look at the source and say "ok, they haven't messed with anything, so I'm ok signing into their servers". Like, you could see the very JavaScript running in your browser. You downloaded it, it's running locally. You can't see the backend, though. You can't tell how your data is being used. That's the thing that feels scarier to me, although admittedly, I use plenty of services based on closed source software as well as open source software, and it doesn't really give me too much pause. I guess I just don't really understand the fervor around the "openness" aspect if you're not actually the one running the service. You're still at the mercy of a service operator who could be eroding the "freedom" you think you have.
- mikegerwitz 11y ago> Do you personally feel more safe, or better, whatever the adjective you want to use would be... about logging in to a remote server that uses software you can read the source for versus software you can't read the source for? Ah, sorry, I see where the confusion is. This is a different issue entirely: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html Source code wise, the problem is non-free JavaScript served to the client: https://www.gnu.org/philosophy/javascript-trap.html It's desirable for the program running on the server to be Free so that I could run my own (if I chose to do so), and therefore be in control of my own computing. For example, I run my own GNU Social instance.
- e12e 11y ago> It seems like a sticky problem because even if Freenode purports to be open, and you can read the source code of what software they say they use, you can't actually see the source code powering their service, right? I'm not sure how hard it would be, but conceivably you could join freenode and host your own ircd? I think the federation part (and ability to migrate/self-host) is the most important part here. I don't think it makes much sense to bever let other projects/org run part of your infrastructure - the key point is that those organisations are open (so you can join Debian and take over an orphaned package you use, or you can run your own email and federate with others that use email). IRC vs Slack is a bit one-sided, as IRC has some real problems at the protocol level - jabber/xmpp and Matrix are probably more sensible alternatives. But even then I don't think the main point is that everyone should do all the work of hosting all their infrastructure - just that it's goid to choose an infrastructure with as little lock-in as possible - and infrastructure that one can easily contribute to (eg: submit a patch for ircd or one of the bots etc).