Over a year I started the process of convincing the people I needed to at my job (Federal, Non Defense/Law Enforcement) to get an instance of Github Enterprise installed. Though it took a lot of time and effort, I managed to get both the approval and funds needed for a small scale - 10 user - install (on my 3rd try, gov't is really against change).
Our current "enterprise" VCS is PVCS (so old I had to look it up). The idea was to get github installed on a small scale, gain support and extend it to the entire agency over the course of a couple years. Everyone who deals with PVCS wants git, but the management don't care to put in the effort to get it initially, so gaining the support would be easy.
A couple months ago, the entire thing collapsed on my face and we went with gitlab instead. Why? Because github's sales team f*ed it up. Apparently, the $5k minimum order was too small for them to care (at least that's what my side says). Too bad, I really wanted to get them in the door.
I'm sure it's just a bad egg in the sales, but seriously there are some people trying to fix/modernize gov't tech from the inside and thing's like this don't help. I guess my only recommendation is that if your company usually sells to private and the gov't asks for a small-sized purchase please be flexible. The guy who caused this request to happen has likely been putting in a huge amount of effort and has larger plans for integrating your service over time. The person who is contacting you is not that guy, has no idea what your product (or any tech) is/why it matters and is usually doing the originator a favor.
> A couple months ago, the entire thing collapsed on my face and we went with gitlab instead. Why? Because github's sales team f*ed it up. Apparently, the $5k minimum order was too small for them to care (at least that's what my side says). Too bad, I really wanted to get them in the door.
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.
This is all really great to hear, I've already begun the process of restarting the engine. It will likely take me 3-6 months just to get the momentum needed to reach out again officially. Oh the gov't...
> I'd love your input on how we can do better.
As I'm not in procurement and don't want to make assumptions about how your shop is run I don't have any comments of merit/meaning beyond my previous ones & saying an honest thanks for your reply and I hope that I can get my guys to reach out to you sometime next year.
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.
>"Apparently, the $5k minimum order was too small for them to care (at least that's what my side says)."
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.
Having previously used a single seat-pack deployment (the aforementioned $5k minimum order), and having sent a fairly substantial amount of questions/requests to GitHub's enterprise support folks, I'm not sure what you mean by "too small for them to care".
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.
14.04 is too new. They probably started working on this long before 14.04 was finalized, and retooling would be expensive and slow them down. And even then, 14.04 is still rough around the edges--not all of the kinks have been discovered or fixed yet. 12.04 still has over three years of life left in it, which is much longer than the probable lifetime of GHE 2.0, and a future release of GHE can upgrade to 14.04 if and when that's necessary/beneficial.
So a stable release is too unstable for them? And now the first thing users will have to do is after install, apply all the bug fix packages to bring it to 14.04. But that will bring no unstability concerns? Or will they just not patch it and expose themselves to the bugs in the name of stability?
That's incorrect. The way you apply bug fixes to 12.04 LTS is by installing the bug fixes, not by moving to 14.04. The whole point is that 12.04 LTS continues to get updates for 5 years.
It's not that it's unstable in an absolute sense – but it is a migration if they started building this prior to 14.04 release (highly likely). And migrations are always time-consuming and risky, even if it's a migration to an otherwise stable platform.
I was part of the Ubuntu decision at GitHub, and it was based on the fact that Ubuntu gave you much longer support after the next release. Debian (at the time) only guaranteed even security updates on previous releases for one year after a new release.
Just wondering, not an attack: did you talk to the Debian project to see what resources (money or person-time) are needed to support a Debian release for a longer time?
I am asking, because Debian is a community project and in the end it gives what its community members are putting in. I am wondering about the amount of effort necessary.
It seems that they estimate it at one person, full time [1]. Which does not seem a lot, given the number of organizations that use Debian.
Why would they talk to anybody? Support decisions were already made (for a reason) for both releases. Trying to revise them and committing on '?' for an array of production servers is a horrible idea.
Exactly this. It would have seemed pretty presumptuous to ask the Debian project to change the support model that they decided worked for them to support us.
We were also faced with a very large new infrastructure build and we knew we were at the end of the line with Squeeze but Wheezy had't quite yet shipped, which put us in an awkward position.
Debian is a great distribution, but at the time we felt like Ubuntu was the right way to go given the existing support policies.
When I made the decision for my shop, we chose Ubuntu because of the guaranteed support cycle. Debian's support windows were too short, and we need to be able to plan years ahead of time for when we must spend the time to upgrade the OS. It takes a lot of testing and tweaking, and Debian didn't give us any certainty beyond a few months out. Ubuntu gives us a five year guarantee (and they've been sticking to that for six years now). That allows us to be a lot more confident about making plans for the next year or two.
Not even close:
"Debian-LTS will not be handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success (with some overlap in people involved)."
How is this different? Unless you know the security team personally, how does it matter which people does the job? It is still officially a Debian project, backed by those volunteers who does the job.
Because Debian doesn't provide enterprise support.
Let say that you've got a critical bug somewhere, do you really think you can tell your boss 'Yeah I asked on IRC / forums / mailing list to get an ETA'
It's very likely buried at the bottom of features since it's the thing that's likely to make some shy away even before they see all the good features.
Edit: In all honesty though, even though it does seem expensive, if you have 20 seats (20 developers), your payroll is already on the order of $1MM+, so $5k a year is almost a margin of error at that point, considering those devs use it all day every day.
It is significantly more expensive, especially for teams in the ~100+ range.
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.
Yeah, and the worst part is that GitHub doesn't even offer the same suite of services you get with the Atlassian ecosystem. It'd be one thing if it were a bit more expensive, but also included CI and a more full-fledged CMS like Confluence.
That said, ff they dropped the price, my team would switch in a heartbeat, because we use GitHub and Travis-CI for all our open source stuff.
Somewhat related, I just finished up the Splunk demo instance launcher on StackMonkey: https://www.stackmonkey.com/demo/splunk/. It would be interesting to be able to deploy GitHub Enterprise as a demo as well.
As someone who's used both Gitlab, Github Enterprise, and Stash in a corporate environment, I have to admit I prefer GHE, for the features it shares with core Github, if nothing else.
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.
I'm pretty sure GHE has the ability to disable pushing to the default branch (which is set on a per-project basis, but by default it's master). But I think this is a per-instance setting (unless that's been changed recently).
So while everyone would have the ability to push to other branches, they wouldn't be able to touch master outside of pull requests, which I think is what you want anyways.
GHE is (minus the things coming in this v2) the same as using public Github, so in my view is the superior experience to using GL (in most ways I can think of).
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.
I've never used GitHub Enterprise, but my experience with GitLab is not so great. If GHE is a beefed-up GitHub, it's probably much cleaner.
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.
Our experiences with GitLab have been really positive. GL may not be on par with GHE UX wise, but I don't really feel that this has been an issue for us. Coming from GH or GHE, GL is a little more difficult to navigate, but it's getting better with each release. The thing that probably bugs me the most is the home page for a repository being the activity stream. However, considering that we're saving $25k per year by using GL over GHE, I can happily put up with it.
I've never encountered the search issue you describe. We're using the latest GL, perhaps it was a problem with an older version?
Looks like we're still on 7.3.1. I don't see anything in the release notes for more recent versions about syntax highlighting, but they might have snuck something in, or it could be a dependent package change.
25k sure is a lot of money. Then again, can you put a price on the frustration of developers used to working with something better? Maybe.
25k is for 100 developers, and we actually have more users than that. GHE is really pricey. However, I don't hear complaints about GitLab, probably because everyone was coming from SVN, and they have little experience with GH.
Another one to compare it to is Atlassian Stash. It's not as full featured as GitHub but integrates really well with JIRA and Bamboo. It even has some features that GitHub doesn't, like ACLs on branches. It's significantly less expensive that GHE.
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 requires a lot more resources then GitLab (8GB/4cores min) and anything lower slows it to a crawl, which is a shame. Luckily there's now an AWS image which makes it significantly easier (deploying it now).
GHE is very social, GitLab never had that feel for me. Same feature set, really.
In my experience GitLab runs well on 1 core and 1 GB. Are you also deploying it on a 8GB amazon instance? How important are GHE's social features within an enterprise environment?
Expanding on what mikemcquaid and mtodd said, essentially it's been replaced with bash and a sprinkling of ruby (Mostly for templating, IIRC).
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!).
"GitHub Enterprise /.../ support for rendering PSD files will have your design teams jumping for joy."
I keep wondering how they do the PSD file rendering, sounds very intruiging. Is there a separate "thumbnail" automatically included in every PSD file or is GitHub doing a real PSD file rendering? In that case I wonder about font availability etc..
PSD files may contain a full resolution rendered (flat) bitmap for interoperability. It's probably enabled by default when saving. Other file formats like ODT and ORA contain a rendered thumbnail (e.g. 256x256) just for fast preview in file browsers. Scaling down a couple of 20000x20000 images in a folder is no joke, and that's not an unusual size for digital artists.
GitHub's tools always fell short for me. Phabricator is a much better code review tool (with a commandline workflows). Trello / JIRA are a lot faster and more flexible for issue management or sprint workflows.
Our current "enterprise" VCS is PVCS (so old I had to look it up). The idea was to get github installed on a small scale, gain support and extend it to the entire agency over the course of a couple years. Everyone who deals with PVCS wants git, but the management don't care to put in the effort to get it initially, so gaining the support would be easy.
A couple months ago, the entire thing collapsed on my face and we went with gitlab instead. Why? Because github's sales team f*ed it up. Apparently, the $5k minimum order was too small for them to care (at least that's what my side says). Too bad, I really wanted to get them in the door.
I'm sure it's just a bad egg in the sales, but seriously there are some people trying to fix/modernize gov't tech from the inside and thing's like this don't help. I guess my only recommendation is that if your company usually sells to private and the gov't asks for a small-sized purchase please be flexible. The guy who caused this request to happen has likely been putting in a huge amount of effort and has larger plans for integrating your service over time. The person who is contacting you is not that guy, has no idea what your product (or any tech) is/why it matters and is usually doing the originator a favor.