> As for the 'large' company, I think his definition is valid. Where I am now we're approaching 200 employees, and it's well beyond the point where everyone knows each other (there is a term for this limit). Even for 400 people, the traditional 'meet at the watercooler' methods break down, and you need to inject some innovation to meet everyone.
Personally, I like to use Dunbar's number as a the divide between small and large companies.
I spent the downtime trying to figure out how to use Jade without the documentation available -- the docs are in the readme.md on the Github repo. It was only later that I realized that the docs were also available through npm (https://npmjs.org/package/jade), but it was an interesting experience nonetheless.
Average CCIS Co-op Salaries
Student Level Average Midpoint Average top 25%
Undergraduate First Co-op $20.00 $19.00 $28.00
Undergraduate Second Co-op $22.00 $22.00 $29.00
Undergraduate Third Co-op $23.50 $23.00 $30.00
Graduate Co-op $28.00 $28.50 $34.00
I've set up Gitlab at Northeastern University to explore it as an option for replacing our cgit install(s). I like the UI, but my only problem with it is that it doesn't support putting repos under a user namespace like Github does (with Gitlab, rails/rails and ali/rails can't exist on the same system). AFAIK there's no plan for Gitlab to support this, but it looks like Gitorious already does.
I'm the founder of Gitlab.com and this is very high on our list of priorities. All our code is open and we will try to merge the changes back into the main project. This functionality is the most upvoted item on our feedback site https://gitlab.uservoice.com/forums/176466-general/suggestio...
I set this up at my university to see if it would be a good solution for school-related project hosting. Haven't rolled out (yet), but as you said it's very promising.
This is my fault for not explaining why I wasn't going to look into it more. According to the features it has listed, it offers me no obvious advantages to my current tools and claims to be difficult to setup and configure.
Beyond that, if you truly want adoption for a tool, you'd invest time into making sure that you remove the obstacles of someone utilizing it. This is a tool that hasn't had any major releases since "September 15, 2010" and hasn't had any commits for two months.
As silly as it sounds I think most of these tools are just being overly appreciated by a group who (at least sub-consciously) think of themselves as cool/badass for having some hacker-style terminal in front of them, you know it's true.
Hit me all you want, but the same applies to Vim and Emacs for a large percentage of people who admire these tools.
People religiously defend them just because they are 20 something year old terminal GNU/Unixy programs.
If someone came up with Vim today, with a slick polished GUI interface, etc... you'd find far less people talking about how great it is and you'd find the same people who are appreciating them today, making fun of it.
I know that's a generalisation and doesn't involve everyone but I think it is not insignificant.
There are a minority who use and need the tool and appreciate it for what it is and have been long time users. For every 1 of those people, there are thousands more who simply follow the teachings of the cult to be in the cool nerds club.
There seems to be a pattern here, a recipe for a shitty (once useful) program that is no longer relevant that a group just doesn't want to let it go.
It kinda goes like this,
1. Be a 20-something year old program written by some GNU/Unix kernel/hardcore/early developer
2. Run in terminal with a million options and parameters
3. Be extensible with all sorts of weird text file configs, plugins etc...
4. Have a short weird-sounding name that is an abbreviation of some other weird phrase
That's all you need. Then no matter how terrible the user experience is and how outdated and irrelevant your program has become, you'll always have that cult who religiously love your program and insist on extending it so it can be a space shuttle as well as a text editor and an email client.
I should point out I'm not mocking any application in particular and I think many of these tools were fantastic for their times and some of them are still quite good today but my rant is towards this obsessive religious overly-appreciative culture of praising these softwares.
We are past that age of black screens and terminals and horrible user experiences. They were fine for their times but not anymore.
I'm not gonna put up with an application that is almost as old as myself and spend hours to configure it just to be a little more efficient.
The efficiency argument seems more like an excuse, because you don't want to admit that you are putting up with the downsides of the application because of all other nerd-culture reasons.
Or, perhaps, the tools do something well, are flexible in their approach, and, by way of incremental improvements and configurations over time, fit very hand-in-glove with those who've been using them for some time.
I'd used multiple email programs before finding my way to mutt, including various GUI programs. I'd used elm and pine briefly and somewhat enjoyed them. My primary mailer prior to mutt was Netscape's built-in mail client (NN3/4). The main problems with that were instability and some lack of flexibility.
Mutt took a week or so of getting used to ... and then ... just worked.
Not having an integrated editor (e.g.: making use of vim) was a huge win. One of the huge benefits of console-mode tools is that they can make use of one another in this way.
I've used a great many email clients since encountering mutt, and none are as fast, effective, reliable, and efficient as mutt. I keep coming back.
My complaints? Search through large volumes of mail (10s to 100s of thousands of messages) is slow. Google's use of tags is really useful, and more flexible than a highly-structured set of mailboxes. There are add-ons / forks of mutt which provide both features.
There's also a lot to be said for tools which work over a minimal configuration -- 24x80 vt100 emulation over serial line (your "last ditch" remote access method for most servers), SSH, Connectbot, console, etc.
Knock them all you want. The tools are useful, ubiquitous, standard, and effective.
Personally, I like to use Dunbar's number as a the divide between small and large companies.