Why Slack is inappropriate for open source communications

Post by rsync » Wed, Apr 12, 2017, 3:35 AM UTC

ktta wrote: post #236

swiley wrote: post #233

Earlier quoted context omitted.

"in the spirit of IRC" is a bit of a stretch. This is all a massive blob of web technologies which contrasts IRC's minimalism and it's lightweight clients written in C. It doesn't appear to require any specific service though so at least it has that.

Well we are moving to a web first world, and passing the terminal days of IRC. Trying to avoid web technologies isn't going to do anyone good. Best we can do is try to make them better are secure. Light weight clients can be written in C if you want. There's nothing that needs a web browser Here's the spec if you're interested[1]. There's also a weechat script if you want a command line client[2] [1]: https://matrix.…

Post by rsync » Wed, Apr 12, 2017, 3:43 AM UTC

piquadrat wrote: post #20

Is that really happening that open source communities use Slack as their primary communications channel? I haven't seen that happening in the communities I participate in (Python/Django/...). What I do see is that more and more communities switch from IRC to Slack as the primary "sync" channel (while still maintaining mailing lists, bug trackers and the like). And as much as I hate it, the success can't be denied. Es…

Post by 013a » Wed, Apr 12, 2017, 3:52 AM UTC

zachlatta wrote: post #90

caseysoftware wrote: post #5

Good points but the bigger problem for me is the lack of an archive. You only have the last 10k (?) messages and that includes public and private messages. If you have a mildly active project, messages may only be available for a month and you lose the history of the project. That makes it an awful support option too.

If you have a nonprofit for your project, you can also get on their nonprofit plan. At https://hackclub.com we get unlimited archival without paying for this reason.

Post by 31h » Wed, Apr 12, 2017, 3:57 AM UTC

rsync wrote: post #431

31h wrote: post #418

Earlier quoted context omitted.

> With the old upload-and-forget model of software distribution, you could put a tarball on a free FTP site for a few pennies You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget). Then it's up to the user to pay $5/mo to host it, a process which doesn't need to take more than a few mouse clicks.

"You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget)." Wouldn't it be easier - and free - to "upload and forget" onto github ? If someone had a software release, why wouldn't they choose github to be the release point - even if it's just a single tarball ? Are there costs involved in hosting binaries/tarfiles on github ?

Post by rsync » Wed, Apr 12, 2017, 4:03 AM UTC

31h wrote: post #438

rsync wrote: post #431

Earlier quoted context omitted.

"You can still create a Digital Ocean droplet, Docker container, or VM Image - and do the same thing (upload & forget)." Wouldn't it be easier - and free - to "upload and forget" onto github ? If someone had a software release, why wouldn't they choose github to be the release point - even if it's just a single tarball ? Are there costs involved in hosting binaries/tarfiles on github ?

Can you clarify what you are driving at with these questions? First off, a lot of people prefer hosted source repositories other than github (e.g. hub.darcs.net, gitlab.com, My Own Private Server). Github naturally imposes various limitations on their "free" plans.