Fork me on GitHub

@tcrawley: @johanatan Re: adding IRC/Slack bridging — I think we’re at the limit of integrations on a free plan?


Also @danielcompton and @mpenet — in case you want to consider discussing Slack vs alternatives.


Since we have some new people here, if anyone wants an invite to the test setup of mattermost that several of us are trying out, just let me know and I will gladly pm you one.


And a reminder (for the new folks), if you think Gitter is a good alternative, please go and actually try it out here and tell us what you think after you’ve used it for a while:


The slack PR team should hang out here and watch us struggle as we realize just how much we like slack and how hard it is to find an alternative.


@meow: It would probably be more useful if the gitter PR team saw us trying to use it.


Yeah I just went back there and reread our posts.


It’s not like our requirements are that outrageous


I’d think they’d be a baseline for a tool targeted at devs


Gitter is clever, I'll give them that. Maybe a couple of years ago that approach would have been enough. But not now, and not with slack as a known alternative.


@seancorfield: thanks for steering me here


you rock


just saying


It’s true, he does.


uhm, thanks!


(group hug)


@tcrawley: You’re using the IRC bridge to Slack, right?


I was, but it was painful. I was only using it because slack in FireFox on linux turns my laptop into a heater, but I discovered the official linux client this week, so am using that atm


it's no great shakes either - I really miss emacs keybindings


You should just build a slack client in elisp


no joke - when I did emacs years ago I did all my IRC'ing inside emacs - gotta love it


mattermost seems a lot snappier to me, but we're just in a test setup so who knows


yeah, erc - good times


@tcrawley: would you like to check out the mattermost that @gjnoonan set up for us to test out?


Perhaps we should also come up with a) a list of candidates, and b) a list of features that we are evaluating against


And then I’m seeing a spreadsheet of some sort


and then I'm seeing a lot of work that I, personally, have no interest in doing - but I won't stop you


Mostly it seems like being systematic about other options as we try them would be a good idea


however, say the word "committee" and I'm gone. 😉


unless there's going to be good bagels at all the meetings


I'll tell you one idea that I've been thinking. Go ahead and set up mattermost or whatever looks like the best alternative and just let people migrate over there if and when they want.


crazy, right?


I’m a fan of the sticking plaster approach


I don’t want to have to monitor two chats


it kind of sucks but it would give us a chance to eat our own dogfood for a while and iron out all the wrinkles


nobody took down the old IRC - people are still over there


let 1,000 flowers bloom


get in touch with your inner hippie


Yeah, it’s kind of a pain for me to have to monitor IRC and Slack


I’m going to take a machete to 999 of those flowers.


Or at least vote for that.


I worry about setting up something like mattermost, moving everyone over from slack, and then, bam! run into some problem and the darn thing is written in something other than clojure and everyone gripes


if slack doesn't kick us off, we look like idiots for having moved


if we wait until slack kicks us off, we won't be able to get together to look like idiots in a group setting


I don’t agree - I mean, we should try to make sure that mattermost works, but I think there are clear enough problems with Slack that we need an alternative. I’d ideally like to see the whole community just transplanted there.


If there are problems, it’s OSS, right?


I know that’s a bit glib, but I don’t want to drag around a bunch of half-communities


yeah, and just being completely blunt and honest here I've been burned by OSS just as much as by commercial software


Sure, or even more


not completely disagreeing with you, btw


there is definitely a benefit of moving en masse


I also think there’s a better chance that Slack would give us our complete archives if it’s part of a migration.


and I'm concerned about putting a burden on @gjnoonan and/or whoever sets up the hosting


Sure, but we can’t avoid that with any self-hosted solution.


I know. And I've had linode's in the past and lots of other hosting and I used to have a number of websites and I hate all that admin stuff


and the costs


nobody should have to foot the bill for this


Yep, I totally hear that. Unfortunately, the alternative is… Slack


and fundraising from the community is not going to be easy, I don't think. Not something I would want to do. And I've done online marketing.


I'm sure you know what it's like. You've got a commercial tool that everyone loves and yet it is going to be work to get people to actually pay for said product, even though they love it. That's just the way it is. Has nothing to do with you or me.


I’d happily foot the bill for a year’s hosting as Cursive, just because it would make my support better/easier


I mean, it’s literally a business cost for me.


Sure, and I appreciate that business attitude and that's super generous of you but I don't think you should have to foot the bill either.


Does clojure have any kind of nonprofit foundation?


No, but there’s been talk of it - @tcrawley probably knows more.


funny you should mention that...


I'm working on getting clojars in to the Software Freedom Conservancy, with the idea that we would use the org to promote other community things as well


and use extra money from clojars fundraising to fund community and OSS stuff


Just as a hypothetical, if someone like @cfleming saw the benefit of supporting the clojure community I think it would be good if he could make a donation to a nonprofit with the funds earmarked for hosting of a slack-alike.


I can do that.


basically taking on the fiscal role the proposed Clojure Community Organisation would have had


right - that's why we're trying to get under the non-profit umbrella of the SFC


makes getting/handling the money much easier, and safer


I just think it would be good to have that chinese wall and oversight


and, yeah, hosting of clojars needs to happen as well


we'd end up with a committee (no bagels!) that would oversee the funds


this is the kind of thing that plenty of OSS groups have done so should be plenty of examples of how to manage it all


nothing new, keep it simple


right, and the SFC has lots of experience with it, so could offer guidance as well


I'm off for the night. adios!


There's an important thing to bear in mind here which I don't see mentioned in any of these discussions: we had IRC, a free global network, mostly powered by FOSS, and a myriad clients from basic text to web to rich desktop apps to mobile apps etc. We reached "hundreds" of people (right now there are 703 people in the #C03S1KBA2 channel on freenode). On Slack -- albeit an "evil, corporate, proprietary stack" -- we have quickly reached 4,335 people on the #C03S1KBA2 and almost 200 related channels for various sub-topics.


The reason for that massive growth is polish: Slack is successful because it works well, and it does so on every platform. It's easy to join, it's easy to use. It's just not designed for thousands of people in a team: this success has taken them by surprise as well.


In order to take a 4,000-5,000 person community somewhere else -- successfully -- that alternative had really better be good!


@seancorfield: to be fair, there’s 4,500 registered. There’s only ~200 active in #C03S1KBA2 and #C03RZGPG1 right now


Whereas IRC has some people who want to setup their own bouncer and then a bunch of people (like me) who just login when we want to talk


Slack auto-aways people after about 10 minutes and that's what you see as "active".


totally agree with your general point though


As one of the admins, I get a weekly report of active and inactive accounts, and the number of messages etc.


ah yup, what’s the weekly actives?


Let me see if I still have last week's report in my deleted mail...


Full members 4,436, 166 new members joined last week, 179 members became inactive, 10,711 messages were sent. 383K total messages, 1.1GB storage used for 1,677 files, 10 integrations active. Past 24 hours, 795 read 2,223 messages from 152 people posting.


So nearly 800 people have actively read messages in the last 24 hours.


And new people are arriving at the rate of 100-200 a week in general.


That's about as much stats as I can pull on a free account @danielcompton -- is that helpful?


yeah, good to know


We are a large group for slack, especially since they charge per seat and likely have issues because of that design choice. But we aren't really a big group of users for a system in general.


What are the concrete problems with Slack now? Lack of archiving, and the potential that we’ll hit a limit at some point?


@danielcompton and @robert-stuttaford : say the word and I will gladly pm you an invite to the mattermost system that we are testing


i’ll give it a go


Yes, some people complain about the 10k message limit in the history imposed by the free plan (I don't find that a problem myself but I can accept some do). The bigger concern is that Slack generally baulk at communities that hit 5,000-or-so members.


The 10k message limit is really a pain for me.


It’s generally less than a day of history.


Yeah, looks like about a day


That’s a lot of collective knowledge lost.


I know we have some archives, but they’re not integrated, don’t cover DMs, and AFAIK don’t get automatically set up for sub-forums.


Plus they violate Slack’s TOS, and no-one knows when they might start taking them down (or taking this community down because we run an archiver).


@seancorfield: bummer, it would really be a great addition i think


sorry i'm late to the conversation but a) what is the actual problem with just paying for Slack ?


b) there is no b


3) i love heterogeneous lists


[feel free to ignore b) and 3) if not in the mood for any comedy]


@johanatan: hmm, off the top of my head- 1) Not exactly encouraging inclusivity or a free and open community feel? - Can't see those of us who don't do Clojure as a day job paying for the privilege to chat - Discourages Students and others without reasonable income - Do we really want any barriers to entry? 2) Who is going to administer invoicing and collect payment from all members? - Needs a bank account to be set up for the group


and that's just some of the objections I could have gone on..and on


RE 1) not everybody has to pay-- there just needs to be a pool of money to support the site (perhaps coming from a rich donor who has already won the startup lottery)


RE 2) See 1)


Cool - are you volunteering to be the donor?


and administer it?


Unfortunately I'm still in the rat race for now. If and when my number is called sure.


what happens when the donor does not donate anymore? Will our history pass away then too?


Also there is a third option: 3) pay what you can? 10 bucks here, 20 bucks there should really add up in the aggregate


Just feels to me this would just do several things: 1) Introduce divisions (who decides who pays and who doesn't) 2) Drop participation (see 1) 3) Make money for Slack


@sveri: history isn't a problem. it is easy enough to archive out of the purview of Slack or anyone else


the real value-add for Slack is the UX


history is a nice to have


As an illustration of 2) I would, by any 'means test' be someone who should pay but I work with Clojure as a hobby and I already pay enough for my hobbies so I'd be out.


1) nobody decides who pays or doesn't-- it is up to each individual to decide what they pay. 2) not if it is opt-in (and massive participation is of dubious benefit over just moderate participation anyway) 3) So what? I didn't know Clojurists were also anarchists


it's vendor lock in the problem, see what happened with maybe tomorrow they limit channels to 1k users, maybe they stop feature X, maybe they close down (could be because of an acquisition, etc).


it's all about control in the end


slack is nice yes, but we control nothing


even if we pay


Yea, but a) obviously this was the situation when the community decided to join Slack to begin with b) if we have the "out of purview" archivers in place (and I think we should) then it is a moot point


and c) if we have the IRC to slack bridge in place (like I'd like to see) then we get "out of purview" archivers for free (from the IRC side)


d) actually in that world, Slack becomes a luxury item which people can choose to use or not. all comms are still available from IRC for those who do not want to pay


e) so really an argument could be made that we need EXACTLY ONE Slack integration and that one integration should be the Slack-to-IRC bridge. A classic hack in fact.


f) so Slack is for people who want to use IRC but want a nice plush UX (and are willing to pay for it)


g) of course Slack will probably become wise to this at some point and we will have to "pivot" (or perhaps they will be the ones to pivot).


[if they have a problem with being just "a nice UX for IRC" (which they really shouldn't)]


Whenever I see an open source project that asks for money for community chat I get suspicious. Mainly, because it would be the first time in my life for this to happen. there is always some kind of a free forum or IRC or whatever.


You apparently missed points d-g above


Slack is the luxury tract. IRC (and Google Groups) is the free tract.


But the comms on both are identical. Only diff is UX


And there is and has been Clojure IRC. The missing element has been the Slack-IRC bridge to make the comms identical on both.


@johanatan: The price is also prohibitive - it’s $6/user/month. So currently the cost would be $324,000/year


@johanatan: Also note that archiving is a violation of the Slack ToS and could result in the community being shut down.


There is a Slack-IRC bridge. Apparently it’s a pain in the ass.


Morning all, just catching up with the messages


There’s also the fundamental disconnect that Slack provides a lot of functionality that IRC does not.


Hmmm lots to think about, I can't send a long reply currently, but I will expand of everything that's being discussed in due course this morning.


One thing I will say though, is it makes me uncomfortable to ask people to pay to joint the community, it goes against everything We're trying to build here, and discriminates against those who a) can afford it and b) are just starting out--not cool! Setting up fundraising and allowing people to donate if they can though, I'm all for that and open to discuss with @tcrawley further, and contribute to what he is trying to set up


In fact it’s worse, it’s $8/user/month if you pay monthly. But either way it’s moot, since it’s probably two orders of magnitude above what we could realistically raise.


@gjnoonan: I still like the idea of people being able to pay individually for archive access if they want to.


It still doesn’t help the fact that Slack basically doesn’t want to support us, though.


Also aggregating a list of what we actually want/need should be the first port of call, and assessing the viability of products, and what it may take to either a) add polish and features to mattermost or zulip or b) roll our own


^^ what he said.


Right, it’s bedtime for me.


@cfleming: I have contacted slack about that for you and will let you know when I get a reply


@gjnoonan: Awesome, thanks.


Night Colin


If every user pays for himself and the Slack-IRC bridge is in place, then what is the problem?


I do however agree that compiling a list of features that people like and finding a way to duplicate those is a nice way forward.


For me personally I like a) the web-app-iness and all that goes with that (inline media sharing, platform/device independence, general aesthetically pleasing design, etc) and b) archives/history


Regarding whether archiving is against Slack policy: this is bordering on thoughtcrime. I for one have a photographic memory and as far as I know Slack cannot force me to delete thoughts in my brain (as of yet at least). [And it's very easy to extend this argument to prosthetic brains aka magnetic or SSD storage devices)]


^ not from me, the join message make it look like I wrote this. Talk about nice UX 😄


^ I think you are seeing a different view than we are


Looks fine here


this wouldn't happen on irc ! 😄


Ha but then we'd have to deal with ugly bold fixed width fonts


And no media


anyway, ppl have different opinions and the end result is that prolly slack #clj will continue to exist until implosion and then they ll move to another solution just like it.


johanatan: your client sucks


Most clients suck


it's very subjective


And I don't want to bother looking through them all


And configuring them etc


If IRC clients didn't suck Slack wouldn't exist


and that's when I leave this chan because this is going nowhere clearly. bye


@johanatan: I did understand your argument about "slack being luxus". Still it would make me suspicious, because at the first look I would not understand that the content is the same (given it is, which I doubt, regarding the support for code snippets, links between chats, etc in slack, which you don't have in IRC)


@sveri: I can easily imagine an implementation of the bridge which uses pastebin, git gists, Dropbox, or any of a number of other commodity cloud storage services for putting the large content and pasting a link into the IRC channel for each item


If the bridge src needs to be modified to accomplish that, I'm sure it's doable


Well, I don't want to stop you. But I am afraid there won't be a positive agreement on such a thing, given the masses of users that are active here alone


By all means, re-implement Slack. I'd love nothing more than to see that--I like to stick it to the man as much as the next guy. But at least please let it have relatively as nice UX and all


And I'd still like to see a bridge from the FOSS re-implementation of Slack to IRC


maybe it's just time for an IRC+. An upgraded protocol that supports all that stuff that slack supports. I guess this is the correct way to go. Everybody could build their own stuff around it then, a desktop client, a web client, servers, whatever, just like what happend with IRC, but, with more features.


Good morning channel. Lots of discussion, which is great. Now I'm going to be the guy that summarizes what's already been discussed so that people quickly see what's already been discovered and decided.


Thinking that slack is just a nice UX over IRC might be true as a thumbnail concept, in reality there are a number of small things that add up to the one conclusion that it just ain't quite that simple. So I'm going to ignore further discussion of this concept. If you don't believe me, search the archives and/or the discussions that we've had on the test mattermost server.


I think it is understood that paying for slack is prohibitive in the extreme and that the people most actively working on looking for alternatives want to have only a free system for users. But even free for users will likely mean some cost for someone for hosting and admin. There are some in the community who, for mostly business reasons, would be willing and able to contribute funds to cover those costs. Effort is being made to establish or work with OSS non-profit type organization that could oversee the management of these funds.


@meow: nice summary 😄


The businesses that would and could provide financial support have the greatest need for certain features like archiving of public discussion, archiving of private messages, ease of working with uploaded files (like error logs and screenshots for tech support). Since meeting their needs only improves the system to the benefit of the entire community I have no problem with making those features a priority in any evaluation.


I would not want to discourage anyone interested in building a brand new system in Clojure from doing so. At the same time, we are dealing with a risky situation and are trying to mitigate that risk. Therefore many of us are risk averse. We also recognize how many little niceties we have come to enjoy about the slack experience. So we are being brutally honest in our evaluations of alternatives, like gitter and mattermost, and I don't see any reason to apply any other standard to a proposed clojure solution.


Then we start getting back into gray areas. Obviously we are all sovereign individuals here and can do damn well what we please. But we are also a community and whatever that means to each of us I think we recognize that a good part of the reason we are all here is exactly that - we are all here. So migration becomes a concern. We could easily create one or more new systems and let people migrate to whichever they wanted, when they wanted, or belong to all of them at the same time. But that fragmentation might destroy the very thing we are trying to preserve and grow and support.


So I'm sure we are going to revisit some of these topics over and over again, and that's just part of the process. It won't be easy. It will get messy. Feelings will get hurt. Haters will hate. All to be expected. But I think there are enough people with good intentions and lots of experience that we can do this.


Mattermost is the system that seems to have the most promise so far. Several of us are banging away on a setup that @gjnoonan has graciously added to the clojurians server. Most of you are already there, but for anyone who isn't I would be more than happy to PM you an invite link. All you have to do is ask. simple_smile


Good summary, thanks Patrick


I would like to stress again, if we want to build something new, I think an addition to the IRC protocol would make most sense regarding community spread and availability of new stuff. That said, I would like an invite 😉


I am currently at work, but I will chime in today to answer questions and concerns, however I know after discussions with a few people in here they understand my reasoning and ideals of community, and will be able to answer as well as I.


@sveri: how about with IRC bridge 😉


@gjnoonan: Yea, something like that


Just for grins, I'm going to change hats and advocate for the development of a system written in clojure. I mean, why not? We've got datomic and om and devcards and plenty of other good tools. If we can't do it, who can? Doesn't this seem like the perfect time? A year ago, maybe not. But now? How could it fail? This isn't rocket science. All the rocket science is handled by datomic and om and the other tools out there. They are the best of the best. All that's missing is the icing on the cake and a good cook who can combine the right items for a meal. That's it. Lots of work, but totally doable. No reason it shouldn't succeed. Right? Right? Poke holes in this man-of-straw argument, please. simple_smile


@meow: it's certainly not impossible simple_smile I think establishing some sort of support structure to make sure people have an incentive to invest their time is critical too.


We can make a Clojurians Foundation and then we can have all the politics the node people have too simple_smile


Yeah. And committee meetings.


But seriously @tcrawley can speak about the effort to work with a non-profit to make this happen but that's just the nature of the US economic system and I don't think bitcoin is stable enough at this point so we're going to have to play a game with involving an org that can help manage funds.


How long do we think it would take to build out a system suitable for production use?


The politics will exist no matter what. Hopefully we can rise above it all.


@shanekilkelly: No clue. But there are reasons why I would be optimistic in general. Datomic is proven tech. Om next is getting rave reviews and while I haven't yet worked with it personally, I consider it to be proven tech. Om is based on react, which I think we can agree is proven tech.


I don't know what other big pieces you need for this puzzle.


I would leverage devcards as much as possible and it has great support for react and om.


The biggest missing piece would be mobile clients, but I’m sure that could come later.


IRC is just a protocol and we also have clojure wire protocols.


good point - client support


Why devcards specifically? I’ve always had the impression devcards was a dev-time tool, not something to build an app on top of.


@seancorfield and @mfikes have been doing a lot of testing of various clients in our evaluation of mattermost


Why devcards? Because I wouldn't build an om app without using it as a developer tool. And because it has the potential to be much more than that. I used it to create tutorials about the code I was writing. More people are doing that now. So it can be a publishing platform. Why not leverage that into a chat platform?


I'm really just saying that a lot of the pieces are already there.


We could have a big debate about an sql database vs datomic and it wouldn't really matter because it never gets seen by the user so who cares as long as it works, but for me I would only have an interest in doing this if we went with datomic because this is clojure and I've done so much sql I never want to see it again for the rest of my life and I just hope CJ Date isn't reading this.


And more to the specifics of your question I'm not saying that we could build the whole app on devcards, just that devcards is an important piece of the puzzle.


I just don’t see what devcards brings to the table outside of a dev-time (or even demo) context. In the context of a production app, does it actually do anything that would not already be done by Om itself?


I don't want to get sidetracked here. I have visions and then bust my ass to make them happen. I see potential in devcards. Why was electron spun off from the atom development effort? Because there was more than meets the eye in the code for an editor. And I think there is more than meets the eye in devcards. But that's just me. The bulk of this app would be just om/datomic, definitely.


Think of Circle CI. Lots of people swiped their approach to working with om, not because they were working on a continuous integration app, but because Circle CI had come up with a model for how to work with om.


Do you want to make this open source?


It would have to be to keep my interest.


I can't speak for anyone else.


Same for me


I've been giving it away since 1999 and I don't plan to stop.


I would participate, although I don't have much time to share


I have to say I would be really excited about a clojure solution and would love to be involved.


I would be able to help coordinate/cheerlead a project, but I couldn't be the lead developer as I've got another big project I'm already committed to.


And I think there is plenty of OM and Datomic talent that we could draw upon.


And we can communicate openly the whole time using something like, oh, I don't know, maybe Slack?


Yeah? Would slack be good for that? I hear people like it.


Any names proposals?


slack-alike, moar-slack, slacker, slackest - don't get me started - I used to buy domain names by the dozens


Not sure if having slack in the name is problematic regarding copyrights?


how about clack?


um, you know, sometimes I jest


well, okay, mostly I jest. sometimes I'm serious


how about crack? I think its overrated and isn't a good enough high for the money


oops, that one wasn't a joke


way better!


like shat rooms


I have a monthly episodal Clojure Dojo I run in London that is building the slowest developed Event Management system (think 'meetup' but codenamed 'meetdown'). This is more an exercise for those who don't code clj/cljs in day jobs to get to build something substantial. However, we thought about a Slack replacement. Happy to direct resources to this project but it will be ad-hoc and mainly for a small amount of time monthly which probably means by time last months work is groked the dojo is over but I'm happy to table it to the group.


If we do this project I wouldn't turn anyone away. Just a matter of figuring out the best fit of what needs doing and what the doer is capable and interested in doing. Just like any other open source project. This would have to be a group effort for me to be involved. I already have a personal project that is all about me. I can't handle another one. If I got involved in this one I would take any and all help and it would be consensus driven and collaborative and open and a team effort.


Even to the extent that I could be talked out of using datatomic, om, devcards, whatever. Group decides.


Just no drama. Only grownups allowed.


Maybe someone else wants to lead this kind of project. If so, great. I hope they speak up.


We had one app demonstration and concluded that they weren't quite ready and I hope they come back with another demo, or get involved in whatever comes next.


Yeah - was that the @rafd demo?


I added this item to the list of suggested topics for clojure/west 2016 - I hope I came up with a proper description: Growing & Supporting the Online Clojure Community (IRC, Slack and Beyond)


@meow: I think you underestimate the richness of the Slack experience captured in my depiction of it as a "nice UX over IRC" and I really don't like your unilaterally shutting down the idea.


If you had doubts about whether that idea could truly capture the fullness of experience of Slack, then you could have asked for help in seeing it.


@johanatan: thank you for bringing this to my attention and please accept my apology


@meow: apology accepted and for the record, I think we are on the same page feature-wise: I wouldn't want to compromise any aspect of the Slack experience and have only the highest standards regarding such.


I'm not sure what part of your message I misunderstood so I hope we can talk this through.


I'm not even sure in my own thinking what I was trying to dismiss about the IRC ideas. Certainly not the notion that there is quite a richness in the Slack experience.


I advocated for a) not dropping Slack and merely installing a high quality bridge to IRC. If a) can't or won't be done then b) reimplement Slack


I think what I was trying to address was my perception that some thought that a bridge would be simple and do the trick.


Again, I apologize for my crude attempt to summarize, dismiss, and bring things to a focus. Like a bull in a china shop.


Well it would be relatively simple (certainly simpler than a full reimplementation) but it would create two experiences.


Two functionally equivalent experiences but one more plush then the other.


Yeah, there are real problems with a diversity of experiences.


How so? IRC already has that with its multiple clients


And we aren't getting rid of IRC because of that


The thing about not dropping Slack is really the opposite - we have no control over them dropping us. And that isn't just a made up fear.


Sure but you are still not seeing Slack for what it is: an IRC client


I'm listening.


We archive IRC. They drop us so what?


With the bridge in place all comms on both channels are identical.


Okay, I think I'm with you so far.


Can you describe what happens if slack drops us. For example, I just use it in my Chrome browser. What would I do after slack dropped us?


That being said, I'm still not opposed to a rewrite in Clojure (and think that would be awesome actually). In the interim though, the bridge may be a stopgap.


Mm, you would find an IRC client that you like (perhaps even browser based).


describe what that would look like with your irc bridge in place, I meant


right, okay


that's the problem


How's that a problem?


And why would Slack suddenly start dropping paying customers?


The concern is that people don't want to find an IRC client and we would lose a lot of the community that is here on slack.


When it is pretty much their entire business


we aren't a paying customer


In that world we would be


Each person would have to pay the $8/month


For their own use


I would not be part of that world then.


Lol ok. My vote is for rewriting it then


Might I suggest: sticking with Slack for as long as they have us, but having a backup solution prepared. I doubt Slack would kick clojurians off (and all other communities) without at least a few week's warning. Evaluating an alternative, as is being done now is good. Whatever wins, we don't have to transfer immediately…we could have it archiving in the background. It may be that Slack won’t do anything, or will come up with a community plan, who knows.


We know that Slack are working with to resolve T&C issues, BTW.


@seancorfield: unworkable due to the way Slack expects that payment?


Unworkable due to several of the premises on which this community operates: it must be free to participate for those who cannot afford it for whatever reason and it must have the low barrier of entry that Slack provides (which is why IRC has never grown to the level that Slack has).


I’m in nine Slacks. One is a small FOSS team (on the free plan). One is work (and paid for). The other seven are 1,000+ communities, some of which are only tangential tech-related.


Gitter gets rejected partly for its lack of UI/UX polish but also because it requires a GitHub account which is considered a barrier by many.


IRC is great as a plain text communications tool for communities but it’s a pretty sucky UI/UX, even with the nicest clients. And even with those clients, you’re still confronted with servers and ports and a bunch of IRC mumbo-jumbo that is irrelevant to "having and growing a community".


If you want to bolt file uploading, code snippets, formatting, pasting images inline, sharing links that auto-expand and a whole bunch of features on top of IRC, you’ve got to also consider how all that affects the users of the underlying IRC rooms. You also need to consider community administration: Slack allows an administration team to manage user accounts, permissions, integrations and so on.


Even on a closely controlled IRC server, maintaining decorum in a community is nigh-on impossible: have you seen the drive-by trolling and abuse that happens on Mozilla’s IRC servers in the Rust community, for example?


I gave up on the Rust IRC community because they seemed unable to prevent spamming to a level that was making rooms unusable.


Ahh, interesting


On their own servers


Ok, well I think we should reimplement Slack in Clojure in this case


Would be a great way to draw attention to the language and ecosystem


re: writing our own, my offer from before still stands (to open-source prototype and lead the project). The project grew out of personal need in my team for something better than Slack for actual productive work (I find the IRC room-based model not great - too many topics in a room at once, a lot of noise). My interest is in making a better chat experience than IRC/Slack/other-clones (for teams, I’m already convinced — for communities, less so, but I haven’t spent any cycles on that problem). My vision is different than “let’s just clone Slack,” — but I do want it to support communities. It’s probably not a good solution to the current problem (not mature enough, will take too long to meet our requirements)… but it still may make for a good community project… and in the future, who knows.


I’ve opened a new room ( #C0J20813K ) to keep discussing this, independent of the decision that may be made with regards to what to do with the current setup.


"not mature enough, will take too long to meet our requirements" — well, it’s already further along than any other "Slack replacement written in Clojure/Script" 😸


...but also, the model might not work for 2000 people... although i think a "Real-time forum" (like dIscourse, but real-time) could work well


I wouldn't bet everything on a new project meeting our needs before [Slack cut-off threat], but at the same time, I don't think a binding decision is necessary now.


So far, the most mature alternative we’ve looked at is Mattermost (Go/React stack, has iOS, Android apps, has Electron-based clients for Windows, Mac, Linux) and it’s pretty clunky in a lot of areas that we take for granted with Slack.


I think it's a valuable effort to undertake even if it doesn't end up being the right solution.


We’d also have to figure out how to bear the cost of hosting and running Mattermost and whether we’d want to fork it and enhance it ourselves, or stay with the stock project (and live with its shortcomings).


But right now I suspect a large proportion of the 4,400+ people here on Slack would not find Mattermost an acceptable replacement — unless of course it suddenly became the only option if Slack shut us down.


I would be interested in seeing why people have latched onto Slack vs. IRC. Clojure is the first programming community I've really clicked with, and at this point I would follow regardless of features as long as a chunk of the community moved as well. In some ways I think it might be easier to migrate if Slack shuts us down, where it might be difficult to move it over voluntarily.


"I would be interested in seeing why people have latched onto Slack vs. IRC." — mostly because of the issues with IRC I listed above, which Slack does not suffer.


Yeah, that's my main reason as well - I kept thinking of going on the IRC channel but never wanted to put in the effort.


So folks who prefer IRC over Slack can already interact with this community via IRC.


@rafd given that we know we have already more than 4000 users does it make sense to follow your plan?


IF we migrate now, likely lose 30% of the community, ...and then 2 months later, Slack creates a community plan... we'll be kicking ourselves.


(any solution we build must be able to support at least the current 4,400+ users and would potentially need to scale to 10,000 — I believe the Google mailing list clojure has more people than that?)


...or have a plan in place, so when Slack sounds the horn, we can transfer to the alternative smoothly.


@seancorfield: yes but the other direction is important too. I'm sure the IRC community would be a vast resource to tap into for most folks on Slack. This is why I'd like to see a bridge regardless of which way we move forward


Since mattermost is react based, hopefully we could base something on their ui if we reimplement. I believe the ui is by far the hardest part of such a project.


Evening all, just catching up it seems I've missed quite a bit