Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

investigate alternative infrastructure for network platforms #7

Open
cameralibre opened this issue May 18, 2018 · 13 comments
Open

investigate alternative infrastructure for network platforms #7

cameralibre opened this issue May 18, 2018 · 13 comments
Assignees
Labels
🕹 aspect: interface Concerns end-users' experience with the software 🛠 goal: fix Bug fix 🟩 priority: low Low priority and doesn't need to be rushed 🏁 status: ready for work Ready for work 💬 talk: discussion Open for discussions and feedback

Comments

@cameralibre
Copy link
Contributor

cameralibre commented May 18, 2018

A discussion was recently started on the Creative Commons Slack channel by @gwolf, suggesting moving away from Slack for the organization. Based on feedback from @Claudioruiz @rheaplex @xolotl and Pen-Yuan Hsing, it seems like there is some support for looking into alternatives.

The development of a new Creative Commons Culture platform seems to me an ideal opportunity to prototype a different infrastructure which is more aligned with the mission of Creative Commons, while maintaining the ease-of-use of Slack.

If it works well, we can think about applying it to the Creative Commons network more generally.

As I mentioned in the outline document for the Culture platform, building a commons community on proprietary infrastructure would be a real block for me, and would severely impact my motivation to set up and contribute to the platform.

For the Culture platform I'd like to look into setting up something like a Discourse forum (easier finding and linking to existing content than a mailing list, plus the ability to organize the platform in the open) combined with a regular curated newsletter (higher quality content than mailing list, invites contributions with links back to forum).

But first, I'd like to discuss an alternative to Slack.

Matrix.org is the option that I would go for, due to:

But perhaps others have a different viewpoint. Is there any reason to prefer Mattermost, Rocket.chat, etc over Matrix?

  • What would be necessary to set up a Matrix instance for a Culture platform? (server, cost, maintenance time)
  • Does anybody within the network already have experience setting up/running a Matrix instance for a community? Is there anything we should know?
  • What are the advantages & disadvantages to setting up a Matrix instance for a Culture platform?
@Veethika
Copy link

Veethika commented May 24, 2018

@cameralibre
Choosing MatterMost over Rocket.chat and Slack | AkitaOnRails.com
This might help in making a decision. Bumped into this in a similar discussion happening on our organisation forum. We've so far been using Mattermost and it's working quite well for us.

@penyuan
Copy link

penyuan commented Jun 8, 2018

Sorry I'm a bit late to the discussion.
Is there someone who knows the current technical requirements of the Creative Commons Slack instance?
Also, can we list the functionality needed so we can use the list to evaluate libre replacements?
In general, I agree with @cameralibre that Matrix is probably the way to go. Thank you for starting this important discussion!

@gwolf
Copy link

gwolf commented Jun 8, 2018 via email

@rheaplex
Copy link

rheaplex commented Jun 8, 2018

Depending on how you mean technical requirements:

  • Slack is a hosted service so that saves us from managing another server.

  • Slack is a stable, well-understood, easy to adopt, extensible public chat system with good social network effects.

Any alternative that requires me maintaining it or requires that users climb a learning curve that is not amply supported is starting at a relative disadvantage, be it a Free Software or proprietary system.

@gwolf
Copy link

gwolf commented Jun 8, 2018 via email

@tarkowski
Copy link

tarkowski commented Jun 9, 2018

I just learned about Riot.im [Riot was renamed to Element in 2020], and according to the site,

Break through - Riot allows teams to communicate across a wide range of collaboration apps. If some team members use Riot while others use IRC, Slack or Gitter, Riot will allow these team members to seamlessly work together. Riot offers the richest network of communication bridges.

Sounds pretty good! As it would allow us to address both the need of many CC people to remain on Slack, and the need of some of us to move to a more decentralized infrastructure.

@penyuan
Copy link

penyuan commented Jun 11, 2018

@rheaplex:

Slack is a hosted service so that saves us from managing another server.

Please excuse my ignorance, but surely the Creative Commons organisation has the technical means to host an instance of a decentralised tool be it Matrix or Mastadon? This would be a great chance for CC to support and promote the growth of libre and decentralised replacements for proprietary solutions such as Slack.

Slack... [has] good social network effects

I see what you're saying, but I think this is really in the eye of the beholder. The network effects of Slack (or Facebook and friends for that matter) are used by these companies to lock users into a proprietary silo. IMHO this is not a Good Thing! And it is exactly because of the network effect that decentralised solutions like Matrix would benefit from a big player like CC.

@cameralibre @tarkowski:

...If some team members use Riot while others use IRC, Slack or Gitter, Riot will allow these team members to seamlessly work together

I heard about this being in development last year, glad it's a reality now!!

I think it's a good idea if CC-related groups could be hosted via Riot.im (which is built on Matrix) and new users are asked to sign up on Riot.im. Slack would be the "legacy" platform but new onboarding would be pointed to Riot.im.

Should be set up some sort of test instance to take this forward?

@claudiorrrr
Copy link
Contributor

claudiorrrr commented Jun 11, 2018

thanks for having this conversation. My two cents here:

  • Personal note: I'm an active IRC user (cla- and/or cla on #freenode/oftc/efnet) and I've been testing Riot in the past.
  • CC using Slack it has been by all the means successful (never in the history of CC we had so many people engaged than today, and we used to use IRC in the past...).
  • It worth having a wider conversation about whether CC network should use Slack or another tool to communicate. As I've said in Slack (ha), I would love if the network decides to have that conversation when the Global Network Council exist.
  • IMO we derail the conversation when we just focus in the ethical argument. It's not the only one. As Rob said, as an example, running our own resources will use tech support time we today don't have. To take any decision -not here, but by the Global Network Council- we need to have a wider conversation not just under the etchical argument.
  • Network Platforms (and Working Groups) can use whatever communication tools they decide, as far is clear how to join, it's public and open to anyone.

@cameralibre
Copy link
Contributor Author

cameralibre commented Jun 27, 2018

Sorry for the delay in replying, I have been bogged down on a freelance job the last few weeks.
Coincidentally, this week I came across @lightweight's article which specifically calls out Creative Commons on this issue: Arresting the slide from Open to Fauxpen | Dave Lane.

But I agree, @Claudioruiz, it is not just about the ethical issues.

For me, there are two main practical concerns, both have to do with Creative Commons' long term-goal: building a vibrant, collaborative global commons.

One thread is simply resilience of infrastructure: if Slack changes rules or pricing, is bought, or shut down, CC has absolutely no say in the matter. This seems to me like a rather precarious situation for a networked organisation's core communication infrastructure and a major repository of institutional knowledge.

On the other hand, if CC's chat were based on Matrix, and Matrix were to change something fundamental, negatively affecting the way that CC would like to use the software - well, that's also not problem-free - but at least there are options:

CC would have access to its own data and chat history, at the very least. It can keep running an earlier version of the software which does suit its needs, for as long as it is secure and practical to do so. As an organisation, it can choose to support or contribute to the development of a plugin or fork which enables the functionality it needs (though I appreciate that this is easier said than done!)

The other issue for me is CC's role within the larger interconnected Commons / Civic Society movement.
Although CC isn't exactly a giant, it is well-known and respected organisation. It has staff, reasonable funding and an active international community, unlike many other smaller civic society orgs. Other organisations look to and learn from Creative Commons.

If CC were to invest time and resources into running a Matrix instance, submit bug reports/patches to the project, and document their experience so that other organisations could learn from them and make informed decisions, then that is a way for Creative Commons to help up & coming organisations, and help shape resilient infrastructure that enables networked, commons-based collaboration.

I admit that this point certainly veers into 'ethical' territory, but I want to emphasise that these ethical concerns have practical implications - for example, there are organisations working on more controversial topics in more dangerous situations than we are, who need good working examples of secure/decentralised communication platforms.

A big 'but':

In saying that, without somebody willing to pick up this issue and put in the time and effort to implement a Slack alternative, drive adoption, take responsibility for maintenance, etc, it is unlikely to be a successful shift.

I have been thinking about it and I can't commit to that role myself - being in an awkward timezone, I don't feel able to lead community-building efforts on a real-time platform anyway - it's more practical for me to focus on asynchronous collaboration. @rheaplex I'll be in touch with you separately about this.

Without other volunteers for the moment, maybe as you suggest, Claudio, this issue can be picked up again when the Global Network Council is set up?

@lightweight
Copy link

lightweight commented Jun 27, 2018

Totally agree, Sam (@cameralibre), that this is a very ethically important discussion to have. Practical considerations must be secondary to principles for an organisation like CC which was created to alter culture by espousing the core values like sharing, collaboration, equity, diversity, openness, and transparency.

Amusingly, the organisation who hosted the NZ-based CCANZ (now renamed Tohatoha and independent) that employs me offered CC a hosted Rocket.Chat instance, in perpetuity, gratis over a year ago.

Sadly, CC's leadership rejected the offer, for what appear to have been political reasons, and refused to even trial it. It's one of the reasons I no longer have any affiliations with CC, which directly contradicted its core principles by actively selecting Slack over an open source alternative. So I see this is an issue more of lacking leadership than technical complexity or administrative burden. What's more, any organisation with a technical focus (and any sysadmin capabilities) who can't manage a chat service like Riot+Synapse or Rocket.Chat or Mattermost is not probably not being well served. (To be clear regarding technical choices, I also encourage the use of the Matrix open standard in principle, although Rocket.Chat is also moving towards that and when I was picking a platform, R.C was the clear choice. Things change rapidly in the FOSS world.)

I manage half a dozen Rocket.Chat instances as a minor part of my development-focused role with the OER Foundation, with a total cost of about an hour of my time in total per month.

See Docker Compose: A better way to deploy Rocketchat, Wekan, and MongoDB | OERu Technology Blog for my instructions on how to replicate our stack, which is pretty trivial for a capable sysadmin to implement.

@lightweight
Copy link

lightweight commented Jun 27, 2018

And, to be clear, unlike Facebook, Twitter, LinkedIn, Meetup and others, Slack does not enjoy the Network Effect. See: Why Slack is better, and why open communities shouldn't use it | Dave Lane

@claudiorrrr
Copy link
Contributor

claudiorrrr commented Jun 27, 2018

In saying that, without somebody willing to pick up this issue and put in the time and effort to implement a Slack alternative, drive adoption, take responsibility for maintenance, etc, it is unlikely to be a successful shift.

I have been thinking about it and I can't commit to that role myself - being in an awkward timezone, I don't feel able to lead community-building efforts on a real-time platform anyway - it's more practical for me to focus on asynchronous collaboration. @rheaplex I'll be in touch with you separately about this.

Without other volunteers for the moment, maybe as you suggest, Claudio, this issue can be picked up again when the Global Network Council is set up?

Thanks for the energy and reflexion on this matter, @cameralibre. That's precisely what I meant when I said I welcome the wider conversation about this matter, that includes not just ethical elements but also practicals. For an organization this size (quite small), both elements should be considered, not just one of them.

My suggestion is this topic to be picked by the governance body of the Global Network. We hope this will exist later this year. Thanks everybody.

@cc-open-source-bot cc-open-source-bot added the 🏷 status: label work required Needs proper labelling before it can be worked on label Dec 2, 2020
@TimidRobot TimidRobot moved this to Triage in possumbilities Sep 10, 2024
@possumbilities possumbilities added 🚧 status: blocked Blocked & therefore, not ready for work 🧹 status: ticket work required Needs more details before it can be worked on 🟩 priority: low Low priority and doesn't need to be rushed and removed 🏷 status: label work required Needs proper labelling before it can be worked on labels Oct 1, 2024
@possumbilities possumbilities moved this from Triage to Backlog in possumbilities Oct 1, 2024
@TimidRobot
Copy link
Member

penyuan dijo [Fri, Jun 08, 2018 at 08:09:08AM -0700]:

Sorry I'm a bit late to the discussion. Is there someone who knows the current technical requirements of the Creative Commons Slack instance? Also, can we list the functionality needed so we can use the list to evaluate libre replacements? In general, I agree with @cameralibre that Matrix is probably the way to go. Thank you for starting this important discussion!

I am very happy this is a point kept alive. I agree that it is counter-sensical that Creative Commons uses Slack as its main communications platform - I have written publicly about this:

  1. http://gwolf.org/node/4119
  2. https://xrds.acm.org/blog/2018/05/walled-gardens-use-project-communication/

I have got recommendations about Matrix and Mattermost.

Wayback Machine links:

  1. On the demise of Slack's IRC / XMPP gateways | Gunnar Wolf
  2. The walled gardens we use for our project communication - XRDSXRDS

@TimidRobot TimidRobot moved this to Backlog in Shafiya-Heena Oct 1, 2024
@TimidRobot TimidRobot self-assigned this Oct 1, 2024
@TimidRobot TimidRobot moved this from Backlog to In progress in Shafiya-Heena Oct 1, 2024
@TimidRobot TimidRobot added 🏁 status: ready for work Ready for work 🛠 goal: fix Bug fix 🕹 aspect: interface Concerns end-users' experience with the software 💬 talk: discussion Open for discussions and feedback and removed 🚧 status: blocked Blocked & therefore, not ready for work 🧹 status: ticket work required Needs more details before it can be worked on labels Oct 1, 2024
@TimidRobot TimidRobot moved this to In progress in TimidRobot Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🕹 aspect: interface Concerns end-users' experience with the software 🛠 goal: fix Bug fix 🟩 priority: low Low priority and doesn't need to be rushed 🏁 status: ready for work Ready for work 💬 talk: discussion Open for discussions and feedback
Projects
Status: In progress
Status: In progress
Development

No branches or pull requests