As part of my plans to reinvent insightfowl I've been meaning to host topical discussions on various (possibly contentious) aspects of the Bukkit project in an effort to improve it and hopefully address the concerns brought up by the community. This is the first of what hopefully will be many articles of this nature in the BukkitImprov series. The first topic of discussion will be the oft misunderstood and contested Unofficial Builds Policy that we've decided to enforce within the Bukkit ecosystem.
This article will cover what the policy is, why it came to be and why we feel that it is necessary, as well as clarify what support we are able and open to provide - and have always been open to providing - to third parties. Due to the nature of this series, these articles are likely to be pretty lengthy and in-depth - you have been warned ;).
What is the Unofficial Builds Policy?
The Unofficial Builds Policy is a blanket ban on the discussion and distribution of any unofficial builds anywhere within the Bukkit ecosystem.
This policy is meant to provide several benefits to the project at the unfortunate cost of a little loss of free speech:
Server Admins are afforded security and peace of mind that any server they find recommended to download within our ecosystem is officially provided by Bukkit, can be ran with confidence and is supported (with the obvious exception of development or special builds)
We're able to provide our community with the focus, resources and attention it deserves when presented with a problem in our product (not including issues caused by plugins, but we generally try to help out in that case anyway). This is only really possible if we're not needlessly allocating resources to supporting someone else's work.
Provides an incentive to users of third party modifications to seek out support from the appropriate location. Although we'd love to be able to help people out with anything and everything, there is simply no way for us to provide any decent help on subject matter we're not at all familiar with and unable to dedicate resources toward.
Why the Unofficial Builds Policy is Necessary
In order to really understand why the Unofficial Builds Policy is a good thing for the project, I need to touch on a challenge we faced (and many large projects eventually end up facing): no matter what your intended focus is when starting your project, as time goes on it is highly likely that your focus will need to shift in answer to the way the project has evolved and grown.
On the surface, it may seem like this shift is insignificant and wouldn't impact how you function as a project but that's unfortunately not the case. In fact, knowing your audience is an integral part of making the right decisions for your project. For example: since Bukkit is no longer purely developer focused, we could no longer just put up a Git log of commits to display what's new in a build we've made available. Instead, I had to address this concern by designing and providing a custom download site (dl.bukkit.org) with our own flavour of changelog presentation. It's difficult for me to understate the importance of understanding how to properly communicate with your audience; server admins are a very different beast than developers and a list of commits would only serve to confuse things. This is just one small example of the many things we had to change and adapt to better serve our new audience, and thus our new focus.
A bigger, more impacting consequence of this challenge is the new found necessity to provide adequate support for server admins using our product. In order to provide proper support, we need to ensure we're completely in touch with our product and able to respond to support queries (formal or not) presented by the people who use what we provide. Personally, I feel that if you're not able to fully support the product you're providing, you should not release it for public consumption unless you state as such when releasing it. Even then, if your project blows up in popularity, you should do the right thing and provide support or pull the product regardless of your preference. Misleading users into thinking that you'll be there to help them when a problem pops up with no intention of actually doing so or expecting others to do so in your stead is a personal red flag for me.
It goes without saying that we can only properly support a product we've worked on ourselves. Armed with intimate knowledge of the way things tick and a list of known behavioural quirks, it's not unusual when we're able to pinpoint the cause of an issue with a small glance at a support request. Despite this, I stubbornly refused to let this knowledge stop me from trying to make the Bukkit project as open and accepting as possible. At first, I was naive to think we could openly support any and all third party modifications, but it quickly became clear that this just wasn't feasible. The sad reality is: the cost of providing support for other projects simply wasn't justified by the benefits we got from doing so. As with many things in life, there is often someone or something that ruins things for everyone.
In Bukkit's case, my vision for openness was dashed by two things: a very real security threat and support fatigue due to supporting projects we were not at all involved in. Early on in the life of the project - around the end of March, 2011 - we were targeted by malicious individuals who thought it was a good idea to "beat" us to a Minecraft update. They planned to do this by creating an ugly protocol hack that would allow updated clients to join a server that hadn't been updated yet. The problem with these protocol hacks is that they never fully work, leading to instability and crashing for the client or the server. Something which successful and competent server admins know will negatively impact the reputation of their server.
While we feel that misleading the community by claiming to have a complete update ready when in fact it is just a horrible protocol hack is in poor taste and disingenuous (a topic I might cover in future discussions/articles), these individuals went even further. Not only did they add code that enabled them to track who was running their hack build, but they also added their names to the version output and joined those servers, misleading server admins into thinking they were a part of the Bukkit team. They then used this "position" to cause mayhem on the affected servers by convincing server admins to give them special access, like op (usually under the guise of needing to debug/test something). If this wasn't bad enough, they decided to further escalate the issue by putting malicious code into the build (which would delete all traces of the server, among other things) and prompting server admins to update. As you can imagine, this is not something we could allow to happen and this unfortunately left me with little choice. I simply had to begin locking down on unofficial builds within Bukkit's ecosystem for the safety of the server admins in our community.
When we were still open to supporting third party modifications, we far too frequently found ourselves spending an unjustified amount of time and resources on matters unrelated to Bukkit. On several occasions we've had to put in a ridiculous 1-3 weeks investigating reported issues, that eventually turned out to be caused by a third party modification and, as such, were issues that didn't even apply to our product. In retrospect, one factor that seemed to contribute to this problem was the stubbornness of the third party modification projects and not so much an issue on the server admin's end. With those same mods refusing to communicate to their users that they were not Bukkit and properly identify themselves as being non-Bukkit, many of the reporters were lead to ignorantly believe that they were running our product (to the point where reporters were adamant that they were running our product and refused to believe otherwise). It is this conscious decision to keep their users in the dark that lead to a lot of wasted time and resources within the Bukkit project as we found ourselves unknowingly providing support for their offerings in their stead.
Despite enduring through these battles because I felt it was for the betterment of the community, it eventually became too much of a drain on the project and we had to cut our losses. Bear in mind that aside from this, due to the nature of the Bukkit project, we already often find ourselves providing unavoidable support for Minecraft and the Minecraft server on top of CraftBukkit, further adding to our support load. As a result, I found myself with no alternative: I had to make the difficult decision of betraying my vision for the project. I immediately set off to create the Unofficial Builds Policy, sadly abandoning my wish for complete openness in the project for what I truly believed was better for the community and our server admins.
Open to Working with Third Parties
As covered in the opening of this article: despite the Unofficial Builds Policy being extremely well-meaning, it is definitely one of the more frequently misunderstood decisions I've made at Bukkit. This is especially the case when it comes to what form of support, if any, Bukkit continues to provide third party projects in light of the policy. Hopefully I can clear this up in this section of the article and I've addressed any other questions you've had about the policy in the lead up.
To put it simply, Bukkit is and has always been open to working with third parties provided they meet a few reasonable requirements:
Third Party Projects need to exercise due diligence when it comes to their impact, if any, on the Bukkit Project.
Third Party Projects need to provide a reasonable amount of support for their product to their users
Third Party Projects need to be open to collaboration.
Third Party Projects need to maintain a respectful relationship with the Bukkit Project.
Due Diligence for Impact to Bukkit:
As a prospective informal partner to the Bukkit Project, if we desire to work together we reasonably expect that certain care will be undertaken to avoid creating an undue and unreasonable increase in Bukkit's work, resource usage and time allotment requirements. This does mean that a project needs to be cognisant of the consequences their actions and decisions have on the project they depend on to exist, but we feel that this is a reasonable expectation for responsibility and only serves to better serve the community.
Examples of actions that could have a negative impact on Bukkit include:
Producing/providing a protocol hack - this increases the support load on our end as people end up reporting the inevitable client/server instability as a bug.
Misleading the community into thinking the protocol hack is a complete and working update - this increases the amount of nonsensical bug reports we get as people believe they're running an actual update and often report issues we've likely already fixed.
Misleading the community into thinking a proper update is out when we haven't released one - this leads server admins to neglect staying on top of our releases (or development builds), resulting in bug reports for issues we've already addressed.
Expectation of Support:
If there is any expectation for support from Bukkit from a Third Party Project, we expect that they are responsibly providing their users with adequate support, accurate knowledge and are vigilant about verifying reports before involving us. As our support load is already relatively high due to our need to support Minecraft and the Minecraft server on top of our product, we simply do not have the resources or time necessary to provide support for non-Bukkit offerings or debunk misinformation.
Examples of irresponsible conduct include:
Misleading users into believing that the product they're offering is an official Bukkit endeavour.
Withholding important information that could influence a user's decision, like the pros and cons of the product provided.
Not providing any support.
Directing their users to report an issue to Bukkit when this should be handled by the project itself.
Refusing to properly identify themselves as a Third Party modification.
Neglecting to communicate the Third Party's dependence on Bukkit and what that entails.
Open to Collaboration:
If a Third Party expects to work with us, they need to also be open to collaboration and the spirit of social coding. In a nutshell, collaboration is a two way street and it is reasonable for Bukkit to expect that the projects we involve ourselves with are open to working towards the success of Bukkit and the benefit of the community. If a Third Party is reluctant to contribute fixes and improvements upstream (back to Bukkit) and/or further believes that any similar improvements upstream makes is a negative, this requirement is not met. Accusing Bukkit of stealing work simply because we have a standard for high quality and thus can take longer to address an issue is in poor taste and not conducive to open collaboration.
Examples of not being open to collaboration include:
Discouraging developers from contributing upstream (back to Bukkit).
Silently fixing an issue and not communicating such to upstream.
Racing to address an issue first to the detriment of quality and/or the community.
Expecting a one-sided relationship where Bukkit puts in all the work without any benefit being given back to the Bukkit project.
Respectful Relationship:
It goes without saying that a respectful relationship is key to effectively working together. As the goal is to coexist and help each other, negative behaviour towards one another only serves to undermine that. As long as a project is open to working with us and maintains a respectful relationship and environment to achieve such, this requirement is met.
Examples of disrespectful behaviour includes:
Attacking or insulting the Bukkit Project and those involved in it.
Allowing or encouraging disruptive behaviour which impacts Bukkit.
Actively working to undermine Bukkit in any way.
Falsely claiming credit for work that Bukkit has done.
If a project meets these requirements, we're definitely open to assisting them with issues appropriately. While we still cannot provide direct support for other projects and their users, we're open to working with responsible projects to address any issues reported to them that they've determined - without a doubt - to be on our end. All qualifying projects need to do is handle their own bug reports and support requests as per usual, then when they come across something they feel is on our end, they simply need to verify this is the case and open a ticket on our bug tracker with the relevant information. Provided the issue falls within the scope of the project, we'll most likely address it - especially if a possible fix is provided with the report.
Thank You!
Thanks for the support you've shown insightfowl so far! I hope you're finding the articles enlightening, interesting and engaging. As the focus of these types of articles is to foster discussion. I'd really appreciate your involvement in the comments section so that we can have a mature, civil and hopefully insightful discussion on this particular topic in order to improve the Bukkit project.
Happy Holidays everyone :)! Just a heads up: I'll most likely be taking a break from everything over the holidays, so there probably won't be any new articles until I get back.
BukkitImprov: Directed Discussions to Improve Bukkit
One of my personal life philosophies is: there is always something to learn from someone else. With over 7 billion people spread out across the entire world, there are many opportunities to learn from the varying and insightful life experiences each unique individual is blessed with. It shouldn't be surprising then that it is also one of the philosophies that permeates through everything I touch and Bukkit is no exception. As a project and as a whole, Bukkit is constructive feedback orientated. Not only do we provide two forums dedicated to gathering such feedback, but a feedback friendly philosophy is also espoused by the entire team all in an effort to always be open to improvement.
While the dedicated feedback forums are definitely useful avenues for discussion that we check frequently, it is less effective for collecting directed feedback on specific topics and a less than neutral location to host discussions. In light of this, I decided to start a new series on insightfowl called BukkitImprov. In a nutshell, BukkitImprov will hopefully be a series of articles focused on different topics for discussion which should assist me with improving the project or at least provide insight into why the Bukkit project functions the way it does.
By hosting these discussions on insightfowl, I hope to allow anyone and everyone to get involved in the discussions, especially including individuals that have been banned from the Bukkit community for one reason or another. Provided people remain respectful, civil and mature throughout, I'm hoping to provide an open and welcoming avenue for discussion here. As I personally feel like a lot can be learned from the opinions of someone not deeply invested in the project, I'm fine with taking the risk of giving them an extra chance to respectfully voice their concerns.
So, there you have it. I look forward to the lessons I can learn from everyone and am excited for what it could mean for the future of Bukkit. If you have any feedback on or questions for this series please feel free to leave a comment so that I may address them and improve insightfowl's offerings.
Thank you for the amazing support you've shown for insightfowl so far and I wish you all Happy Holidays! :)
