Gitter is one of the most popular chat room services that was based on github repositories and authentication, but was bought by their competitor - gitlab.
Great point. We "soft launched" this yesterday so are still working on the documentation and hadn't made any official announcement yet until we've ironed out in any kinks.
If you go through the commit history you can see that they removed a lot of secret keys from the repo.
What if the main reason why people don't want to opensource their project is because they don't know how to use their secret keys without including them in the repo ?
Not having started out as an open source project, this was always a major consideration.
Once we've finished fully open sourcing everything, we should look to write up our experience around the conversation, in particular, the tools we used.
ENVs in a private repo would definitely be convenient, but the best practices I've always seen are to omit those values even from a private repo (for security but also portability)
Asking users to run mongo, es, neo4j, and redis is a tall order. Mattermost just needs (AFAIK) a relational database.
Also, less relevant but the Gitlab UI has far too much wasted whitespace. Like 85% of the page is navigation. I like open source competitors to incumbents but maybe just copy Github here - no one is gonna say anything.
Mattermost isn't exactly a simple bbcode-enabled chatroom though. They have support for multiple projects, an API etc. Achieving this with just text files would be quite the headache.
It's greatly improved from the original version and official release is this month.
Mattermost mobile notifications aren't a commercial feature, they are just off by default due to privacy (push notifications appear on a mobile device when the device is locked).
Go to System Console > Notifications > Mobile Push > Send Push Notifications to enable.
Sadly the Android's react version seems to lack any share features - the app doesn't appear in any 'share to' dialogues, nor can I share pictures or such from the app itself (For example using rocket.chat I can long press on an image and I will be able to share the picture to other apps). The issue appears to only have around 100 combined votes on uservoice (https://mattermost.uservoice.com/forums/306457-general/sugge... + https://mattermost.uservoice.com/forums/306457-general/sugge...) so I'm not holding my breath for this to be implemented anytime soon, but it would be a really useful feature to have for when you need to move graphical assets around and you want to take a quick look on your phone for example.
Gitter is not intended to be a replacement for Mattermost, Slack or other team collaboration tools. We see Gitter as a community instead.
As such, we're not expecting to see a huge uptake of on-site installations, so the list of required services (es, neo etc) is big compared to other products focused on on-prem.
We're hoping that our users will contribute to the main site, Gitter.im.
Obviously, we're also totally happy with users running their own Gitter installations but, while we would like it to be easy, ease-of-installation of a production instance is not a goal currently.
We use Ansible / packer & terraform. Open sourcing this repo will be fairly complicated but it may make more sense for us to publish a k8s helm chart or more complete, production-ready docker-compose.yml
you are already using docker-compose.yml. you should use definitely do a production ready docker swarm deployment. you only will need to do incremental changes to your docker-compose
We have a docker-compose.yml for development environments and I'm currently in the process of simplifying this[1] so that Docker for Mac/Windows will be able to spin up an environment with little effort.
We use ansible for provisioning beta/staging and production. We have yet to open source the ansible repository but, since we're switching to GitLab CI/CD, the deployment process will soon be publicly accessible - even for production.
We currently use docker-compose for the development environment. I'm currently simplifying this to allow developers to get started with minimal effort:
Yes it's rude, but I want to love GitLab - it's amazing. However I just can't bring myself over with this UI. It's just too bad and too unintuitive. Also slow.
Oh, sorry I missed that you said GitLab. It's less rude if you're not commenting on the open sourcing of a project to just say negative stuff about it :)
I have to use GitLab for work and I find the UI much harder to use than GitHub, so I agree there. But, it's open source and we can all contribute, and in particular the best place to make your feelings know about the UI is constructively in the issue tracker.
This type of feedback is almost completely useless for a project. "the worst", "too bad", and "unintuitive" are not actionable so if you really want to help a project then describe concrete issues.
"I'm not an UI/UX expert but a back-end developer."
This actually makes you the perfect candidate for giving us good feedback. You may not be able to articulate exactly why UI elements feel off or don't work for you, but you know they could be better. If you are interested, you can join our UX Research Panel to help us pinpoint areas we can improve. We want you to love GitLab too :)
This is actually the first real project I've come across that uses neo4j - thank you for pointing that out.
Given the requirements, I actually think this project looks rather clean between the docker-compose-file and the npm dependencies.
I very much doubt it can compete with Mattermost or Rocket.chat for self-host for small organizations - but I'm really happy to see this thing open sourced!
I much prefer it to be opened up as soon as possible, and then flicked on later.
If there's one thing I'd like to see (beyond a reduction in what appears to be a default of three? mongodb instances) - it would probably be a set of juju charms for bringing the thing up under lxc/lxd on Ubuntu.
I just revisited the combination of juju+ubuntu+lxd - and while I was skeptical when juju was introduced, it appears to be a rather sane toolkit for automating deployment IMNHO.
you might think that this thing is insane overkill - but if you start at the beginning of the series[s], you will (or I did) get a warm fuzzy feeling about how much fun it is to play with lxd on top of zfs. I suppose some people think docker is just as fun (and warm and fuzzy) - but I don't know. LXD does feel like it combines the good parts of linux with the good parts of bsd jails.
Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it.
These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a chance, I would like to remove the dependency we have on neo4j.
You might want to reach out to Al Baker or Kendall Clark at Stardog. Their product is more RDF centric than for generic graphs like Neo4j, but is in my opinion a much better product. They have a community version, and have open sourced several pieces, but it is commercial. https://www.stardog.com/docs/
The big problem with the way we use neo4j is around huge rooms with ~100K users. The number of possible rooms that neo4j has to traverse (even a shallow traversal) for a user in a big room is huge.
Thanks for your recommendations. I'll definitely check them out.
Those huge rooms really don't add anything to recommendations (like everyone buys milk), if almost everyone is in the room you can also just leave it off (the same is true for rooms with very few users).
That's why in recommendations, I usually filter them out b degree (which is a constant value read).
MATCH (r:Room) WHERE size( (r)<-[:MEMBER]-() ) < 5000)
...
You're also not using directions in your queries, which will also help.
I looked at your other queries, they can also be improved easily, if you want to I can help you do that. Just need some sample data or a read-only access to the db.
Just ping me at michael@neo4j.com.
It looks like you're still using Neo4j 2.3. Have you tried using newer versions of Neo4j? There have been some pretty substantial performance improvements.
Additionally, Neo4j does support clustering with their Enterprise edition. It also has much better tooling (better metrics/logging, backups, etc.). It is AGPL licensed, so there's no reason not to use it really.
Linux doesn't really have to since 99% of users use distributions, not LFS.
And there's a difference between gratuitous (or almost gratuitous) dependencies and must have ones. From what I read in the other comments Neo4J doesn't feel like a must-have for this project.
Plus, to be honest, Mongo, Neo4J, Redis AND Elastic Search? That's got to be overkill :)
It's not the actual codebase, it's kind of a branch that has to be manually updated (by cherry-picking across commits from the "real" one). It used to be kept in pretty close sync with the code live on the site, but it seems like they don't care about updating it any more. There are things that have been live on the site for close to a year now that aren't in the open-source repo.
Sorry to hear you're displeased with our UI. We'd love to hear any suggestions you might have. We're always looking to improve as much as we can. You can open an issue in https://gitlab.com/gitlab-org/gitlab-ce/issues
We started Gitter before React was A Thing and Marionette had a lot of the functionality we needed. We even hacked it to do server-side pre-rending and live collection binding. Topics was an experiment in how we could look to move towards react and evaluate blending technologies.
While I applaud the initiative of Gitlab to opensource Gitter I think the target audience for self hosting is rather small. I think alternatives like Zulip or Mattermost are probably better suited for most organizations.
I am however interested to see if the community starts making the "main instance" (gitter.im) better.
Interested to know what the Gitlab / Gitter guys and gals think what the target audience is.
We're trying to achieve two things with open sourcing Gitter.
Firstly, we see Gitter as more of a community than a product. That we have nearly 1,000,000 developers coming together on the platform to talk about code and open source software where public rooms far, far outweigh private rooms, is testament to that. So we're not trying to compete with MatterMost.
What we're trying to facilitate is to allow the community and users of GitLab to contribute to the experience of the community. We've always had a very small team at Gitter and the surface area of the product is massive. This way the community can help us make it a better place by improving the product.
We also have some communities who are interested in running their own public instance entirely. Sure they could use other products, but Gitter is built community and public first and suits a lot of different needs that other products don't necessarily facilitate out of the box.
IRC is not going anywhere but projects like neovim use gitter primarily while IRC is linked using a bot. They view the IRC chat in gitter.
Dunno if Gitter is better than IRC as I have only used for help and support (for me) but Gitter was far easier to use than IRC. Just Login and start chatting.
I don't think IRC is going anywhere either... We just have alternatives to freenode now in Gitter
it's not very comfortable to use though. Partially because the gitter features don't match how IRC is used 1:1, partially because it seems to have some bugs and sometimes does the simplest possible but uncomfortable thing (which might now get fixed!)
Apropos, does anyone know of a hosting provider with one-click installs of Weechat? It would be nice to have something slightly more self-hosted than irccloud to recommend to the GsoC/GCI students who keep disconnecting from freenode :)
(You'd think with all the Wordpress one-click-installs that this would exists, but I can't find any yet at least.)
Does Gitter have federated servers using a standard protocol and a vast array of programmable extensions? None of these hosted solutions are even in the same league as IRC, and we are worse off for it.
As someone who has written an IRC server implementation, there is no standard protocol. There is an RFC, but no one implements it. Instead, each server uses its own mix of poorly documented pseudo-standards.
I don't know if this still holds true. I've been a IRC user for ~20 years and the current state is a fraction of the fraction of it was once before. Compared with the entire internet, it can already be considered irrelevant, imo.
IRC as general chatting service is outdated. IRC as communication between developers and for tech support is relevant because it's easier and simpler to set up and use.
I agree that self-hosting audience is probably small for this, but open sourcing also changes its image and workflow a bit.
I'd much rather pay for a hosted FLOSS app, than a hosted closed source app (assuming similar capabilities). Being able to inspect the code, and knowing that anyone's free to collaborate or reuse the code really makes a difference on where I choose to put my money.
They are creating the infrastructure for some kind of projects that currently don't exist. Local / national Githubs/software communities might be a thing soon, and Gitlab will be powering it if happens.
Self-hosting market isn't that small. The entire gov/aerospace/anything with ITAR/ETAR etc is stuck with very few options that are self-hosted or fedramp approved cloud options.
As an aside, I badly miss the Github language statistics in gitlab repositories. This is one of the crucial info for any developer browsing through new repos and it is very counter-intuitive to have this info hidden from homepage.
In addition to that, I'd like to see the number of SLOC for each language to get an idea how large the project is. Is this a weekend project? Is this Linux kernel?
What? Why? Why shouldn't I be able to run my entire application without relying on 3rd party distribution channels? Caching my dependencies in node_modules is perfectly reasonable to me. It's not like I'm getting binary diffs. It's Javascript.
Caching node_modules is fine, but not in the mainline branches of your source control. Let your CI system put it somewhere, after it passed tests. Tarball, a dedicated git repo/branch, Docker image or whatever else is practical.
To control versions of dependencies pull in, narrow your specifiers in package.json, verify that the deps use semver sanely, and consider a lockfile.
https://docs.npmjs.com/files/package-locks
You're not caching anything by checking it in git, you're mirroring it (very poorly). Your filesystem caches it; you still rely on your remote to download it.
If you want to mirror your dependencies, run an npm mirror subset or something. If that sounds crazy to you, that's because mirroring npm dependencies is unnecessary for virtually everybody.
Oh, and you are also making your .git folder 100x larger than it otherwise would be, making your initial download and on-disk sizes a lot bigger, which can also slow down other git operations. Not to mention the atrocious amount of noise whenever someone does a git blame, git log, git log -S, ...
In other words, checking in your entire dependency source tree in git is unnecessary, wasteful and annoying in the best case scenario.
I've really enjoyed Gitter as a better means of communications when I have questions that are small enough to not need their own issue, yet also not worth it to ask on SO or some other platform.
It has been nice to be able to have a nice way to talk with other open-source collaborators or get quick clarification on a small repo-specific question.
The biggest problem I have with something like this is that unlike SO the answers aren't archived for others who may have the same issue. It would be nice if discussions like this on Gitter could be archived and searched the way mailing lists are.
Right, I meant more in a Q&A fashion with perpendicular discussion like with SA. But I'm happy to see there is an archive. I've had decade old Mozilla bug reports save me more than once.
Gitlab UI is truly horrid compared to Github. When I go to a repository page on Gitlab, the navigation and whitespace takes around 80% of my screen. On Github I can immediately see the directory structure.
Also the colour scheme is bad IMO, everything is a light shade of grey, hard to quickly navigate the page as things look all the same while scrolling. Try using some darker shades and more contrast to make different parts of the page more easily distinguished.
Anything specific about the UI you'd suggest changing? We'd love to hear your feedback so we can improve. Feel free to suggest improvements in https://gitlab.com/gitlab-org/gitlab-ce/issues
Thank you for the specifics, it is helpful to know what UI elements we can improve on.
The submenu is going away. We have done extensive testing on our navigation and are making significant improvements. Take a look at the issue, I would love to know your thoughts:
We have a few issues to address improving the pipelines interface, take a look or create issues with your suggestions on how we can make the UI better for you.
I clicked on the title of this post which links to gitlab repository page. And I was frustrated with the UI while trying to find out more about this project.
Clicking on the title brings you to the project page which shows the latest activity for that project. I can understand being frustrated as you most likely expected to land on a page with files and a readme. Clicking on the Repository tab will bring you to this view. Project owners have the option to make the repository view the default view. It looks as though this was not enabled on this project.
Gitter co-founder here: we use neo4j for suggesting rooms.
So, if you're in room A and room B, and most people in those two rooms are also in room C, then we suggest that you join room C.
As I mentioned elsewhere, we also use some non-neo4j based methods for suggestions (including your GitHub graph). One of the problems we've had with neo4j is that we haven't been able to make it scale. It frequently burns up from being overloaded.
This is almost certainly down to the way we use neo4j but at some point I'd like to ditch it for a clustered suggestion algo that uses batch processes to cluster rooms together.
Sounds like you're going to be doing a lot of writes, which neo4j isn't designed for. While I get why you're using it, I'd suggest that it's not really the right tool for that job, which is possibly why you're having problems with it.
Do you really need persistance at all? If the application crashes everyone would be kicked out of the channels anyway no? I think making an in memory graph and ditching the graph DB entirely would be more helpful for that kind of suggestion tool.
Neo4j Powers a 1.2 Terabytes Size Data with Nearly Three Billion Nodes and Nine Billion Relationships to Create the World’s Largest Consumer Identity Graph. Neo4j’s native graph clustering architecture is ideally suited to deliver real-time query performance at scale, across massive customer graphs. Please see: https://neo4j.com/news/qualia-media-customers-experience-gre...
I just wish I had time to work in my side-project http://git.chat and investigate the ability to implement chat-like functionalities into the git-repo/protocol itself.
I really think any kind of discussions related to open-sourced projects should be stored together with it rather than a 3rd party in a closed environment.
Start small: a CLI chat client, no auth (auth is the ability to push to the remote), install a fetch hook to notify user of unread chat msgs, done.
At that point anyone can use it.
Personally, I don't think that it's even a right format for questions which are not part of a larger discussion (e.g. deciding on details of some issue or PR).
I have never seen link to gitter in google search results, and answers vanishing forever (not sure how good gitter search is though) does not sound good. Once I joined a few channels because I wanted to ask maintainers a quick question if $xyz sounds feasible or am I strongly misunderstanding things, because had some ideas how I could contribute. These were rather popular repos and all channels were full of low effort questions that could be either google-able or answered by spending a few minutes playing around.
That doesn't sound like a Gitter issue but a lack of activity in that particular project/community.
Some projects prefer email/github issues over chat as there isn't an active community around it 24/7 for anyone to just jump in and ask away.
I maintain an open source project where we have set up Gitter awhile ago. So far -even with a really small community like ours- I'm answering questions and interacting with users regularly.
It depends on the project & maintainers, not the tool. When I was learning webpack a couple years ago I had a great experience asking for help in their gitter.
This reminds me of something I want to share with HN. I've put a lot of thought into how technologists seem to forget to think about how their tools will be adopted and used in a collective sense. They seem to not design their tools for the end result.
Gitter has been a huge part of freeCodeCamp's community since the beginning. Thousands of people have asked questions there, and most of them have gotten helpful answers quickly. This is thanks to the experienced developers who contribute their time and expertise in there.
Like IRC, it's a great platform to ask and answer questions on. Find the right rooms and talk to the right people.
I co-maintain an open source project on GitHub that's somewhat popular (>1.5k stars). We set up Gitter because I preferred Slack which my collaborator didn't use, and he preferred Gchat which I didn't use, and Gitter looked like a reasonable middle ground. Since then it's mostly been a communication channel between us two. We do get a user question once in a while, and I do answer when I get a notification email. Basically, for users it's like opening an issue, just less formal.
That is just not fair to say that gitter is the reason your questions go unanswered. Gitter is a chat technology. It depends on who you're chatting with not the underlying technology. Its like calling and ordering pizza, and then blaming your phone because the pizza is cold.
GitLab, a startup that provides open source and premium source code repository software that people use to collaborate on software, is announcing today that it has acquired Gitter, a startup that provides chat rooms that are attached to repositories of code so that collaborators can exchange messages. Terms of the deal weren’t disclosed.
> Whilst drinking your tea, make sure you have Gulp installed. You can do this with npm install -g gulp. You may need to use sudo for this.
How blind can you be not to understand how evil this request is to your users? And you request this because... because you don't want to `sed 's|gulp |node_modules/.bin/gulp|g' Makefile` ?
Similarly, too hard to check npm's version in Makefile, and run or not run `linklocal` yourselves?
Running any npm module install script through sudo is a bad idea unless you are very sure of exactly what will be installed and how. There's a reason why distribution packages are generally signed and package managers require packages match repo sigs.
It's not really that bad, unless you install it with sudo. The need to have gulp installed globally is unnecessary. They could just add it as a normal dependency and put the specific gulp command in the scripts section of their package.json. It wouldn't require the user to do anything extra.
Two others touched on the sudo part but the global flag is as bad. So they have a gulp file that works with gulp "v1". Gitter goes bust (inactive), next year gulp is bumped to "v2", you want to try out gitter, gulp fails, you have to digg why. Another scenario is when another project asks you do the same, install gulp globally, but it actually means gulp "v0". Now you can't run to projects side by side.
Global deps should be versioned, the same way you do not see a respectable npm module with "*" semver in its package.json.
Seeing things like this in 2017 from smth like gitter! now owned by gitlab! is just a big red warning "amateur work, please look away".
How can you have a Makefile, a Makefile! and still require gulp, and still require people to run "npm install"? How? Where's the bare minimum logic?
As Gitter was originally built as closed source with a team of people working exclusively on Gitter, this has never really been a problem for us.
This is very much v1 of the setup/instructions and would be delighted to improve them with any MRs or contributions. We'll certainly improve them ourselves over time as we get more people in less controlled environments adopting the project.
Btw on my phone the notifications are never cleared, always showing a super old message from hundreds of days ago for me. It's annoying because I cannot see why I got the notification. I wonder if this is already in your bug tracker.
In the original blog post announcing the Gitlab acquisition (http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/), there's mention of open sourcing the mobile apps -- "Next piece of wow: we will be open sourcing all of the Gitter. That’s right, the web application, the mobile apps, the whole nine yards, free and open."
reply