2012 – Page 5 – T-machine.org

As a free-time project, I’ve been writing a Risk clone (*) for iPad.

One of the bits I like best right now is that you can give it the URL of *any* SVG file on the web, and it automatically turns it into a Risk map.

(e.g. all the maps in Wikipedia articles are SVG files – it’s a common file format with good browser support)

This was one of those “interesting” technical challenges – I had to find an algorithm that would automatically work out which territories a human would “assume” were connected to each other.

I’m using an open-source SVG library which works fine for basic SVG files but has a lot of bugs with the more esoteric ones. I’ve already fixed a few of the major bugs (they’re now merged into the GitHub project) – but I’d like to get more SVG files to test with.

The one thing to bear in mind is that the colour-data gets wiped when it imports. So … SVG files that make heavy use of different colours or gradient-fills/pattern-fills lose detail when imported.

Also, files where none of the elements are close enough to be deemed “connected territories” … work poorly.

Everything else works fine.

So … if you’ve got any, please post a comment here with URL, or email them to me directly (address in the About link at top of this page).

(*) – I say “clone” because it’s the same genre – but the gameplay is “fixed” quite a lot. If you once loved Risk, but grew to hate it, you’ll see why I wanted to change the baic game design :).

What happens when you get 2 developers working together, sharing their source? What about 10? … or a 100?

There was a dream, 20 years ago, that the total would be greater than the sum of the parts. That developers could *re-use* each-other’s code.

Sadly, that dream – in 2012 – is poisoned.

What I’m going to describe here happens a lot – although in absolute terms, I hope it’s just a drop in the ocean. Maybe it’s nothing to worry about. Or maybe … well. In the last 15-odd GitHub projects I’ve tried to use, it affected more than a third of them. Such tiny stats are statistically meaningless, of course – but if you look at the causes of this, I think it’s more likely part of a general trend – and that really is worrying.

So. What’s going on?

The curse of Github

I love GitHub, I’m a paying member (and I regularly sell it to clients and colleagues) but … in some ways, it’s IMHO actively preventing collaboration.

Just to be clear: it doesn’t have to be this way – you can run your own projects on GitHub and prevent this happening.

But … GitHub makes this the path of least resistance, and that means – in the world of Open Source – it’s the path that gets most followed

When you fix a bug on GitHub, you have to wait for the original project author to “accept” your fix.

If they don’t accept it, as far as collaboration goes: you’re screwed. There is no “plan B” for collaboration.

Your only option is to tell the world:

“Stop using his project! It sucks! Use my project instead! I promise I’ll be a better merger!”

But then … if *you* stop accepting fixes for a while, one of the developers fixing YOUR bugs will have to do the same thing.

And each of these “Stop! Use mine instead!” calls is one-way: once another developer who’s making use of the source moves to a sub-fork, they can never go back. In theory, the original Author could do a back-dated merge … but in reality, that won’t happen, because of the cost involved:

Back-dated merging is combinatorially expensive

In practice, that’s more expensive than a normal person can afford, in terms of time and effort.

For each SubAuthor they want to back-merge with, they have to check every single change that person has made … against every change that they’ve merged already, from every single source. Otherwise they break the previously-merged code. Usually, each individual SubAuthor makes an incompatible change sooner or later – and so prevents the original Author from ever merging with them.

It’s no surprise – usually by this point the Sub Author has given up on the original Author (can you blame them? the Author has disappeared and ignored merge requests for months or years by this point)

So, in practice, very few GitHub authors (so far: none that I’ve seen) re-merge SubAuthor projects once the SubAuthor has really got going. On the projects I’ve been involved in, when a popular SubAuthor disappears for a while, there’s been a desperate scramble by the SubSubAuthors to find the guy/gal and beg/bribe/bully them into merging – otherwise we know that our combined efforts are about to be blown up.

What? Well …

The actions of the Author can undo the work of the Collaborators

Say you have Author “A”, and 3 people making changes and fixes to the code (“B”, “C”, and “D”).

At first, while A accepts merges quickly, B, C and D are all sharing code together – in practice, they are collaborating. However, they are not truly sharing code – GitHub does not allow this – they are sharing code with a Master (A), who is forwarding their work to all 3 of them.

When A disappears, B C and D can no longer collaborate. If A disappears with merges pending … then B/C/D find they have 3 distinct codebases, and no way within GitHub to do a simple cross-merge.

Now, the situation is not lost – if B, C, and D get in contact (somehow) and negotiate which one of them is going to become “the primary SubAuthor” (somehow), and they issue manual patches to each other’s code (surprisingly tricky to do on GitHub) … then they can resume collaboration. I’ve done this myself – it works. But it’s massively more complex than the process they were using before, which was *one-click-merge*.

In practice, at this point B/C/D will stop collaborating. Sad, but true. This happens over and over again on GitHub projects – when a SubAuthor arises, the other collaborators stop collaborating and become new SubAuthors in their own right.

Often it feels like watching a religion split, with each of the senior priests declaring themself “the new Prophet”, and going forth to spread (their) word…

Net effect: GitHub may be killing open-source projects

In theory, GitHub is wonderful.

But the combination of its bad design around some core use-cases, and its intransigence when it comes to the VERY common case of a single person disappearing … have lead to the point where I believe it’s killing projects. This is a gross generalization – and not every project that loses its Author will get this problem – but I’ve encountered more and more “dead” projects on GitHub over the course of 2011.

Of course … the way GitHub is designed, *those projects do not appear to be dead*. Often they appear to be very much “alive” – there’s tonnes of activity.

But all that activity is going on in radically different and massively incompatible forks. It’s wasted time and energy, it’s programmers fixing the same bugs – multiple times – because they are NOT collaborating any more.

In the case I cited at the start, 100-plus developers have (probably) re-written the same fixes for the same problems.

i.e. the total effect of this project is tending towards ONE HUNDRED TIMES less than the sum of its parts.

Note: LESS … not more!

There’s some value there, still – anyone can come along and start from the original project and make their own fork. But it’s a sad and sorry fraction of what the Open Source world dreamed of when the word Collaboration was fresh and exciting.

This is UnCollaboration. And its becoming depressingly common.