I hate to crash the party, but this is a very odd move for an awesome company and a service that I use and <3.
Github has always been against taking money. Actually, TPW has used some very harsh words criticizing startups that choose to take VC money.
Now, Github raises 100 gazillion dollars? How the f*ck do they plan on spending that wisely? Sure, it's nice to have that sum in the bank. But, in all honesty, someone has to explain how this is a reasonable move, because I simply don't get it.
> The ironic thing about bootstrapping and venture capital is that once you demonstrate some success, investors will come to YOU. When this happens you will be in a much better place to make a more reasoned choice about taking on additional capital and all the complexities that come with it. Talking to VCs with some leverage in your back pocket is an entirely different game from throwing yourself in front of a conference table full of general partners and trying to persuade them that you're worth their time and money. Power is happiness.
I don't see any inconsistency whatsoever between the post you link to and what just happened. Tom was clearly talking about early funding, essentially when you just started, and how that can affect your product and its future. The fact that they raised that much actually proves Tom's point: That you should approach VC money from a strong position, which you can't reach if you start off with VCs watching over you.
Update: This post (Above for the moment) says it better.
yes I indeed did misread your comment. Sorry about that! I read a couple of threads here and there and the number of comments raising this issue was increasing, so my eye only caught the inconsistency part of it. Sorry again.
1) Burn the ships
By committing so strongly to an anti-VC ideology, they forced themselves to focus on profitability. They required themselves to make a sustainable company without the expectations that eventually someone would expand their runway. In the process, they created a very attractive investment opportunity for the trillions of dollars out there sitting on the sidelines looking for the next big thing.
2) Everything has a price
Don't consider this a strike against the github folks, I'm sure they are strong and ethical people, but everything has its price. $100 Million is a lot of money and I'm sure it left the founders with a lot of peace-of-mind that will allow them to focus on building an IPO worthy company.
They haven't done anything immoral and no one gets hurt, rather many people may greatly benefit from this move. They changed their mind like everyone in the world does in the face of smaller sums of money than this.
After all instagram did something very similar, used VC investment to boost sale price. And it seemed to work very well. Can we expect some surprise news from github? I don't know, but that can sure be one valid reason for raising such money which they clearly don't need to work on the product in it's current form.
And that probably explains the anti-VC sentiment. In multi-level marketing (MLM) pyramids, there's a "business" which serves as an investment vehicle for the money to trickle-up: energy juice, women's cosmetics, etc. A cynic sees startups serving the same purpose for VC. Announcements of funding are publicity stunts to pump up the valuation and then dump it in an "exit". The main difference between now and the late 90's, as far as I can tell, is that insiders sell their shares on SecondShare during later rounds, instead of waiting for an IPO to sell them on NASDAQ.
Maybe they're building their own data center? Or really trying to expand into the enterprise market by going up head to head with Atlassian (expanding their issues and Wiki tools to complete separate packages). All speculation, of course.
They specifically said they are raising this round for their enterprise product. Having the backing of top tier VC gives them more validity within the enterprise. That's probably the main reason. I doubt they needed the money. Very happy for them. The talented team they are building is unstoppable.
Pixar uses Perforce. Over 1000 users, 12 million ops/day, 40 million changelists, 115 million files, >20 TB data, and accessed by 12,000 cpu renderfarm. If you're dealing with large amounts of binary data it's basically a solved problem and Perforce is the answer. An expensive answer but an answer.
Just curious, what makes you think they don't already use version control prolifically? What opportunity do you see? One studio I'm familiar with has some assets with change history back through to SCCS -- back through RCS, CVS, and P4. These places have long dealt with large groups of people collaborating on shared files that are constantly changing, forking, merging, etc.
I'm sure lots of bigger places do use it. In the world of music, there are studios everywhere that have maybe a dozen staff, making a lot of money and producing a lot of output, where version control is an unheard of concept. No audio production software that I'm aware of has any provision for version control.
I was kindof assuming that it would be the same for mid to smaller sized movie/tv studios as well, but at the same time I wouldn't be surprised to learn that you can get a plugin for Premier or whatever that does it.
I know for a fact that there are many largish advertising agencies out there who have fileservers with hundreds of ProjectName01, ProjectName02 etc style directories.
Why do you think apple brought "Versions" or whatever its called in with lion?
I use Sequoia (http://pro.magix.com/en/sequoia/overview.527.html) and I'm very happy with the 'Save Project Copy' function. When I start a new project, I create a 'history' folder and the project copies go in there, named as project_name-timestamp.VIP. I do that every time I'm a stopping point, much like how I use 'git commit' on a code project.
That doesn't mean there isn't huge room for improvement in this arena. An approach like this (or OSX's versions) doesn't allow you to do anything like 'git diff' to see what's changed from version to version. I can imagine this is a very difficult problem for binary data, however. Also, distributed version control on media production software could allow for multiple users to be editing a project simultaneously.
Unfortunately, I don't really see GitHub being able to help much here. For example, any work done to make ProTools files git-friendly wouldn't also work on Photoshop files. I'd love to be wrong about this, but I suspect seeing version control in media production software would require redesigning the application's file format from the ground up, and would be a task for each software company to do on their own.
Thanks for clarifying. I agree there are many environments that would benefit from version control but that lack the technical resources to make it happen with existing tech.
Versions (and Time Machine history) are good steps to part of this, in that they are easily available and understandable, but they don't solve the collaboration aspect. How do you diff and merge your local changes into the NEW_final_v2_UPDATED.xls that was emailed to you? I'd summarize the problems as:
- identfying & organizing versions of the same document in ways manageable by normal humans (i.e. not a set of variably-named files spanning email attachments and shared folders, nor a graph of nodes identified by 20-byte hashes, nor a rigid interface to a versioned-file server)
I've worked quite a bit in the cgi and 3D graphics side of the industry and at least from what I've seen there the use of version control is lacking to say the least. The de-facto industry standard seems to be a directory full of files with names like scene_latest3_newest_old2.max.
Although it also seems to be more of a cultural issue. There are already pretty good tools from companies like Perforce and Alienbrain, the problem is to convince the artists that there is value in using them. Every time I've suggested it, there has been imitiate pushback and outright rejection from the artists. Even in the places I've seen that use Perforce, most artists seem to see checking in and out as a pointless chore, rather than a vital and helpful part of their workflow
I'm guessing they're working with file formats that can't be diffed or merged. In which case all the version control is doing is just storing the file. Branching, forking or collaboration isn't possible in the way it is with text code.
In that case it really doesn't benefit them at all and is a chore. You'll only get them to use version control if it's hard mandate (good luck) or figure out a way to make it completely transparent to them (something like Time Machine).
The movie studios are not so open with software, but almost all of them do use open source software in some way, and most certainly nearly all have developers that use some varying amount of version control.
Not just movie/music studios. Who could reap huge rewards from great distributed version control? Anyone who collaborates on some computer file regularly.
So everyone. Or at least everyone who works in an office.
My own erstwhile field of small business accounting is all about version control. An enormous amount of energy goes into keeping tabs on which file is most current and ensuring that work isn't done in a non-current file.
Same thing for anyone who regularly collaborates on documents or spreadsheets or images: lawyers, advertisers, my friend the outdoor school counselor, journalists, etc.
The state of the art here isn't very good. For all the products out there, I'd guess 90% of actual version control happens via emails. Case in point:
A journalist friend of mine is currently attempting a small intra-office coup to switch from Email/Excel to Asana for scheduling and managing the editing process. It is not going well. Email/Excel will probably win.
But the old people won't be around forever. The opportunities to improve on the state of the art are vast. The amount of energy people spend on keeping current could be dramatically reduced.
thingverse is a pretty popular free distribution channel for 3d-printable objects - but there's no way to integrate forks. So people copy an object & improve it, but there's no way to put that fix back into the main line.
Getting these people to use github would be awesome!