GitHub Enterprise 2.0 (opens in new tab)

My only gripe w/ GHE is the lack of branch-based ACLs. If we want to implement a Github Flow (https://guides.github.com/introduction/flow/index.html) methodology, but also have automatic branch detection and testing in our CI (Jenkins/Bamboo/whatever), we end up having to assign all users the ability to create branches in the given repository (which, in turn, gives them the perms to push to master). I'm actually quite surprised that this hasn't been implemented yet in GHE; I can understand why GH wouldn't have it, but GHE (because of the nature of its user base) really should.

That issue aside, the UI in GHE is simply superior to GL and Stash.

The issue I have ALWAYS had with GHE isn't with GHE itself but with how organisations use it, there are usually dozens of organisations that make little sense and 1000's of repos that are often empty or abandoned. It becomes a black box of repos that no one really knows the ends of.

The real improvements GitHub could make to GHE is improve the discoverability experience, it's UI/UX is inherited from public Github where people work in small(ish) groups on single projects within individual orgs. This, for me, is not the paradigm people employ in GHE.

My major gripe with GitLab is that it's really hard to navigate around. There are lots of links that take you somewhere other than what you'd expect. The landing page for projects is the log, you have to click a tab to see README and file structure, which I've always found clunky.

EDIT: also, GitLab's syntax highlighter gets really confused if a search result snippet starts in the middle of a string. Never seen that problem on GitHub, but it could be there, too.

Just my 2c.

Currently, my startup is using GitLab. It does the job for the 16 or so developers we have. It has issue tracking, wiki, web hooks, merge requests. Pretty much all the same features as GitHub, but not as clean or pretty.

GHE is very social, GitLab never had that feel for me. Same feature set, really.

Ben Balter from GitHub's government team here. I'm sorry to hear we let you down. Please let us make it up to you. You (or anyone else) should feel free to reach out to me any time at government@github.com, and I'll personally help navigate the process.

For what it's worth, we care a lot about the experiences of all our users, whether you're a developer using the GitHub.com front end, a system administrator spinning up GitHub Enterprise, or a COTR procuring a license for your agency. I'm not part of the Sales team. In fact, my full-time job is to help empower those working to "fix/modernize gov't tech from the inside", and a big part of that over the past year or so has been seriously leveling up the user experience for government and other large enterprises.

To help here, we now have a dedicated government team (https://government.github.com) that makes sure our front-line sales reps and supportocats are conversant in "govspeak", a semi-private government peer group (https://github.com/government/welcome) to collaborate on best practices, and are streamlining the procurement process for government with invoicing and standardized contract vehicles (and now FedRAMP support as part of AWS). I'd love your input on how we can do better.

Similar feature set, but otherwise better in almost every way (and I don't work for Atlassian, just for the record). Some examples:

- Source code is provided when you purchase a license, and you have the right to modify it (just not distribute it). Whether or not Atlassian is still around in 10 years (they probably will be), you'll never be left in the cold with something you can't maintain, or bugs that can't be fixed.

- Pricing is up-front and non-discriminatory. The prices are listed publicly, and you can buy it on your Amex, right now, without ever speaking to a sales team (unless you want to).

- Distributed as an installable application, not an opaque VM like GitHub Enterprise, so you can provision it in any environment, not worry about out-of-date OS components, dealing with an opaque black box you can't administer directly, or any other similar issues.

- Extension API. You (very easily) can write extensions that hook into just about any aspect of Stash, without having to work with an external REST API (unless you want to — it has a REST API, too). Atlassian provides a built-in extension "app store" for both free and commercial extensions, and there are a lot of great free (and open source) extensions out there.

I find this to be pretty typical behavior when representing Government to vendors.

It doesn't impress me as being dismissive so much as indirect sales pressure.

A vendor knows that the typical Government agency can and does regularly piss away 10-100x that amount on systems that never see the light of day.

They're betting that if the initiative has any real support someone will find the funding to make it happen.

Problem is, this is probably worst possible tactic to take with someone in your position who is trying to enact change without substantial/any budget to command.

The people on your end are happy to walk away, they've already done it twice and they were surely just looking for a reason to do it a third time.

Word to salespeople working with Government:

When you're dealing with a lone "champion" inside some organization you should be thinking in terms of cheaply seeding for the future and having friendly eyes and ears inside - not booking a sale this quarter.

Also, as the OP points out, you're going to be dealing with entirely segregated procurement departments who are likely out of their comfort zone to be handling the task at all - not the sort you should be at all impatient, demanding or upselling with.

Now, to be fair I should point out that I think there are some valid reasons for vendors to avoid small deals.

The main thing is perception. The naysayers are going to attack any new installation the moment it hits the floor. If a minimal install isn't defensible against a hostile environment like that seeing it fail will kill any potential future business for the vendor.

A simple way to mitigate this is sign an agency up and leave them fully-featured and uncapped - no friction to grow the product internally. Then, this is important, resist the urge to demand a huge true-up once things have taken root, just ramp up gradually and understand that the social proof of your having your product fully-established in one such agency will open the door to sales elsewhere.

It's not like they're going to be exchanging tech stuff with your billing person, so not sure what issue you're referring to in your last sentences.

In order for GitHub to take away anything actionable from your example, they'd need more details on what issues actually occurred with the interaction.

Me saying "replaced" is a bit of a misnomer though because the way we create, maintain, and configure Enterprise is totally different now making Chef and Puppet overkill for our uses. We no longer try to maintain the state of the entire system throughout upgrades instead favoring placing a complete system (built using mostly bash and again a bit of ruby).

Since we only now need to change a few configs we can do that using bash and ruby. This resulted in huge speed ups when reconfiguring Enterprise.

It's hard to over emphasize how much of the underlying way that Enterprise was put together changed and was improved with this release. Everything from developing on it, to releasing it, to deploying it, to upgrading it has all been shifted.

Huge respect to the infrastructure folks that made this happen (certainly made my life easier as a dev!).

We've been using Stash (and Jira, Confluence, etc..) pretty happily. GitHub is great, but the $$$ is just too much, and the Atlasssian ecosystem integrates nicely.