11–20 of 159 posts
GitHub has to have revenue to continue to operate. I'd rather GitHub go down the road of enterprise and other paid contracts, rather than going down the road of becoming SourceForge and all the ickiness that that entailed.
Why would someone (specifically a large enterprise) outsource source control? Running a local svn or git server is fairly trivial.
But yeah, I'd rather run GitLab.
Why would someone (specifically a large enterprise) outsource source control? Running a local svn or git server is fairly trivial.
I don't understand why this is an issue for the current employees. Surely you hire a bunch of sales people and a bunch of consultants to help with on-boarding/support and place them in a separate floor or building. They don't really need to interact with developers. The 'brogrammers' just carry on as normal and some of their work is now adding features to help support enterprise requirements. Unless your sitting a co…
Enterprise sales people can make a habit of selling things that the product can't currently do, and then forcing engineering to make it a reality on a compressed timeline because "this is a deal we can't afford to lose." Repeatedly. No idea if that's happeing at GitHub, but I've seen it happen a few other places, and it sucks for the engineering and product teams even if the sales people are in a different state. In…
Maybe this is a trope from the 90s and 2000s or from a Scott Adams cartoon, but I disagree this is representative of most enterprise sales these days. Maybe I'm just spoiled, but every company I've worked at the past decade has had a knowledgeable sales force. I've been asked plenty of times, "can you add this feature for a huge customer?" and been able to say "no, that is not realistic for us to complete in a reasonable amount of time."
Why would someone (specifically a large enterprise) outsource source control? Running a local svn or git server is fairly trivial.
At GitLab we learned that indeed large enterprises don't outsource it, they run something (GitHub Enterprise, GitLab CE/EE, etc.) on-premises.
Okay, I guess that makes as much sense as anything really. I can see the advantage in something turnkey.
I don't understand why this is an issue for the current employees. Surely you hire a bunch of sales people and a bunch of consultants to help with on-boarding/support and place them in a separate floor or building. They don't really need to interact with developers. The 'brogrammers' just carry on as normal and some of their work is now adding features to help support enterprise requirements. Unless your sitting a co…
Enterprise sales people can make a habit of selling things that the product can't currently do, and then forcing engineering to make it a reality on a compressed timeline because "this is a deal we can't afford to lose." Repeatedly. No idea if that's happeing at GitHub, but I've seen it happen a few other places, and it sucks for the engineering and product teams even if the sales people are in a different state. In…
Their only real competitors were Bitbucket (which was originally Mercurial and was late to the git party) and Google Code (which was taken to pasture along with Wave and Reader). Bitbucket is not targeted at individual users. It is targeted at teams and companies. Atlassian has played in the small business/enterprise market for a while. As evidence by Atlassians "defeat" of FogBugz. http://movingfulcrum.com/why-fogbugz-lost-to-jira/ Google just kind of gave up on Google Code and closed the doors because it wasn't the biggest kid in the playroom.
Also the explosion of repo/package tools (Bundler, npm, cargo) and automation lead people towards browsing repos instead of static assets. Github provides a ton of tools to deploy to package managers like npm or PaaS's like Heroku dead easy. Github is not just a code repo, but a base for Continuous Deployment/Integration. "
Github would benifit from the platform route over the software route. A cloud based software repo isn't particularly special. A one stop for managing code, deploying software, working tickets, hosting docs, and more is special. Github has great tooling around pushes/commits but not issues/docs. Markdown is great if you're a browsing a repo, but isn't nice for non programmers. I would much prefer something like readthedocs.org integrated in.
Also github could look into offering services for enterprise customers. Github is fairly self service right now. They stand to make a fair amount of money charging for setting up deployments to AWS or Travis for you. Enterprise customers definitely overpay for simple stuff that could be done in an hour with proper docs.
Re: hiring & sales - on a semi tangential noet
Honestly, when I visited GH last year and met the very (few) women that worked there (they were all in marketing), (it was the UE4 workshop with like 3 women in attendance, great workshop, but I noticed more and more of the staff at happy hour (their bar) was filled with lots of marketing/sales people -- something I hadn't really experienced other times I visited, usually its more devs than those folks (marketing/sales).
https://www.theinformation.com/what-happened-at-github?token...
I don't understand why this is an issue for the current employees. Surely you hire a bunch of sales people and a bunch of consultants to help with on-boarding/support and place them in a separate floor or building. They don't really need to interact with developers. The 'brogrammers' just carry on as normal and some of their work is now adding features to help support enterprise requirements. Unless your sitting a co…
Enterprise sales people can make a habit of selling things that the product can't currently do, and then forcing engineering to make it a reality on a compressed timeline because "this is a deal we can't afford to lose." Repeatedly. No idea if that's happeing at GitHub, but I've seen it happen a few other places, and it sucks for the engineering and product teams even if the sales people are in a different state. In…
A million times this. I currently work at an enterprise software firm, and this is exactly what happens with each new client.
In addition to the compressed timelines and ridiculous feature requests that must be honored... in terms of the product itself, you have to do one of the following: 1) Maintain separate codebases for each client, or 2) Build the application so it can handle different features for each client, since each client will want different things.
Neither course of action is nearly as pleasant as having products that are the same for all customers.