I've found it interesting how many people in the Bay Area, particularly veterans of the 90s boom, discount a lot of the ideas pushed by GitHub and 37signals. Anedotally, one of the common responses whenever I reference either company is, "Yeah, but how big is [GitHub|37signals], really?" It's actually somewhat surprising to me how consistently I've encountered this response (so consistent, it feels as if it was distributed like a political talking point). As mentioned in the slides, publicly announced funding definitely serves as a signal, and I haven't heard anyone say that about GitHub since then, though someone said it to me regarding 37signals within the past few months.
What I think it really has to do with is that GitHub seems to make an effort to hire doers, whereas many companies develop processes to deal with non-doers, eg, having staging servers so non-technical staff can check the work of "their" developers. Remote work also doesn't serve the interests of non-doers, since they want to Have Meetings and Make Decisions.
>> staging servers so non-technical staff can check the work of "their" developers
Surely staging servers have some other benefits? Maybe some teams consider running code on the production setup for the first time to be risky to their customers? Perhaps some teams have encountered differences between dev laptops and production servers, which run on different OS/memory/etc. combinations?
Short-lived staging environments (eg, a temporary clone of a production environment) certainly have a place, such as when making architectural changes, but these kinds of changes are generally not happening on a regular basis if you are making incremental changes and doing continuous deployment.
I'm sure that there are companies that have a valid engineering need for perpetual staging environments rather than feature flags, but I've seen absolutely no evidence that staging servers are commonly engineering driven. Certainly in every part of the web startup world I've had contact with or heard about, staging environments have consistently been for product QA in organizations with heavy-handed processes and/or product management by non-technical stakeholders.
Edit for the people responding: This is not about haphazardly pushing to production. You should familiarize yourselves with continuous integration (http://en.wikipedia.org/wiki/Continuous_integration) and the various deployment strategies of major web companies.
I'm a dev at a company and I pushed for us to have a staging environment _and_ QA. When I started at my current job, it was common practice to edit code in production, and there was no testing (automated, QA, anything).
In our case, having a staging server (which is really a prod server since it's used for some internal stuff) gives us a chance to check a few things:
1. The installer still installs everything properly.
2. The main website works
3. Web services work
We don't have any hard and fast rules about how long things sit on staging, but having a staging system is useful.
So there you have it, a staging environment driven by engineering.
You might want to do fewer, less frequent releases in order to provide training to end users. You might also want to do do fewer, less frequent releases in order to facilitate a marketing push centered around the release.
What really sets GitHub and to a lesser extent 37signals apart is that they are making a product for themselves. That's how they manage to only hire doers. They don't need marketing or usability testing or operations or acquisitions beyond what the doers provide because the feedback loop to the target market is near direct. That's not to say it's easy to do what they've done, but rather it's much less likely those principles could be held as the staple of companies in other markets where engineers and designers will not be as naturally adept at nailing product/market fit by themselves.
> I've found it interesting how many people in the Bay Area, particularly veterans of the 90s boom, discount a lot of the ideas pushed by GitHub and 37signals
Then you can imagine how many people outside of the Bay area do the same thing. I've worked at places where I (stupidly) suggested some of their principles as solutions to systemic problems that came up, assuming that everyone would be on the same page (I mean their ideas just make sense right?) ... no way. I've gotten laughed out of the room a couple of times, wised up and am now resigned to the fact that unless I start my own company or join the founding core of a startup, I'll never get to apply those kinds of ideas unless I work in the Bay
Don't give up so quickly. Sneaking in good ideas into companies is a skill that takes time to learn, and even when mastered takes patiences to exercise.
Whenever you hear about the number of repos, most of them are just forks. In fact, I've created many by accident because Github changed their UI so clicking the icon instantly starts a fork instead of asking for confirmation first. I guess it's good for bumping the numbers up when getting private equity investors interested (cynical, I know).
Security wise, meh. Why would anybody pay to put their closed-source proprietary code onto Github? More holes than a sieve with their Rails setup.
Ok, you want somewhere to stash some private repos, nothing confidential. So why would you pay for Github when you can use Bitbucket for unlimited private repos? Plenty of other providers too.
Their enterprise product? Expensive meh. Atlassian's enterprise Stash is shared/open source when you get a license. You can also just install Gitlab, Gitorious, etc. for free on your own servers.
Github fanboys get excited whenever a big name dumps some code onto Github, like when Linus copied the kernel code over, but it was just a dumping ground while they sorted out server problems of their own. Ubuntu uses Bazaar and Trac, Linux Kernel development uses git on their own servers, KDE is over at Gitorious. Heck, there are some people still using Darcs and SVN.
Github is popular but it's not essential unless crave social karma points and your name/handle in lights.
Sorry for the rant like writing, lots of thoughts above, but I just never saw what the big deal about Github was. A good business and a slick offering but it's not going to suddenly transform your software projects or your abilities as a programmer.
The big deal about GitHub is that they were in large part responsible for the current Open Source Renaissance we currently find ourselves in. Do you remember the world before? Where you would hunt for someone's private SVN repo on their personal site and email them patches, only to hope that something comes of your effort? Compare that with the world of today, where, if I'm using GitHub, I can submit a fix to a project I happen upon entirely from my web browser, if I wish. The maintainer is notified immediately, we can have a line-by-line discussion about the change, and then it can be merged - also entirely from the browser, if that's what you're into.
Introducing DVCS and the pull request model to the wider development world is the reason that the pace of OS software development has accelerated so much in the past half decade. Of course, GitHub did not invent git, but they made it easy to host your repositories, and once Rails migrated to GitHub, the rest of the Ruby world came with it - followed shortly thereafter by a sizable chunk of the wider web development community. If you use one of their many competitors, that's fine - but they wouldn't exist had it not been for GitHub. Remember that Bitbucket started out as a GitHub clone for Mercurial. Gitlab is unashamedly an OS clone of GitHub.
> More holes than a sieve with their Rails setup.
This is just unnecessary FUD. The GitHub and Rails teams have both been fast to deal with security issues as they are raised. Just because a security issue is well publicized, it does not mean that every other piece of software ever written does not have its own security issues.
Renaissance? Open source has never been less healthy. All the previous social constructs around properly documenting, testing, and releasing stable versions of your code have been swept away.
Instead we're faced with the constant churn of semi-functional code, users working in silos and then showing up with patches well after it's too late to give them direction, animated GIFs instead of careful engineering discussion.
Github optimized being lazy, and this was appealing, and in doing so they broke most of the technical and social structure that held together open source's ability to produce reliable, stable, well-documented software.
I've watched stable projects either wither and die or become commercialized, and now instead we live in a world of rolling mostly-broken hacked out releases (if there are releases at all), a confusion of forks (which one is the 'real' one?), while animated GIFs and "oh snap" responses permeate our bug trackers.
Since when were bureaucratized quality standards part of Open Source?
---
"GitHub optimized being lazy" -- translation: GitHub enabled more people to get involved with Open Source.
There are no-fewer quality-obsessed developers participating in the community as a result of GitHub. There are, however, a lot more people involved, and a lot more code being "churned". The suggestion that the community is suffering as a result is a dubious claim that you offer no real evidence for.
It sounds to me like you miss the "good old days" when the club was more exclusive.
> There are no-fewer quality-obsessed developers participating in the community as a result of GitHub.
There is natural attrition of participants in any project; what keeps (or kept) so-called "quality obsessed" developers in abundance were the social structures -- and social currency -- of the communities built around open source projects.
In exchange for stature, learning, and intangible satisfaction, contributors would learn project guidelines, interact with project members, learn to meet the required levels of quality, and over time be subsumed as committers and trusted members of the community. This approach sustained open source for roughly 20-25 years.
However, github's social network structure supplants the traditional communities, instead creating a wholly Github community in which the previous social construct (and social economy) can no longer truly thrive, and instead, the community and social focus is redirected and reinvested in Github itself.
The similarities to the reward mechanisms and value feedback mechanisms of social networks like Facebook are quite strong.
> It sounds to me like you miss the "good old days" when the club was more exclusive.
This seems to be a recurring theme; it sounds to me like justification for cognitive dissonance borne out of a situation where two choices exist:
1) Subscribe to the notion in which one would be a junior contributor in a broad pre-existing world of established engineers, or
2) Ignore the experienced engineers and create a community of self-evaluating peers, writing off the old model as "exclusive" rather than "experienced".
I expect the truth is found in-between those two poles, but reality has trended strongly towards number #2.
I never disagreed that the overall quality of the code has gone down; I meant to suggest that such an observation misses the point.
Open Source is now much more accessible, and I think that's a good thing.
It used to be that if you wanted to own a car, you needed to basically have the knowledge of a mechanic. Now any "idiot" can own and operate a car. Is that such a bad thing? Cars are for getting you from A to B, remember?
There is arguably more mediocre code out there in the public eye now, thanks to GitHub. Is this bad? I'm not sure. But don't tell me that GitHub has made it more difficult for you to make software of the same quality as the stuff from 20 years ago.
Furthermore, why do I need to "choose" one of the options you gave? I don't care if I'm "junior" or "senior".
TL;DR: I just want to get my work done like everybody else. It's a matter of practicality; not honor.
Then you missed out on an intelligent and frankly important critique. He managed to put in words what I have been thinking for a while. I was skeptical after the first two sentences too...
I disagree on both counts. Actually, I find the assertions in that post callous and destructive. This cathedral that the poster is referring to never existed. Open source has never been healthier, and Github is a very big part of the reason why.
The parent makes very salient points, I think you'd do we'll to understand rather than brush then away because they don't comport with the conventional echo chamber wisdom.
I suppose you might be right, but I definitely don't feel that way myself. If it wasn't for GitHub, I don't know if I would've made an effort to get involved with the projects I use. It's made it insanely simple to find a project, get documentation and a list of open issues in one place, with a consistent UI across projects. It's also been a pleasure committing fixes for projects I use - as mentioned above, being able to discuss the fix in a code review style environment, with the original author is hard to beat.
Projects I've published myself have been a breeze to maintain, because pull requests are really easy to manage. I can review changes with the submitters, pull the changes myself to tweak if I need to, and auto-merge when changes are simple enough. It also acts as a nice portfolio for potential employers.
I guess I feel like OS in general is benefiting from the likes of GitHub, not suffering. Just my two cents.
> Instead we're faced with the constant churn of semi-functional code, users working in silos and then showing up with patches well after it's too late to give them direction, animated GIFs instead of careful engineering discussion.
I've been paying attention to this stuff since around 1998, and except for the animated GIFs, this has always been the case. The difference is that we've had 15 years for the abandoned cruft to accumulate, and Google has gotten a lot better at finding it.
Circus? you could barely call it a sideshow.
I remember the glory days when we wrote perfect algorithms by hand and mailed them by post to each other. We called it Mathematics.
I've watched beautiful concepts come to life only to choke on the reality of bits.
It's very easy to be a part of the the problem when you're not contributing to a solution. It's also very easy to say a lot about nothing. I mean that in that you source no projects that have gone the way you described.
>Github optimized being lazy, and this was appealing, and in doing so they broke most of the technical and social structure that held together open source's ability to produce reliable, stable, well-documented software.
And yet, here we are, years after Github optimized being lazy and broke most of the technical and social structure of open source, and we still have hundreds of thousands of usable and awesome open source projects available to use and contribute to. The internet and the apps built on it still run just fine, people are getting more done with technology than ever before, and more people are getting their code out to the world than before Github.
I think that you're either overly cynical and negative, or you're upset because Github has taken away implicit social power you used to have or you're pissed off cause you have to deal with the plebs who use your obviously brilliant software in ways that aren't correct (i.e. ways you didn't think) then have the audacity to file bugs on it in ways that are wrong (i.e. ways you don't like).
1) The internet and the apps built on it still run just fine.
There is very little maintainership and investment in core difficult technology development. Most core projects that make up the foundation of the internet subsist on the oft-dwindling maintainership of what you seem to consider to be a legacy generation of engineers.
Outside of areas where companies hold direct commercial interest, many core technology projects are withering or stagnate. There are an infinite variety of new JavaScript frameworks, however.
2) Hundreds of thousands of usable and awesome open source projects available to use and contribute to
We're reinventing wheels at a prodigious pace, but your comment demonstrates and underlying shift in the opensource mindset that Github has invoked. Whereas open source was previously something to be produced as a stable, reliable entity, and consumed by users, it has instead become an expensive participatory process for all comers, in which stability and reliability and even documentation is discarded in favor of quick fixes and local patches and increased expenses for the entirety of the ecosystem.
3) More people are getting their code out to the world than before Github.
It's the conceit of every generation that they exceed the previous, but this statement (and the implication that this is due to Github's introduction) is simply not true.
> We're reinventing wheels at a prodigious pace[...]
What you see as waste, I see as valuable experience. In school, did you just read books and take tests? Or did you spend a lot of time solving problems that had already been solved, deriving equations you could have looked up, writing programs you could have downloaded...?
People learn by doing. You don't sit down and design the Next Big Language on your first try. You invent a lot of shitty, unoriginal little languages while simultaneously studying what's out there, and maybe eventually you get to the cutting edge where you can create something novel and better.
You're both arguing by anecdote here. It seems to me self-evident that Github has many more projects on it -- not just forks of existing projects, but original projects, period -- than its predecessors and competitors do. This just about definitionally implies that it has a lot more crap. While it would be hard to prove that Github has a higher percentage of crap on it than its predecessors and competitors, that's certainly plausible.
However, you're essentially taking it as a given that the absolute number of worthwhile projects has dropped thanks to GitHub. If there's convincing evidence of this, I'd honestly like to see it, along with a plausible theory as to why that would be the case. What does, for example, Sourceforge get right that GitHub doesn't? (At least from my anecdotal experience, Sourceforge is in fact full of under-documented, unfinished and effectively abandoned crap to more or less the same degree that GitHub is.)
> However, you're essentially taking it as a given that the absolute number of worthwhile projects has dropped thanks to GitHub.
Not just dropped -- they're drying up. I can only speak from anecdote (nobody has paid me to run a study), but while I've seen no dip in usage of my libraries, and I've seen my projects explode with half-baked forks on Github, I've seen mailing list participation and worthwhile code patch submissions drop to very nearly 0.
> What does, for example, Sourceforge get right that GitHub doesn't?
SourceForge essentially died out for modern projects upon the release of Google Code in 2006.
However, what (traditionally) SourceForge and Google Code did right -- and, what projects did in their own hosting for decades before and after that -- was place the project's community in the forefront, and the code in the background.
This meant that documentation, releases, mailing lists and other constituents of a vibrant community project were placed in the forefront, with the code being something that one worked on as part of the community.
By contrast, Github made projects secondary. The code was (originally) always attached to an individual account name. The primary project page was the code itself. Forks existed at the same namespace hierarchy as the projects they forked.
The result was that Github sucked community energy into Github itself, and in doing so, began to redefine the community social constructs in a way that allowed users to maximize social and personal rewards while minimizing work necessary to conform or participate in the project's community.
Although I disagree with almost everything you've said in this thread, I appreciate the different perspective and your points are certainly reasonable (ie. have given me something to think about). However, this:
>> 3) More people are getting their code out to the world than before Github.
> It's the conceit of every generation that they exceed the previous, but this statement (and the implication that this is due to Github's introduction) is simply not true.
has me scratching my head. I would have assumed "there are more people writing code now than five years ago" and "Github has enabled/encouraged/caused/what-have-you proportionately more programmers to publish their code" to both be true statements, leading to an obvious conclusion. What do you think I'm missing?
I think you're both looking at this the wrong way. The projects that "wither or stagnate"? Without Github, they likely wouldn't be publicly-accessible at all. The professionals will always produce professional code, the amateurs will always produce amateur code, and what Github did was to make the amateur code accessible. You can't make the amateur code into professional code, but that by no means translates to it being valueless. You just have to recognize it for what it is.
> A good business and a slick offering but it's not going to suddenly transform your software projects or your abilities as a programmer.
I'd wager a pretty penny that Github has exposed a few orders of magnitude more people to the actual source of open source software than its predecessor, SourceForge.
A few orders of magnitude? So at least 100x more? You might want to rethink that. sf.net gets more traffic today than github does. So, two orders of magnitude is most unlikely.
But most of the traffic to sf is just users downloading the software. If you were to look at the number of commits per day on sf v github, I wouldn't be surprised to see a x100 difference.
I don't know what's a valid source of traffic data but according to Compete you're absolutely right. I'm pretty surprised. It's also nice to see that their traffic has been trending upward.
Let me tell you about this great new invention called the internet! Even though it is still pretty new, it does actually have a quite large userbase!
I guess, soon people will forget that you can call other people without a conference service, and praise some conference service for its huge user base.
Well, git is a distributed VCS, so all you need in order to use it socially is the Internet. Just publish your fork on your machine (or just anywhere on the net) and anyone else connected to the Internet can pull it, github is simply superfluous for that, the Internet already connects everyone to everyone.
That's akin to saying you're part of a 'social network' by virtue of having your own homepage. Sure, everyone can come to your site to see your updates/pics/etc but it's not a fair comparison to the things Facebook/twitter/G+ provide.
No, you have a "social network" because of your social contacts, that doesn't need the Internet at all. Also, the internet consists of more than the Web - e-mail and IM are also fine tools for maintaining your social network over the Internet, for example.
Now, there may be functionality that those services provide that others currently do not, and I never disputed that. But the original argument was that somehow that little fenced garden had a large userbase.
Other than that, I am not sure I am interested in the surveillance, lock-in (potential), and manipulation possibility that FB/twitter/G+/github/whathaveyou "provide".
And G+ is worse because the thing with Facebook...I'm never FORCED to reveal my Facebook identity on the open web. G+ doesn't really give me that option.
Spotify was doing it when I tried to join. They apparently changed it later, to not require Facebook. But, you know, first impressions being what they are, I'll never be a subscriber. Trust is hard to recover once lost. Guess Google is going to find that out the hard way.
Oh, it works without FB again? I joined when it was new but never used it much (niche musical taste). When I tried to login again a few (4-12) months ago, it wanted to force me to use FB so I just started ignoring them altogether.
Of course we matter. After all, Google profits from trafficking our private lives. It's a company that manufactures sugar coated surveillance devices that seem so useful that we submit to them willingly. If we didn't matter, Google will have had nothing. After all, its power stems from our voluntary submission to its merciless watching eye.
In fact, the question is frightening. Are we, prisoners, afraid that our benevolent jailers no longer pay us enough attention? That they've lost their touch to slyly subdue us by painting the convincing illusion that they have our best interests in mind? Have the abusive guardians' charms lost their potency on their admiring wards?
Speaking of the Google analogy, I hope they do more with their acquisitions of Speaker Deck and gaug.es, as I can't recall a single feature being added or improved since their acquisitions.
Nop, it does not. They're walling their garden. Many thanks Mr Job.
Youtube comment only available if you're logged in for instance.
Actually, nothing that new here. They wanted to build the Google distributed "computer" since early on. Except some of us thought it would be open like the PC. It's now all closed like a Mac
I'm always skeptical when companies say they have "no managers" and are a completely flat organization with 100+ employees. I don't pretend to fully understand organizational theory, but I take it that at some point, there will be someone doing the "management" work. Whether that's someone with the title of ninja/hacker/product guy/project manager/director/CEO/BDFL
Works well until sh*t hits the fan and you need to cull teams or have a very angry customer.
The buck really does need to stop somewhere, it cannot be distributed.
Every other job I've had uses some sort of stressful review as part of the salary process. You get a good review, your raise is bigger; bad review, smaller raise. This seems like it works, but it actually doesn't.
What's the goal of a review? To provide feedback. Shouldn't you be interested in feedback so you can get better, not just so you can get paid more? If so, shouldn't you be getting it all the time, instead of twice a year?
What's the goal of a raise? To keep you from being effectively paid less (because the cost of living keeps going up), and to make sure you feel satisfied with how much money you're making. There's nothing in there about making sure some people feel less appreciated than others. So pick a percentage number, preferably one that's above COLA, and just give everybody that. If that's not enough, your base salary isn't enough.
Note that none of these goals overlap. Feedback and salary don't really have common goals. If you're trying to get people to do better work by dangling the salary carrot, you're taking away intrinsic motivation – see DHH on mixing open-source and money, he did a good job with this topic – and you'll end up with less performance and motivation, not more.
The main goal of raises isn't cost of living adjustments, but as a part of career progression.
If you're staying in a stable role and productivity, then you need COLA.
If you're improving, in time you become significantly more valuable both to the company and to outside market, so you deserve much larger compensation than back in the years when you were a fresh-out-of college newbie.
I don't think his reply runs contrary to your post, if you include the last part of that sentence:
> To keep you from being effectively paid less (because the cost of living keeps going up), and to make sure you feel satisfied with how much money you're making.
It does run contrary, given "pick a percentage number, preferably one that's above COLA, and just give everybody that" which explicitly doesn't (a) differentiate improvement from non-improvement; and (b) doesn't address significant salary increases due to professional growth and changing responsibilities.
It's not contrary cause of this "So pick a percentage number, preferably one that's above COLA, and just give everybody that. If that's not enough, your base salary isn't enough."
Which, to me, implies they have different base salaries for different positions. So when your "career progresses" you get a different (predetermined) base salary. Orthogonal to raises.
If nothing else Dunbar's number will creep in somewhere. And of course the whole reason we don't use flat hierarchies unless the company is really small is because of the explosive growth in the company communications graph.
People could form ad hoc teams to reduce the exponential growth (instead of having such teams pushed on them by management), but then it's not a flat hierarchy anymore. Instead it's a self-organizing construct which may or may not be better than actually designing a proper org. structure.
I'm skeptical when people claim that their lack of managers mean they don't have a hierarchy. If there isn't an official hierarchy there will still be an unofficial one in some way - founders and early employees with more esteem/authority, etc.
Spot on. What you're describing is leadership, which is pretty deeply wired into human nature. We don't try to avoid this; rather, we want to recognize it as a discipline, and help people become better at it.
Authority, however, is totally different. It's the power to make someone do something they don't want to, and we try our darnedest to avoid that kind of situation. (Also note that "having authority" is different from "being authoritative".)
Actually, I'm kind of glad that the link said "video". Because I might not have clicked it if it didn't, and I almost just closed the tab when I saw the video wasn't available.
Amusingly, I'm also glad that the video wasn't available yet, because I clicked through the slides, and I suspect I got the gist of the talk at just about the right density for my interest (and it took very little time).
What I get from these really great presentations presentations/posts/slidehows that Zach creates is that obviously GitHub is an interesting place right now, and Zach has got some really good insight but I can't help feeling that Zach really needs to get some experience with working at few more companies for some of the points he makes. Companies that succeed in different ways, companies that get bought out, companies that fail.
From the outside GitHub is in a really interesting space in that they can dog-food their own product very successfully, they have a huge market and intellectual share, and he writes as if this is the way that all companies could operate - but they simply can't.
For instances some companies have to play safe with what they say and do because they are in regulated industries, some just operate by people that have other values or outlets for their own time. I personally think it's fine if a company that I use has given up blogging or whatever to spend more time on creating a great product, or doing that while enjoying friends and family. I will leave/stop buying when the company no longer creates value for me, not when they stop talking at events or the original founders cash out because some people are born to create new interesting companies but are not suited to the 100+ person growth.
Zach if you are reading this, keep up the good work, but damn your writing is going to be interesting in 10 years time with a few more companies under your belt.
"Our tech stack shrinks as we age, fewer trendy languages and databases, your product should be cutting edge, not your tech"
I'm glad this was said. I find it hard to quell the excitement about new FOTM language/framework/database in our internal team and always wanting to use the hot new stuff that HN is raving about.
Seems like 20% of that slide deck is about chat rooms... GitHub still uses Campfire for chat?
I tried Campfire and Hipchat a couple years ago, neither stuck. Not sure why, maybe poor offline notifications and logging? Or maybe our team didn't have enough timezone overlap or things to chat about? Hard to say.
Is strong chat as important to Github as Zach implies?
As I mentioned, we have 150+ rooms that we chill in, and most of our day-to-day work practices are tied into chat. Mention someone's name in a room they're not present in and we send push notifications to their phone and desktop- works great to pull people in as needed, without needing to distract them with the noise of being in the room 24/7.
Our ops team is particularly in deep with chat. Instead of siloing everyone's process off individually in SSH sessions, many operations happen in chat, so everyone can learn and help out when diagnosing problems. They've built some really fascinating tooling around the problems they face- if you're interested, check out @jnewland's talk on ChatOps: http://www.youtube.com/watch?v=NST3u-GjjFw
I've been working on adding configuration management via environment variables at work. We allow setting configs via the command line, but it posts a notification to our devops room in Hipchat showing who made the change, and which config was changed, but not the new value.
This means that people can see what is going on, without having full access to the settings which may be sensitive.
I suppose you could also set sensitive credentials in a one on one chat with Hubot.
I've seen this done by locking the room, too. That way, everyone in the room when you make the change sees everything (and can check your work), but it's not recorded in the transcripts.
This probably works great for all-hacker teams, but I think it's worth pointing out that some people don't like typing or otherwise aren't comfortable expressing themselves in text. I work with some people who simply refuse to use online collaboration tools. Were I starting a company, I probably wouldn't hire them, but I wonder if there's something to be done about this.
My team uses Slack (http://slack.com) and is very happy with it. It's in active development, and has good cross-platform clients. (Flint for Campfire is great, but last time I asked they didn't have any way to do volume licensing)
We've been on HipChat for a bit now. Campfire seemed a bit ugly to our tastes.
We don't use chat so much for the Hubot-ish stuff, but I have enjoyed using Robut[0] as a culture tool. I usually serve it directly from my computer, which is fun.
All the teams I have been part of have used chat together with Github. First team used Campfire, on the second team we started out with Hipchat, but we decided to give Flowdock a try, and now we can't live without the chat threads that Flowdock provides.
Brilliant work happening at GitHub, of course. Seeing the rise of the "primarily responsible person" is huge for us in our small company - we've found it's natural to work this way, without a label.
Admittedly I'm cynical, but how is a "primarily responsible person" different from a lead developer? It feels a bit like you're just calling things different to avoid manager-like names.
I am reminded of the Syndicalists in 1930s Spain. After their mini-revolution, they abolished money, hooray! The next day they introduced "tokens" so they could get anything actually done...
We use PRP in any situation where someone explicitly takes responsibility for an outcome, no matter whether the outcome is some software or a clean office or an accurate tax return.
Added: That's a little too glib, sorry. Let me try again: From my perspective, if there's something that needs to be done at GitHub there are a few possibilities:
1. It needs to be done and it's getting done,
2. It needs to be done and it's not getting done, or
3. It's bullshit.
Cases of #3 become obvious pretty quickly. The best evidence: Searching for ways to make someone do it because nobody stepped up.
Cases of #2 can happen for a bunch of different reasons, but malice, apathy, laziness, or incompetence are the least likely ones. The most likely: Not enough hours in the day or not enough people with the knowledge necessary to be worried. No matter the reason for #2, someone at GitHub who is worried will generally try to get others to share their priorities, by persuasion, by hiring, or by prototyping.
Or occasionally by just jumping up and down and wailing.
Sometimes the primarily responsible person isn't a developer on a given team. Especially at smaller firms, hats of responsibility are passed around to multiple members of the team, regardless of that member's particular talents/core competencies.
We call them project champions. I work in an agency model, so we have many clients who have many projects. The project champion usually knows the client, their wishes, etc - acts like a product owner (if you're familiar with the term from agile methods).
The product owner should be the person building the product and also be the facilitator for the client. This model of having non engineer/designers as project directors or whatever is broken.
Funny, couple days ago I was wondering why zach stopped talking about the github internal.. which I found illuminating and highly entertaining, and then, a couple days later, boom an amazing presentation.
If I may add a question: How do you manage to keep a consistent design across all teams considering that there's no manager and that most teams have different designers?
We keep a styleguide (which is actually public: https://github.com/styleguide) that we loosely use across many products and apps. Beyond that, we have two libraries (one CSS, one JavaScript) that we pull into projects that help us maintain a general feeling of consistency.
Beyond that, designers get passed around the company a lot. Typically they can implement the frontend quicker than the backend can be finished. This has an interesting and unintended side effect of getting designers working all across the company. I think this plays a large role in getting a lot of the consistent feel across different projects: there's a lot of transfer of taste across the company.
Dear github, please sort out your:
- Intermittent angry unicorns
- Slow data transfer (150kb/sec?!)
- Poor support
- Expensive enterprise licence, why don't you host a better service and i will pay for it?
If you are so fed up with them, why not host an internal Git service with gitolite for user access rules [1]. You could even add something like gitweb as a web interface for git/gitolite [2]. Or, better yet, use something like GitLab [3].
Their enterprise license is pretty comparable in price to something like Perforce, which does not include hosting. Do you also find Atlassian's Stash pricing to be high?
He has an earlier blog post on how he designs his slides. Not extremely informative but csn give you couple of tips on how to get that zach holman look. Iirc it was in response to the how github uses github to build github talk.
The one thing that would make it better would be to black-line border the text I think so that it stands out on the black AND white parts of the slide.
What I think it really has to do with is that GitHub seems to make an effort to hire doers, whereas many companies develop processes to deal with non-doers, eg, having staging servers so non-technical staff can check the work of "their" developers. Remote work also doesn't serve the interests of non-doers, since they want to Have Meetings and Make Decisions.