Okay, Atlassian, we get it. You think that GitHub is your biggest competitor. You're worried about the idea of source control being the focal point of developer productivity, because it makes issue tracking a secondary feature, and not a primary ure. And this threatens your biggest product, Jira, which is already kind of a mess to configure for source control. It's the reason why you want to own BitBucket and directly compete with Git, and it's the reason why you're adding this to your ecosystem -- so that you can own these aspects customers' projects. Customers who need source control hosting first would start with BitBucket, and customers who need it after they've project-managed and roadmapped everything in advance would realize late in the game that they need something like Stash.
It seems like trying to capture every kind of use case with a smattering of different products will ultimately be Atlassian's undoing. Yeah, you capture more of the market in total by taking this approach, but it also means that you have to maintain additional products, many of which are at odds with each other. There are so many technology businesses failed that tried to be "everything to everybody" that it's not even worth getting into here. I think they're better off identifying a strong, unified voice and promoting a single right way to handle end-to-end software productivity. But if it works for them, whatever.
I get what you are saying, and your analysis might be correct, but I actually think their strategy is right on.
Don't forget Atlassian's market is 'enterprise', this means people who like their products to be supported from a 'total solution' vendor... i.e. someone to hold their hand through integration problems, etc.
For all the 'difficult to configure' (which is true), Atlassian products do get the job done, and in a very enterprise friendly way.
I'm not affiliated with the company, but I have met both Mike and Scott, and I have no doubt they have a good hand on the tiller. These guys are engineers and don't do anything without testing a hypothesis first.
Don't forget that their software is notoriously convoluted and buggy as hell. The wider they spread themselves the less effort and time seems to be going into their product.
As a current Jira user and customer, I find this announcement and the idea that they've been working on this really annoying. There are already way too many products in the Atlassian ecosystem, and the Jira product offering is like a cautionary tale for all aspiring enterprise software systems out there - slow, big, ugly, very customisable, but really tedious. I wish they would just focus on Jira, cede this idea of source control software to Github (which already has a firewall product, most people don't know this) and make everything work together really well.
There is also a nice price delta between the two. Stash is $9000 (currently) for 500 users/yr. GitHub Enterprise is $125,000 for 500 users/yr. That might win over some
Disclaimer: I work in the game industry. In the last few years I've worked on projects with Valve, EA, Blizzard, Bungie, Infinity Ward, Treyarch, id, NCSoft, etc... the list goes on and on. They all use Perforce.
Perforce is double the cost of GitHub Enterprise, at $350,000 for 500 users/yr, including their (amazing) support for when the server wont restart in the middle of the night after routine maintenance.
Regardless of how sweet their support staff is, P4 has relatively painful branching, so all of these companies who have multiple teams developing on separate branches (fairly common in companies who outsource large chunks of work), an entire engineer is dedicated to concocting epic change lists for a week at a time every time you want to merge.
GitHub Enterprise could make that issue a bit more bearable for engineers (binary files get checked in regularly, but rarely are two people branching the same binary that would need merging later) and save a nice chunk of money.
Developers would probably enjoy using a DVCS and apparently don't mind loosing an entire guy who is doing merges all day, while artists, designers, and other not-so-technical folks who also contribute to the repo would have a hard time migrating from a workflow that is ingrained from internship onward. Tech-heavy companies and those who develop solely on Mac or iOS are the rare exception.
A big problem is that Git has no concept of what Perforce calls "exclusive checkout" where only one person can claim and file and work on it. That's a deal breaker for most. Communication is hard. Make it apparent that someone has claimed a file.
Retraining users from Perforce to GitHub (however enlightened that may be) has a real cost. I would estimate thousands of dollars per employee in lost productivity. Gotta make way, way easier to start working in the git workflow, especially on Windows. All game console development happens on Windows.
Fixing the issues above could crack the entertainment industry nut (and probably many others) and likely reap some nice rewards for other groups who can't afford to switch.
> A big problem is that Git has no concept of what Perforce calls "exclusive checkout" where only one person can claim and file and work on it. That's a deal breaker for most. Communication is hard. Make it apparent that someone has claimed a file.
Is this a problem particularly in the games industry for some reason? Because in "regular" development, people always think it'll be a problem before they try it. Turns out not to be, especially with the great merge support you get from git.
I could see it being an issue for binaries though. If anything, I'd expect people to balk at having to clone the entire history of large binary files, which don't typically delta-compress very well.
Realistically, I'd be surprised if that difference was more than a rounding error for any organization with 500 active developers. $21/month/user is essentially nothing.
In most the big orgs I have been with, price was not the deciding factor, but rather a host of other considerations. That being said if two product where identical in feature's and ease of use, you can guarantee that a significant cheaper product will get further consideration, price is a factor it's just not usually the top factor in big orgs. In a previous life I was an executive at some fairly large companies and personally had 20-30 mil budgets and I can say that at least in the orgs I was with, something 100k+ would get some scrutiny along with some questions as to whether there was a equivalent cheaper product. In many org's purchases over a certain threshold have to be vetted. I know the ones I was with where well south of 100k.
It's $250/person/year. Yes, it's probably a rounding error when you're talking about folks who, with salary and benefits, are almost certainly costing the company $100k+/person/year.
For the software, yes, but then you have to host it and maintain the server it's on. Sure that's not going to be much, but it's still something to consider.
Why cede the self-hosted source control market to Github if, as you say, most people don't know Github has a presence there? If that's the case, this sounds like a great time for them to enter this market.
Why cede hosting to GitHub when you want to ensure tight integration to your other products? If your customer is already spending money with you and needs to host their repos internally, you should take their money.
Exactly. I love GitHub, but they are a bit pricey. If I can get a professional tool for $10 (I have between 1-5 developers) rather than $25 a month, I'm there.
Except they also have confluence,crucible, and fisheye, which is very useful for my organization because we can't force everyone to be on git, and we have tons of people on subversion and cvs too, some who want to play around with mercurial and people on git too, in addition to using crowd/jira/confluence currently. No other company that I know of offers that many solutions, and it's a shame you think atlassian should only focus on jira, because everything already works together really well.
Also, Atlassian is battling github on an entirely different front using bitbucket.
You're making my point for me. It's just ridiculous that all those products exist, and now +1 more product we won't use. We use github, and yes I know not everyone uses git, but the integration there is just painful. Just to get anything working is a chore. Fisheye has become worse and worse over the years and it's easy to see why - because the company just doesn't care about taking the time to make anything work really really well.
Except that it works fine for my organization, and we do use all of those tools. We use jira and confluence for everything, and the majority of the users of those products aren't explicitly software developers even though most of them can code. We're going to use fisheye because it's getting ridiculous to have multiple web servers use ViewVC for CVS and Sventon for subversion and nothing for local git repositories right now.
The last organization I worked at used a combination of mediawiki, sharepoint, VersionOne, and software from Seapine (Test Track, and Surround SCM), in addition to unofficial git repos on people's machines, and Windows Active directory for LDAP stuff.
It was horrible because we had to use it.
Maybe for small organizations their products don't make much sense, but on the enterprise scale they're much better than the alternatives.
The maintenance contract is another $10 for the next year (assuming you're still < 5 people). And you get software updates during that period. It's not particularly devious.
Gerrit (http://code.google.com/p/gerrit/) addresses some of the same problem space and comes with an awesome code review system. It also has one of the world's strangest access control systems. But it works and it's free, and the code review makes it all worth it.
It seems like trying to capture every kind of use case with a smattering of different products will ultimately be Atlassian's undoing. Yeah, you capture more of the market in total by taking this approach, but it also means that you have to maintain additional products, many of which are at odds with each other. There are so many technology businesses failed that tried to be "everything to everybody" that it's not even worth getting into here. I think they're better off identifying a strong, unified voice and promoting a single right way to handle end-to-end software productivity. But if it works for them, whatever.