
Kicking the Bukkit: Anatomy of an open source meltdown - avandeursen
http://www.slideshare.net/RyanMichela/kicking-the-bukkit-anatomy-of-an-open-source-meltdown
======
RKoutnik
Bukkit made a lot of mistakes (don't we all), but I think that this talk tries
to pin them on the wrong thing. Bukkit was in a failure state the second they
included the Minecraft binaries. You're beholden to a third party the minute
you create a server for the service, but linking the binaries in an OS project
dooms you to failure eventually. Mojang could have DCMA'd the project (and
thankfully didn't).

The talk seems to focus on license as the resolution - and it's an important
point. However important licenses are, they aren't as important as not linking
third-party closed-source binaries in your "FOSS" project.

~~~
scourge
This. Lesson learned: the "over 150 developers" who literally threw away their
time(i.e. money) working on this had the option to work on minetest instead.
They didn't. Grow up, learn your lesson (I have in much more painful ways) and
only use GPL.

~~~
clarry
> only use GPL

It looks like the lesson from Bukkit is that if you use GPL and there's some
problem, then a disgruntlend copyright holder (of GPL-licensed code) can get
your entire project into trouble.

The project of course was wrong to include or link to proprietary code. But
had they used a _free_ license for their own stuff, Wolfe wouldn't have had a
claim to make.

~~~
krisdol
Actually I can't think of a single license that would have been valid here
unless it came with Mojang's permission. The problem was the proprietary code.
Had everything been GPL, not a single copyright holder could have affected the
project in such a way.

~~~
clarry
No, the proprietary code was _a problem_. Another problem was a license that
gave a single developer the power to take the project down. If the code were
permissively licensed, he could've not done that. Yes, it would still infringe
on Mojang's rights, but that could've been addressed separately.

~~~
forgottenpass
_Another problem was a license that gave a single developer the power to take
the project down._

It gave a developer the power to take down a project violating the GPL. That's
probably a quite good power for them to have. I don't see how that's a
_problem_ for anyone except if you currently are or wish you could violate the
terms of the GPL.

------
rodgerd
The advice to have a CLA seems mostly valuable if you want to cash in on the
work of an open source community while refusing to honour the intent of their
contributions, based on this story.

~~~
spindritf
It's also important when you want to make any changes without tracking down
everyone who ever contributed.

~~~
coldpie
Not really. If your changes aren't controversial, you don't really need to get
permission. Arguably some developer could demand their contributions are
reverted, or sue, or whatever, but for all practical purposes no one will care
enough.

Having an agreement isn't a no-cost option, it adds another barrier to
contribution to a project.

~~~
Argorak
Controversy isn't part of the equation here.

You change from license A to license B to your project without asking
permission of those that contributed under license A. Some party uses the code
under B and violates B, but not A. Their attorney argues that you didn't have
permission to re-license from all contributors, so the switch wasn't possible.
You try to contact all developers that committed under A. Sadly, one of them
died a year ago. To add a problem, that person lived in a legislation where
you cannot give away authorship.

Suddenly, you are in a legal mess. You can choose to follow through or drop
the case.

~~~
forgottenpass
spindritf said "make any changes"

coldpie seemed to assume s/he meant "any changes", not "any changes to the
license"

~~~
Argorak
But the initial part of the thread is about a CLA and a CLA covers the
licensing part of the business.

------
quarterto
It's worth noting that Mojang never actually _changed_ the EULA. You've never
been able to make money from Minecraft. They clarified it to allow
monetisation of Let's Plays and their ilk, while ensuring that pay-to-win
servers were definitely a no-no.

It's also _always_ contained the Do Not Distribute term. Bukkit has always
been in the wrong here. It's not the EULA clarification that did that.

------
Kiro
A bit OT but who are all these people making the mods? It seems really
complicated and I'm impressed great developers choose to spend so much time on
it. What's the incentive?

~~~
Cogito
I've talked about this a few times, but I was there at the start of Bukkit,
and though I haven't touched it for a few years I still think back to it now
and then.

The motivation was many faceted, but the basic impetus for most people in the
server mod world is that the vanilla server was so inadequate for running a
server.

I got involved with a small server, and (quickly! that was a mistake haha)
started to help sysadmin the box. I got us on to hMod, which was terrible in
many ways but provided a vision for the future - a central, modded server,
with plugin points that proffered server admins incredible flexibility
configuring their servers.

hMod was run by a single (apparently inexperienced) dev, and the community
grew too quickly for him so bukkit was formed.

By this point I had started contributing to hMod, but realised it was a
sinking ship and switched my efforts to bukkit. It started as trying to build
plugins for our server, but as I started getting commits into the core project
it quickly ramped up into full on team participation.

The dev team was really really fun to be a part of. I was on mumble and irc
all day talking to the other devs, and would often spend over 8 hours working
on code or talking about plans. Upgrades were hectic, and everyone pulled long
shifts when they happened.

As time went on and the community grew it became more like a real job, and
momentum kept me going for a long time. Eventually I actually got a real job,
and my participation waned.

I can't speak for others, but my motivation seemed to be a spectrum that
started with scratching an itch end ended with the satisfaction of
contributing to a community; the knowledge that your code is being used by
thousands, if not millions, of people.

~~~
gingerlime
sorry to follow-up with an even dumber question(?). Feel like an old fossil
not playing a game in probably 25 years or so.

What's the motivation for running a server? and how do people using the game
decide which server to use and why? I'm really stuck at the basics.

~~~
lelandbatey
Many people set up servers so they and their real life friends can play in the
same world together in real time. That way, you can both work on building a
house, or a city or a world.

Larger servers have complex mods that add tremendous functionality to the
game. Some may have roleplaying mods, where you can find a role (blacksmith,
lumberjack, etc) and participate in the economy. Others may set up a world
just for pure creation, a way to make sculptures.

There's a lot Minecraft has been extended to, so there are many reasons you
may have to set up a server.

~~~
gingerlime
Thanks for the clear explanation. I somehow thought everything was in one
"game world". The way you described it makes a lot more sense to me now.

------
reubensutton
I'm confused what selling an open source project would even mean in this
context?

~~~
mikefaille
For example, RedHat, Cisco, Suse (Novell), Alfresco, Wordpress, Drupal, etc.
Can sold their Free Software project.

You can have it free. And it's ok. But having success is possible too (recheck
my examples).

You can refuse to pay. But, if you want support : $$$ for value++. (you just
buy the brand)

See this for more info
[https://www.gnu.org/philosophy/selling.en.html](https://www.gnu.org/philosophy/selling.en.html)

~~~
kaoD
I wish people would tell you what's wrong with your comment instead of
downvoting you into oblivion. Sorry, sometimes HN sucks.

There's a great difference between selling access to your software and selling
your project itself, i.e. the copyright assigned to your code and/or logos,
trademarks, etc.

------
incision
Are there any particularly good comparisons of OSS licenses in terms of facts
as well as perception?

I regularly see comments on one project or another pointing to a XYZ license
as the reason a project failed / has few contributors as if the 'problem' with
that particular license is entirely self-evident.

It's awfully confusing as I'm sure I've seen polar opposite opinions on every
major license under the sun, each entirely bereft of context.

~~~
hugofirth
tldrlegal.com is a really good resource

~~~
clarry
If you want the facts, tldrlegal looks like a terrible source (except for the
original license texts), and will no doubt contribute to the confusion with
its vague, misleading and incomplete tl;drs.

------
dwild
I seriously doesn't understands the issue here.

Okay it contains the Minecraft server binary, remove it. If it's the issue
then it's no longer an issue if it's the user that download it themselves (I'm
pretty sure it was working like that in the past).

Is it the signatures of the methods from the official server? Is it really an
issue? Isn't all GPL project full of methods signature and call to windows
binaries?

------
tzs
Slide 41 is amusing. The list of example GPL software is headed with the GPLv3
logo, yet none of the examples are GPLv3. Three of them are GPLv2, and one is
AGPL (acknowledged in the list).

------
davexunit
To me, it looks like Bukkit was doomed to fail from the beginning. Bukkit
created an LGPLv3 project based upon proprietary, decompiled Java class files
which is a copyright violation, afaik. Reason #4 for failture states that not
having a CLA was a problem. Bukkit certainly seems to have had many problems,
but a CLA would have just been one more.

------
Immortalin
Minecraft forge
[http://www.minecraftforge.net/](http://www.minecraftforge.net/) (mainly used
in the feed the beast modpacks)is still alive and kicking. Only downside is
that they don't have a clojure wrapper.

------
donatj
GPL3 seems to be the biggest issue here. It's basically the single worst
license you could pick for something who's entire basis is hooking to closed
source code.

All that said I'd be very interested to see this play out in court, not to
imply that it will get there. I feel strongly that the developer forfeit his
control of the code on contributing it to the project. I can't say for sure
though, I'm not a lawyer.

------
Cogito
A few comments say things like "they shouldn't include the binaries" or "why
can't they just link to the binary, let the user download it themselves" etc.

There may have been a way to achieve that (and we talked about a few of them
quite a few times) but it was never as simple as just 'linking to the binary'.

The Bukkit project was actually composed of a few different pieces, designed
to make maintenance of the mod manageable across upgrades of the game. This
architectural change was one of the main reasons Bukkit split off from hMod in
the first place.

There were 4 main codebases in play; the Bukkit API, the CraftBukkit server
mod, the reverse-engineering-tools project, and various plugins supplied by
the Project or for use as examples.

I go into more detail below, but the reason why just hooking into the binary
was so hard is two fold, and meant that CraftBukkit could never really just be
a server wrapper.

1\. Methods, method calls, and program logic needed to be modified directly to
enable things like turning off fire on the server. Anytime the game tried to
start a fire CraftBukkit had to fire an event, and allow that event to be
cancelled. So CraftBukkit had to be a mod in the purest sense.

2\. Obfuscation meant that modified files had to be translated every single
upgrade. To reduce this burden large swathes of the code was de-obfuscated, so
that the upgrade process was de-obfuscate core code -> translate any mod
changes that used obfuscated code -> apply mod changes on top of the core code
-> fix the thousands of bugs we missed in the translate step. So much of the
mod was on top of this de-obfuscated version of the server that _any_
distribution would require distributing large amounts of de-obfuscated code -
there was no other source for this.

So there may have been ways to avoid shipping Mojang code, but it was always
going to be a hard slog. When the core team started conversations with Mojang
it always seemed like there was never a pressing need, and as I understand it
Mojang still hasn't shut down Bukkit. It was a lone developer asserting a DMCA
take down.

I would be very interested to know if there is a better architecture that
solves these problems, some more of which I have listed out below.

==== More Details ====

The Bukkit API consisted of JAVA interfaces, providing a stable(ish) API
against which plugin authors could build plugins, and some glue code to manage
the plugins. This had no code from Mojang in it.

The various 'official' plugins were coded against the API, and similarly had
no Mojang code in it.

The reverse-engineering-tools project was used to, perhaps unsurprisingly,
reverse engineer the official server. A lot of the code had been de-
obfuscated, but that de-obfuscation was usually a painstaking task performed
by hand. These tools made that process much easier. It included a decompiled
version of the official server code, but the project was private and wasn't
distributed. Not sure how that impacts everything.

The CraftBukkit server mod of course DID contain Mojang code, the modded
server. It's job was to implement the Bukkit API.

The API was almost entirely event based. Plugins would hook on certain events,
and the server would wait for the plugins to process the events before
continuing with whatever it was doing.

Someone tries to set a house on fire -> LightFireEvent is fired -> NoFire
plugin hooks the event -> NoFire plugin cancels the event -> in game no fire
is lit.

In order to implement these events, entire code paths within the game need to
be diverted, hooked in to, subverted, or replaced. There are lots of ways a
fire might start, so we had events triggering when lava ignites a block next
to it, and explosion sets some grass on fire, someone uses flint to light a
tree, etc. Each one requires

* finding the obfuscated code path that implements the feature we want to hook

* de-obfuscating the code so it is clear(er) to see how to modify it correctly

* modifying the de-obfuscated code to introduce the hooking code, and implement the API

Every time there was an upgrade to the server we would have to map every
modification made to the new obfuscated code base. So if CraftBukkit had
modified or included a call to an obfuscated method (which happened often
enough for it to be a pain) then those changes had to be mapped to the new
method signatures of the upgraded server. c(wx, f, b, 23) might now be e(ww,
f, b, 23) and translating that to a modified code base can be hell.

The Bukkit team took that process on itself, which is one of the reasons it
was so successful. As long as the API points used don't change, a plugin will
continue working as soon as CraftBukkit is upgraded.

~~~
GhotiFish
Forge was based on decompiling and patching mojang binaries, it works pretty
well.

~~~
Cogito
Yeah, as I mentioned we did talk about it a lot. As it seemed like a lot of
work, and since mojang had turned a blind eye, the effort never seemed worth
it. The core team got bought before it all came to a head, otherwise you might
have seen a greater effort to separate the code bases.

I'll have to look in to forge, I haven't yet seen what they are doing, but it
sounds interesting.

EDIT: the other aspect was the fact so much code was written against the de-
obfuscated version of the code base. There's an argument that distributing
that patch would also be distributing mojang code.

------
Ecco
Awfully similar to the VLC on iOS story. Terrible license (GPL) + one angry
developer = millions of frustrated users.

~~~
cbd1984
Meh. The GPL does very well for a lot of projects used around the world.

------
gear54rus
So it failed just because of the stupid outdated law system - just like many
other great ideas.

Maybe it's just my idealist part, but isn't it a shame so many efforts (or
much effort? not sure) in this world went to waste just because of blabla you
can't distribute or blabla you cant build upon... This is _digital millenium_
, wake up!

~~~
cybrox
Of course it can be frustrating, if you can't build upon a project, if you
have an idea that you want to realize. I'd say you have to look at this from
the other side. Well, you can't blame people for building upon your project as
long as they don't publish or distribute it but would you be happy if somebody
distrubutes a better version of your product because he's allowed to build
upon its source?

Granted, Mojang did make a lot of Money with Minecraft regardless but
especially with open source projects building on other open source projects or
especially non-profit projects in this case, this would be really problematic.

Developers don't need to wake up, they just need to put in the effort to chose
the right license and make everybody who wants to contribute to their project
agree with licensing their own code under said license.

~~~
clarry
> would you be happy if somebody distrubutes a better version of your product
> because he's allowed to build upon its source?

If it weren't for projects that make better versions by building upon others'
source, I wouldn't be here. Hopefully in the future someone will also find my
code good enough to build something upon.

------
mikefaille
Not sure about this presentation.

Just enforce GPL licence and you'r ok ;-)

Just ask Software Freedom Law Center and your fine. (every body can do this
move; like you)

For example, it works against Cisco :
[http://en.wikipedia.org/wiki/Free_Software_Foundation_v._Cis...](http://en.wikipedia.org/wiki/Free_Software_Foundation_v._Cisco_Systems)

