311–320 of 325 posts
Earlier quoted context omitted.
It's great to see such a fast, and positive response. It's a whole league away from companies that don't even give any transparency or feedback! <3
You're very welcome.
A suggestion I have is to consider open-sourcing and re-branding EE on a GPL-Like license that also requires projects hosted with it to be open sourced, while specifying that contributions to this version can be re-licensed by GitLab to be used by paying customers (Or re-licensed to MIT and released on CE). This way open source people get it all, and if you want to use it on closed source you pay GitLab.
This also has the benefit of allowing open source developers to work with GPL, and the changing to MIT could even be decided before merging (Sending to either CE on MIT or EE on GPL+GitLabProprietary, according to developer decision).
There's a lot to fix on the OpenSource world, but there are also so many possible ways. Best of luck to the GitLab team, I hope we see more amazing stuff from you (Btw, GitLab CI got a lot better recently, I hope you keep improving it. :D)
Earlier quoted context omitted.
Can you comment more on why a hobbyist should not need their own repo? If I'm doing SaaS for everything, my monthly costs start to go up. I've found it is far cheaper, and far (way!) more educational to take an extra box out of the basement and install Ubuntu/GitLab/Node/Java/Apache/Etc. I have to pay for internet either way, and the electricity cost is nowhere near the cost of having multiple Saas?
Most of the time, it's because of opportunity cost: The time you're spending building a server, learning how to manage repos, setting up redundancy and just trying to get the thing working, you could've spent on whatever product you were trying to produce, and would likely be much further along with if you hadn't done everything the hard way. That's not to say there isn't educational value, but a common piece of advi…
That said, you do have a point, and you decide what matters to you as a hobbyist (or whatever you decide to call yourself).
I personally like (and need, most of the time) stuff that "just works", so I totally get your point about optimizing and agree with it.
Earlier quoted context omitted.
I wonder why they advertise the "platform"/implementation language so clearly (in this case Go). It shouldn't matter for the users? I get sceptical, as if the only reason they exist is to provide the same service but in a new implementation.
Performance. That thing is _fast_ when compared to a Ruby-based stack.
Earlier quoted context omitted.
I was unaware of this. Thanks for the link. It seems just about everything is being re-written in Go these days...
Go is easier to deploy than Rubby on Fails.
If you're not you just seem like someone who came to the NodeJS Party late and didn't understand Go is C for gigantic codebases using parallelism. :D
Congratulations on GitLab, I personally use it and love it, and it's awesome to see amazing people like the VLC team considering GitLab. A suggestion I have is to consider open-sourcing and re-branding EE on a GPL-Like license that also requires projects hosted with it to be open sourced, while specifying that contributions to this version can be re-licensed by GitLab to be used by paying customers (Or re-licensed to…
Meanwhile, Phabricator has implemented all of these (and even more). Custom templates: https://secure.phabricator.com/book/phabricator/article/form... Votes: https://www.mediawiki.org/wiki/Phabricator/Tokens It's better in almost every aspect than GitLab and GitHub. See https://en.wikipedia.org/wiki/Phabricator for an (incomplete) list of open source projects using it.
As a quite disappointed user of Gitlab (due to issues raised here, e,g, CE vs EE and the Ruby infrastructure), has anyone had experience with both? I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share? Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
That being said, just like any other fairly complete solution, it's quite opinionated about the right way to do things, and it's very different from github or gitlab. In particular, since it is not tied to git, it duplicates some of git's functionality in its own tools. In many ways I find those tools to be better than what git uses (arcanist just seems more well thought-out from a UI perspective), but it is a learning curve.
If you are happy with svn or hg, and don't want to have to switch to git, Phabricator is a no-brainer. If your team is a bunch of super-advanced git users, they may not like having to learn a different way of doing things.
I remember GitLab. They interviewed myself and a bunch of my colleagues to test the salary waters here in the Bay Area and hired nobody because we were all "overpriced", with several being underpaid for the area. If you want the talent you need, especially in the Bay Area, you have to pay more than what the average developer makes in Amsterdam. I want to like GitLab, but I just can't get that bad taste out of my mout…
We never interview people to test the salary waters, we know interviewing is serious for you and it is serious to us too. We're very aware of the salaries in SF (writing this from SOMA). But since we're a remote first company we can hire for anywhere in the world and because we're open source we get a lot of great applicants. So the bar is high and for the Bay Area it is even higher. Feel free to email me at sytse at…
If you know you're not going to pay SF (or even US) sized salaries, why waste everybody's time with multiple interviews then? State up front "We're only willing to pay $80k, even if you've got the history (previous salary, measured prior project impact, demonstrated skill in the areas we need, etc) to justify 2x or 3x that". You won't be able to pick your interviewees brains on possible solutions, but you also won't be wasting their (and your) time.