

Github: Interesting Repositories - mcantelon
http://github.com/repositories?a=1

======
jrockway
Not actually interesting; these are all projects that have massive public
exposure and that I have already heard about. What would really be interesting
are up-and-coming projects that are not already massively popular.

The page should be titled "look at how popular Github is" instead.

~~~
exogen
They show trending repositories, too, if you click on Explore:
<http://github.com/explore>

The pages with the most data, however, are the individual language pages:
<http://github.com/languages/Python>

I discovered this because my project happens to be on the Most Watched list
for Python at the moment. ;)

~~~
jrockway
Nice. My .emacs file (and support files) is apparently one of the most forked
Emacs Lisp projects :)

I wonder how many peoples' emacs installs I'm going to break whenever I commit
to that repository now...

------
vicaya
I'm interested to see their interesting algorithms to determine interesting
repositories.

It's obviously not based on the numbers of watches and forks.

~~~
mrduncan
It looks like it is manually curated to me.

If not though, I'd second your interest on how they determine it
algorithmically.

------
icefox
meta interesting: looking at the languages there are only two C++ projects
that are 'interesting'. Would this be that C++ is not interesting or C++
developers don't put their projects on GitHub? On the flip side in the ruby
world it seems pretty defacto that you will put your project up on GitHub, but
does that mean Ruby is more interesting? There are probably plenty of
communities that are not like Ruby where it be be beneficial for GitHub to get
some eye balls looking and learning about GitHub moving that community to a
tipping point of switching to Git and using GitHub is the default.

~~~
samdk
GitHub is overwhelmingly populated by projects written in dynamically typed
interpreted languages. A quick look over at the 'Top Languages' tab tells us
that compiled languages don't even show up until position number 7.

~~~
jrockway
This is just because that's the language style popular with people writing
their own software. If it was "CorporateCubicleTeamHub", you'd see a lot more
C++ and Java. Github shows what sort of tools are actually optimized for
productivity, because when you are working on something for yourself in your
spare time, you don't have time to waste.

~~~
tbrownaw
> Github shows what sort of tools are actually optimized for productivity,
> because when you are working on something for yourself in your spare time,
> you don't have time to waste.

It shows which tools are optimized for low bootstrap overhead. When working on
something simple for yourself, expected productivity is governed by rather
different aspects of your toolchain than when you're working on more complex
projects that involve other programmers and even long-term maintenance.

~~~
jrockway
All I can say is that 99% of personal projects I've worked on are much nicer
in terms of test coverage, deployability, documentation, and maintainability
than anything I've worked on with a large group of paid ("professional")
developers. Like I said, developers working on their own projects optimize for
productivity; documentation, test coverage, maintainable design, easy
deployment, and so on all save time and make the project more enjoyable to
work on.

Personal projects have enormous time pressure on them; instead of "can I build
this by the amorphous deadline in three months", it's "can I build this
feature and still get a few hours of sleep before work tomorrow". That's a
whole order of magnitude (or two!) different from paid software development.
That harsh evolutionary pressure has brought out the best techniques, because
these good techniques increase productivity by so much.

In the corporate world, there is too much negative inertia and too little
incentive to improve productivity, so people just do whatever, and "whatever"
is not usually the best way to be productive. (Write some tests, and your
coworker just breaks them the next time he wants to make a quick fix without
thinking about design. Now there are two problems, and it ends up being easier
to just not write the tests; it's better for the app to break in production so
your manager allocates you a chunk of time to fix it. And so the cycle
continues; the software getting buggier and buggier, until you need a team of
100 people just to keep it alive.)

I will point out that not all corporate paid development is like this. My
$work at a large company is very much like an open source project; there are
shared libraries that everyone uses, and if you change them, you need to
update the docs and make the tests pass. Your own stuff that nobody else uses;
do what you want. It works very well. But of course, it's not Java or C++ :)

