A Question of Trust

This stream grew out of my rambling The Balance of Power stream.

A lot of what we do in creating organisational structures (whether governments, corporations, non-profits or other entities) is about establishing and maintaining trust.

There are all sorts of trust relationships at play:

• we trust (or not) that employees will work in the interests of their employer
• we trust (or not) that employers will try to do the right thing by their employees
• we trust (or not) that employees will try to do the right thing by their fellow employees
• we trust (or not) that governments will try to do the right thing by their citizens
• we trust (or not) that citizens will try to do the right thing by their fellow citizens
• we trust (or not) that vendors won't try to rip off their customers
• we trust (or not) that regulators will try to protect the interests of customers over those of vendors
• we trust (or not) that customers will recognise that products aren't made of magic pixie dust and that if vendors can't survive, the products will often go away (or, at least, won't be as good as they could be).

Proprietary software licensing has such a bad reputation because it's an inherently monopolistic power ripe for abuse:

• a proprietary vendor's copyright license over their software is protected by the full coercive power of the regional government. In the specific case of the US, this includes the ridiculous statutory penalties for copyright infringement.
• a vendor's promise to not abuse that power generally can't be trusted, as "doing the right thing by our customers" is not typically a legally binding obligation, and the history of proprietary software is a history of dubious practices by monopolists.
• Open source licensing (even on a time delay from the proprietary version) is a powerful way for a vendor to make a promise to do the right thing by their customers in a legally binding fashion.

I highly recommend Bruce Schneier's Liars & Outliers on the general topic of trust.

Something I think may distinguish the likes of GitHub and Atlassian from the traditional proprietary vendors that have given proprietary licensing such a bad name is the fact that even though their software is proprietary, it isn't a platform in the same sense that an operating system or a PaaS cloud service is a platform (in the case of PaaS, "platform" is right there in the acronym).

For those, customers really do need the full protection of open source licensing to avoid the kinds of abuse we have seen from vendors in the past.

Hosted services are a little different, especially with things like OpenShift Online becoming available to make self-hosting far simpler for many use cases. There, the customer base is generally more mobile, and while network effects do exist, they're nowhere near as strong as those that previously locked application developers and hardware manufacturers into dependencies on proprietary platforms.

So perhaps setting the bar at "completely open" is setting it too high. A more appropriate standard may be "open enough to be trusted, at least for now".

That second bar is one that companies like GitHub and Atlassian clear easily, while other companies that grew up under the traditional proprietary enterprise model don't.

I think "open enough to be trusted" is a more accurate description for Red Hat, too. We're definitely not an open company like Gittip, and we do consider various things (like many of our certification tests, for hardware, software and training) to be secrets worth keeping.

When you look at it that way, then a company like GitHub keeping the implementation details of the shiny front end a secret, while open sourcing the back end systems that do the heavy lifting sounds a lot more reasonable, even from an open source purist perspective.

The other key thing to remember is that both GitHub and BitBucket are vulnerable to displacement if they "turn evil", and they know it.

While the two big free-as-in-beer proprietary hosts (and their network effects) do suck a lot of potential users and contributors out of the pool for the open source hosting options, GitLab, Gerrit, Allura and Gitorious are still excellent options for projects and organisations that are concerned about the governance of their dependencies.

With services like Red Hat's own OpenShift offering to handle the hosting and server maintenance component for free, a couple of those projects teaming up to work on a "federated pull request" system could potentially make inroads into GitHub's dominance.

The current state of the DVCS hosting market is like an email system where all of the email providers offered POP3 and IMAP to their users, but none of them implemented SMTP to communicate with users of other email providers. The two proprietary providers have no incentive to collaborate on a federation protocol for pull requests, so if it's going to happen it will need to come from the smaller open source providers.

The folks from RhodeCode noticed the exchange on Twitter that prompted the previous card and suggested I take a look :)

Source code is here with mirrors on both GitHub and BitBucket.

I think that's as nice as GitHub or BitBucket (sorry any Allura folks reading this!), so time to put my money where my mouth is and pony up the cash for a small RhodeCode instance and migrate my personal Hg repos away from BitBucket :) (Well, once the free trial period ends, anyway!)

In contrast to GitHub, BitBucket or SourceForge, which are like one big shared instance instance, RhodeCode's hosted offering is a bit more like getting your own Gerrit or GitLab server. I suspect, with that model (and the main benefit of higher payment plans being more registered users of the instance), it's a better fit for personal or business use than it is for open source projects.

That said, open source projects that can't afford the rates might be able to combine the RhodeCode source with the free tier of OpenShift Online or the offer of free open source project hosting from RackSpace...

Some time after I wrote the previous card, RhodeCode shifted to a fully proprietary licensing model, and the Kallithea fork was formed from the last clearly GPL'ed version of the RhodeCode code base.

GitLab also absorbed Gitorious, and started clearly positioning themselves as a more open and flexible alternative to GitHub, including publishing clear info on their notion of responsible stewardship of open source projects: https://about.gitlab.com/2016/01/11/being-a-good-open-source-steward/