Thank you for kind words.

GitLab can run on macOS (I do development on it for years without any VM). But Windows is the problem. Most of our dependencies are quite Linux/Unix specific and until those are ported to Windows it's unlikely we can run server code on it.

There is no real reason to host GitLab on macOS or Windows. You can run GitLab Runner on both platforms, so testing, building, deploying etc all works for everyone!

Installing and maintaining GitLab is ridiculously easy: it's never been a reason to not adopt GitLab! For all the way to deploy, see: https://about.gitlab.com/installation/

GitLab's dev kit does work on macOS (and I believe even Windows).

There is nothing more important to us than feedback. A customer that uses GitLab and provides us feedback is 🚀

What I've personally really enjoyed is getting customers with new use cases or a new scale. Today there are teams of 1 and teams of 30,000 using GitLab intensively. That is exciting.

I had a quick search and not that I'm aware, but anyone can make an issue on our issue tracker to suggest it - or even contribute it!

Would love to hear more what you'd need. Feel free to create an issue on https://gitlab.com/gitlab-org/gitlab-ce/issues

Someone else asked the same question, which both DZ and I answered here: hashnode.com/ama/with-gitlab-cj7uu549m01pq2qwurkk…

We're actually seeing a lot of open source projects moving to GitLab. Some times on their own instance, some times on GitLab.com. But we're still a magnitude smaller than GH when it comes to open source projects on GitLab.com. We believe it's a matter of time. GH has been around for a very long time and gets the most eyes still. And we understand that, so we've made it easy for you to mirror your repository between GH and GitLab.com.

We're making sure that GitLab.com is becoming more stable and much faster. By building the best possible place for someone to build and ship software, we believe it's a matter of time before more open source projects will move to GitLab.

No and we don't plan to make them open. We believe that is private, personal information.

However, we base our salaries on a calculator that is open. You can view the one for developers here, for example: https://about.gitlab.com/jobs/developer/

We do a lot of work to update that calculator regularly and actively listen to any feedback.

GitLab started as the weekend hobby. Ruby was my favorite language back in 2011. I wanted to make something useful and practice my skills at the same time. Thanks to Ruby and Rails I was able to release the first version within a month.

To add to DZ: Today we continue to use Ruby, as it allows us to iterate very quickly.

We also use Go for specific pieces in the backend and of course plenty of Javascript on the frontend.

No. We'll never take that away. We realise it's a big strength of GitLab.

We already offer shared runners to build/test/deploy your code. They are free for open source projects and private projects have a limit in build minutes, which can be expanded through our subscriptions for GitLab.com (https://about.gitlab.com/gitlab-com/).

Most of our customers run their own instance on their own infrastructure and they should be able to use GitLab to its fullest as well. So we make sure they can use GitLab Runner no matter what or where.

We just want to build a great product. That means fixing bugs and regressions is among our highest priorities, together with building features that our users want and need.

Some of those features will land in our Enterprise Editions, of course. But many others will go towards improving Community Edition.

Ultimately, we want that anyone that uses GitLab can ship cool stuff, quickly and easily. Independent of which version you use. If you are a big organisation or have similar needs, that'll be easier with Enterprise Edition. But we never choose between fixing bugs and introducing more features. If GitLab was full of bugs every release, there wouldn't be a point for building new features!

With GitLab you can actually go from idea all the way to production, quickly and easily. You don't need to set up and use external integrations and have a powerful issue tracker, CI/CD, wikis, and much more.

For instance, to deploy and monitor a simple app, all you have to do is enable AutoDevops in your project and GitLab will take care of the rest. It's very powerful, see the video here: about.gitlab.com/2017/09/22/gitlab-10-0-released

If you still want to use your own tools, like JIRA, GitLab integrates really well with them. And lastly, GitLab is improving every single month with large jumps. We just renewed our navigation and it's now super easy and quick to jump between your projects and groups.

Of course that strongly depends on the role someone is applying for, but as a remote company there are a few characteristics that help a lot:

• ability to work independently: depending on how you organise your time, you might be spending a lot of time working by yourself and having to make decisions without getting direct answers from other people.
• great communication/writing skills: you'll be writing a lot! Anything that isn't written down gets lost between timezones and the absence of an office. Great writing skills make that you can easily translate your thoughts into words.

We're hiring for a lot of roles and each role has an elaborate job description. Feel free to have a look and apply if you're interested in a particular role: https://about.gitlab.com/jobs/

GitHub is responsible for making Git the version control system of choice, if they'd be MercurialHub, maybe we'd all be using that now instead.

We actually hosted the GitLab repository on GitHub.com before we created GitLab.com, so we're happy that GitHub exists!

There is no animosity between GL, GH, BB. We often see each other on conferences and even appear on each other's conferences occasionally. I'm super happy to work in an industry where competitors can treat each other with such respect.

We use GitLab for almost everything, but also use:

• Calendly to schedule meetings
• the Google suite of tools
• Slack
• Zoom for meetings and webcasts

We have no choice but to deal with timezones daily, so we make it work. Working asynchronously makes that you don't need to have everyone present in every meeting, so we often have meetings that work for maybe 2/3 of the world (morning in place A, end of day in place B) and make sure whomever can't attend knows where to read up.

Through any channel we have and with a combination of intuition, research and experience.

On of our UX'ers wrote a long article on how we redesigned the navigation, there's a lot more there: about.gitlab.com/2017/07/17/redesigning-gitlabs-n…

It's not a smart move on our part to charge you per-feature, because that makes it hard to create an integrate experience and give you powers you never knew you needed! We might introduce per-X billing in the future for pipeline minutes or additional storage.

Yes, I do hope to bring code owners to GitLab in the near future! I don't think we'll ship it this year, but I can imagine it somewhere next year. Issue for it here: gitlab.com/gitlab-org/gitlab-ee/issues/1012

GitLab.com is not stable enough yet, but we're working hard on improving that. Most of our customers run GitLab on their own infrastructure, where this isn't a problem, as GitLab.com is several factors larger than any customers' instance.

Trying to give off the impression that your service is reliable while it's clearly not is not inspiring confidence. It's better to be transparent and communicate what you're doing to resolve the issues with reliability.

I'd say it's working out really well. We've been building new things in Vue and slowly replacing existing components with Vue. It has allowed us to iterate faster and reuse more.

One of our FE engineers gave a talk about how we use Vue recently, it also links to a whole bunch of other things we've written about it. Check it out here: about.gitlab.com/2017/06/29/gitlab-at-vue-conf

Interesting question! I think any piece of critical infrastructure should be either resilient against failures or easily brought up again.

In practice, I wonder if anyone does this against their test instance. In my experience, test instances are brought down involuntary frequently enough that people are comfortable bringing it up again 😅

I do think it's important that every environment is well-instrumented and alerts go out if anything is off.

I think there are two tricks to making it work:

1. Working asynchronously: write everything down and avoid creating bottlenecks. You want everyone to always be able to continue with their work. So if you write everything down (such as we do in our handbook at about.gitlab.com/handbook), people can consult that instead of having to rely of tribal knowledge.

2. Realizing that working remotely requires work: It's a very different way of working and you have to actively think about how to communicate, how to build teams, etc. So instead of relying on those micro-communications you have when you're together in the office (e.g. 'watercooler talk'), you have to create opportunities to bond and share. Working remotely means not doing the exact same things but separated by more air, it means working differently so everyone can be more productive and have a more flexible life.

I wrote quite a bit about this, see also here: medium.com/@jobv/how-to-work-remotely-with-150-pe…

We believe that by building a product that allows everyone to easily and quickly build, test, deploy and monitor their applications, people will slowly move their open source work to GitLab.

We also realise that many people want the largest set of eyes on their open source work, so we allow you mirror your repositories between GitLab and GitHub automatically.

Lastly, we offer all our features (CE, EES, EEP) and completely free CI to all open source projects. That means you can use GitLab.com for any stage in building, testing and deploying any open source project.

1. If you need to store private projects, GitLab seems like a good place to do so (unlimited private projects)
2. If you want fully integrated development. Code hosting, build docker image, store it, test code, deploy it etc.

We still have the long road ahead to achieve good visibility in sense of public projects compared to GitHub. But it's getting better year over year.

If still in doubt - you can do development on one platform and mirror to another (GitLab.com has nice mirror feature) to achieve both rich functionality and public visibility.

I think being open is the most user-friendly thing you can do. Now your users can hold you accountable. It forces you to be honest at all times, treat your users more fairly and when you do - you find that your users are more understanding and helpful as well.

Not many companies are transparent, but if you are in the position to be more open with your own company, I think that can be a unique advantage.