Tuesday, November 15, 2011

John Gruber Has Some Career Advice For Developers

(33:45-35:53 from John Gruber's keynote speech at The Çingleton Symposium, a conference which took place in Montréal on October 14th and 15th, 2011)
One simple way to look at it is that there are far more people who've never bought an iPhone and who've never bought an iPad, who will in the next five years than all of us who've already bought at least one to this point. And I don't see how anybody can deny that, unless something unbelievable, dramatic changes. That's certainly the way everything is going now. If you think this app store platform is big now, you really haven't seen anything yet. At an event last week, Tim Cook had a line - he said, 'This is an extraordinary time to be at Apple'. And He is definitely right. But I say to you, 'This is an extraordinary time to be an Apple developer' .This is the right time and the right place. This is a once in a career opportunity. This is like being a Rock and roll musician in the late sixties. This is like being a film maker in the seventies following Scorsese, Coppola, Steven Spielberg, George Lucas (when he was sane). If things go right, if things go the way I think they are going to go, these next five years, we are never going to work harder, we are never going to be under more pressure, we're never going to be more stressed, we are never going to feel like we have to work faster and we are never going to have to solve tougher problems. We're never going to have to move this fast. But the only thing any of us are going to regret is if we don't aim big enough. If you don't feel that you're now in a position to do the best work of your entire career, to look back and say, 'This was the time, I was there, I did this, I helped make this thing a reality', then you need to find a new position. This chance will never come again. And we are lucky, we're so unbelievably, incredibly lucky that it even came this once. Thank You.

Sunday, April 17, 2011

Is A GitHub Fork A Real Fork ?

Karl Fogel, who was most notably involved with the development of CVS & Subversion and is a director of the Open Source Initiative (OSI), makes an interesting observation about Github's usage of the term "fork" in an interview:
Actually, I think the notion of forking has not changed -- there has been some terminological shift, perhaps, but no conceptual shift.

When I look at the dynamics of how open source projects work, I don't see huge differences based on what forge the project is using. GitHub has a terrific product, but they also have terrific marketing, and they've promoted this idea of projects inviting users to "fork me on GitHub", meaning essentially "make a copy of me that you can work with".

But even though there is a limited technical sense in which a copy of a git-based project is in theory a "fork", in practice it is not a fork -- because the concept of a fork is fundamentally political, not technical.

To fork a project, in the old sense, meant to raise up a flag saying "We think this project has been going in the wrong direction, and we are going to take a copy of it and develop it in the right direction -- everyone who agrees, come over and join us!" And then the two projects might compete for developer attention, and for users, and perhaps for money, and maybe eventually one would win out. Or sometimes they'd merge back together. Either way, the process was a political one: it was about gaining adherents.

That dynamic still exists, and it still happens all the time. So if we start to use the word "fork" to mean something else, that's fine, but it doesn't change anything about reality, it just changes the words we use to describe reality.

GitHub started using "fork" to mean "create a workable copy". Now, it's true that the copy has a nice ability to diverge and remerge with the original on which it was based -- this is a feature of git and of all decentralized version control systems. And it's true that divergence and "remergence" is harder with centralized version control systems, like Subversion and CVS. But all these Git forks are not "forks" in the real sense. Most of the time, when a developer makes a git copy and does some work in it, she is hoping that her work will eventually be merged back into the master copy. When I say "master" copy, I don't mean "master" in some technical sense, I mean it exactly in the political sense: the master copy is the copy that has the most users following it.

So I think these features of Git and of GitHub are great, and I enjoy using them, but there is nothing revolutionary going on here. There may be a terminology shift, but the actual dynamics of open source projects are the same: most developers make a big effort to get their changes into the core distribution, because they do not want the effort of maintaining there changes independently. Even though Git somewhat reduces the overhead of maintaining an independent set of changes, it certainly does not reduce it so much that it is no longer a factor. Smart developers form communities and try to keep the codebase unified, because that's the best way to work. That is not going to change.