GitLab Acquires Software Chat Startup Gitter, Will Open-Source the Code (venturebeat.com) 28
According to VentureBeat, "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." From the report: GitLab won't bundle it in its community edition or its enterprise edition yet, but it will open-source the Gitter code for others to build on, GitLab cofounder and CEO Sid Sijbrandij told VentureBeat in an interview. What's happening now, though, is that as part of GitLab, Gitter is launching a new feature called Topics, where people will be able to ask and answer questions -- sort of like Stack Overflow. "Although Gitter is best in class with indexing things, it's still sometimes hard to find things," Sijbrandij said. "In this Q&A product, it's a lot easier to structure the Q&A. You're not dealing so much with a chronological timeline where people have different conversations that cross each other. There's a location for every piece of knowledge, and it can grow over time." That technology is already available in beta in Gitter rooms on GitHub, and it will become available on GitLab's Gitter pages over time, Sijbrandij said.
Re: (Score:3)
That's a silly comment. GitLab is buying Gitter so it can be incorporated into their own platform eventually. They're buying a well-made codebase to improve own product. They could have written it themselves, but they decided that their time to create an equal feature would have been longer or cost more that buying it.
GitLab needs to compete on features with GitHub, who is winning the popularity contest by a wide margin.
Also, "will not be adding it directly now" is not the same as never. I still think the l
Re: (Score:2)
The trick to understanding it is that in most sectors there is little money in software anyways, and most of the money is in support. This is true for the proprietary software, too.
If you think open source companies are failing, you might want to check that one in a search engine. Because you're so embarrassingly wrong that I'm not going to spell it out.
Can't wait for the Git fad to die out. (Score:5, Insightful)
I can't wait until the Git fad finally dies out. I've worked with a number of teams that use Git, and they all use it like a centralized VCS, except it's more awkward to set up and use than a VCS like SVN or Perforce or even CVS is. Then they spend more time arguing about whether or not to rebase than they spend actually developing software.
It's a real shame that Mercurial didn't win out. It's a superior DVCS in every way, except for not having as much mindless hype surrounding it. But I suppose in some ways that's one of its best features, too. It hasn't attracted all of the fools that Git has.
Re: (Score:2)
Of course git is used as a central repository, it _makes sense_ to do it that way... but only because humans don't think "distributively" but instead LIKE having a central repo & repo master. (plus the inherent chain of responsibility that gives the repo master in a business).
If humans have to be able to understand commits, and they do, then it makes sense to make commits work in a way that humans understand.
But just because git isn't USED dist. as much as you would like, doesn't mean anything. It has the feature...
If you're not using it, then git is the wrong tool, because it's harder to make sense of than the things that aren't distributed. So in those cases, those people absolutely are wrong, and git is absolutely a problem.
Re: (Score:2)
Using SVN day in day out is far too slow with non-trivial repos.
(I hear git and hg can be slow too when used with very large repos. But, as I understood, this primarily is when first cloning a repo or during large fetches. In stark contrast with SVN, you don't end up with enough time to make coffee or walk your dog each time you commit.)
Re: (Score:3)
I think it is funny, too. When I used svn, I tried to use it in the ways that it was good at, and if you set up the directories right it is simple and painless even in complex settings. Actual code collisions shouldn't be frequent anyways, so people can like one or the other better for that but it is really a different problem.
I switched to git for offline commits, which svn added but too late to prevent people switching. Once you switch all your practices to the ones that are best with git, then git become
Re: (Score:1)
I've worked with a number of teams that use Git, and they all use it like a centralized VCS
The D in DVCS stands for distributed, not decentralized. The model is up to you, but even with a centralized one there are many benefits. Try bisecting with SVN.
except it's more awkward to set up and use than a VCS like SVN or Perforce or even CVS is.
Then you must be doing something wrong. I’ve had to handle both SVN and git repo sharing and git was a breeze compared to SVN. Not to mention starting a project on your own is as easy as `git init`.
Then they spend more time arguing about whether or not to rebase than they spend actually developing software.
Sure, the tool is to blame for people who like bikeshedding.
It's a real shame that Mercurial didn't win out. It's a superior DVCS in every way, except for not having as much mindless hype surrounding it. But I suppose in some ways that's one of its best features, too. It hasn't attracted all of the fools that Git has.
My first DVCS experience was with Mercurial, and I’m glad git won the race. The o
Startup? (Score:2)
I think it's safe to say they've outgrown "startup".
Re: (Score:2)
I think it's safe to say they've outgrown "startup".
Gitter launched in 2014 and was seeded in 2015...that's a startup in my book.
Re: (Score:2)
GitLab, a startup that provides open source
Re: (Score:3)
GitLab, a startup that provides open source
Sorry, be specific then, it's in the title of the article for Gitter:
GitLab Acquires Software Chat Startup Gitter, Will Open-Source the Code