Slashdot Mirror
Visualizing Open Source Contributions
An anonymous reader writes "A student at UC Davis has created some stunning visualizations of open source software contributions, including Eclipse, Python, Apache httpd and Postgres. From the website: 'This visualization, called code_swarm, shows the history of commits in a software project. A commit happens when a developer makes changes to the code or documents and transfers them into the central project repository. Both developers and files are represented as moving elements. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away. A histogram at the bottom keeps a reminder of what has come before.'"
"When a developer commits a file, it lights up and flies towards that developer."
Shit, that sounds kinda scary... flaming files chasing you around the office.
Are there other sources for the videos for us Gnash users?
How many times have I told you to stay out of my laboratory?
If a file is commited it flies towards the developer
Cool, and now I start with 1 developer and eventually add more. What exactly does determine where their place is inside the cloud? Does a developer commit and fly towards the middle or is this random? What happens if several developers commit the same file in a quick period of time? I think the idea is fun but I'm not really impressed without knowing these facts too. Without those this is merely a random animation generator based on commits, which can be compared with your standard scope on Amarok.
Finally, a way to see who is wasting the most of their day here!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
One of the first things that shows up in the Apache video is a "rodent of unusual size" (!).
Your webserver was coded by a hamster and your Perl smells of elderberries!
Those who would give up liberty to obtain working drivers, deserve neither liberty nor working drivers.
"When a developer commits a file..." an angel gets its wings. .When it breaks the project, the angel and developer go to hell.
.
.
.
.
After watching python and apache, I was really impressed. I especially liked it when python went from three core developers to "the world" when it became more popular.
Lots of commits isn't really a measure of developer productivity or worth. Among other things, it might just mean a scatter-brained developer who commits lots of unrelated, mostly useless changes, or somebody who continually writes bugs then has to back them out. More seasoned programmers will tend to make fewer, but larger commits.
Something open source seems to lack in general is project stability. With so little central oversight, changes tend to happen without people really thinking things through, many times without any clear motivation for the change other than simply pumping out code in order to look "active."
Software engineering as a discipline has been working for decades to come up with a heuristic to evaluate programmer productivity, and we're still nowhere close, although there are literally hundreds of formulas in use.
Of course, it's flashy and cool, but I worry that this will only encourage people to make more commits instead of actually using their brains.
Of course the first thing I wanted to do was try the visualizer on my open source projects but... it's not open source.
Pretty, but somewhat useless. The idea is nice and would make a cool presentation on any FOSS project web page, but if it's not open source(d) it'll die.
My blog
I wonder how the animations here would compare to those of of closed source projects that use a revision control system. I'd imagine there would be less flying around of files (i.e., one piece of code might have a specific maintainer), much less people involved, etc.
I think this somewhat relates to the "activeness-on-wikipedia" problem. Of course, there are differences, but in terms of "introducing bugs and backing them out", "minor unrelated changes", "quality of commits" it is comparable.
http://www.aaronsw.com/weblog/whowriteswikipedia
I'd like to see that type of presentation used to show the credits for a film. You could color the contributions according to acting, camera, sound work, directing, etc.
Now if someone could make those visualizations interactive GUIs to archives and people, we might finally be getting somewhere. Someone wake me when we're in Stephenson's Metaverse, the home version of the game.
--
make install -not war
Apparently they did the same thing for Vista and posted it to youtube, but people just thought it was a watermelon exploding...
Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
what the visualizer does with a project that dies. It would be interesting to watch the fits and spurts of activity as it gradually dies out.
Likewise, I'd like to see a project that goes through definitive cycles where it has nearly died more than once and then been resurrected.
I have no examples to provide for either of these ideas... it's just what I'd like to see.
man, I feel like mold.
At least this is visualizing something useful (and maybe encouraging more commits), as opposed to http://twittervision.com/ .
-- If you're posting to be funny, and your sig is funnier . . . .
Linux kernel, Free/Net/OpenBSD, gcc, ... the core infrastructure
Well, you could look at the diffs and track the percentage of each file that's got code from each committer... making sure to look for reverted code and giving credit to the person who originally committed the reverted code...
Very.
You can lead a man with reason but you can't make him think.
What's the IQ of a project tracking FOSS projects that's not a FOSS project?
OMG, I'm STUNNED. Benevolent Deity, help me!!
All I get is a "to watch this video, you need Flash 9" message -- displayed in a flash object that runs in Flash 9.
I was sad that the Python one ended in 2006. They missed me!
It's interesting. After each release you see big bursts of documentation updates, then lots of commits from a varied crowd, then a trend towards larger/more frequent commits by a fewer number of people, then another release hits.
I'm thinking it's because after a release big architectural, functional, and feature changes are less likely to change really soon and lots of changes have happened recently, so there's a lot of documentation to update and it's the ideal time to do it: the release just came out so the next big release that changes things will be a ways out.
I'm thinking the trend towards contributions from larger numbers of people after the documentation boom is for two reasons - one, the more "hobbyist" developers have had some time to get familiar with the architecture revamps, and two they've had time to see where the new documentation doesn't line up with the new behavior and find/fix little bugs.
After that, as a new release is coming up, the core developers are making big changes to key infrastructure. That's why you see more central activity from them as they make the more bold and large changes in anticipation of the new release.
That's what I gleaned/theorized from the visualization, anyone have other potential insights or theories?
.. the wings get torn off and a dead kitten is stuffed in the crippled angel's mouth. Then and all the other developers throw their empty Dew/Engery Drink cans at the offending developer shouting "NAY NAY!".
Or so one could wish.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
I guess you could learn to read this like a Dr can read X-rays and other such stuff, but for me it was just confusing.
in my life God comes first.... but Linux is pretty high after that
Francis Smit