121–130 of 230 posts
I'm a little surprised by all of the anti-VC sentiment in this thread so far, especially from this community. I'm perhaps even more surprised by the "what do they need 100 million dollars" sentiment that is being floated around. Github is an impressive company that has, so far, blown away its competition in many aspects. The fact that they have been self-bootstrapped up until this point and that they are profitable t…
GitHub is essentially a web interface to a single open-source DVCS. The switching costs to using another DVCS such as Mercurial (which I personally prefer) or another Git hosting provider are minimal. There are no barriers to entry since Git is and always will be free. There are very few network effect benefits to using GitHub for paying customers who by definition want to keep their code private.
GitHub is a good service and I use it myself, but I'm now increasingly cautious about using it since GitHub are now under serious pressure to deliver pretty spectacular returns to their investors.
In the end I think this investment has less to do with GitHub and more to do with the fact that e.g. yields on 10-year Treasuries are currently under 2%. Investors are desperately looking for any decent returns on their money and throwing it a company like GitHub is just a Hail Mary pass.
Earlier quoted context omitted.
Probably makes it easier for them to sell the company to bigco for $1bn.
I believe that this is the correct answer.
Earlier quoted context omitted.
TPW (or some early GH employee) has posted somewhere that yes, the cost of servers on your own is cheaper. However, the original goal of GitHub was to build a tool that allowed collaboration easier. You pay for the experience and the tools and the network IMO.
Ah, gotcha. I guess I was missing out on the social aspect of it. But I have to wonder: if you're hosting that many private repos...how much does "social" play into it?
I have to imagine that a chunk of that money is to provide liquidity to the founders, which they very much deserve. I don't really see how this is a bad thing. They were very much profitable, and were likely able to dictate the terms of the deal. Also, the money came from one of the most, if not THE most, reputable and respected VC firms.
That helps explain why the founders sold the equity, but not why the VCs bought it.
Damn, github seemed like the perfect model for bootstrapped, they were growing like a weed, seemed to not lack for money from income, etc. In these situations, I'd really love to know the details-- did they go shopping for investment (love to see that deck!) or did A19Z pursue them and talk them into it? Probably perfect timing, too, because I think things are going to cool down in 2013. Anyway, couldn't happen to a…
Earlier quoted context omitted.
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 th…
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)
- diffying & merging non-text document types (images, audio, spreadsheets)
I agree this would be a valuable problem to solve well!