When it first appeared on the scene, Github was one of a kind and a true visionary amongst its rivals still using Subversion, Bazaar or Mercurial as their source control system.
Since then the scene has changed a lot, with many alternative options challenging the monopoly established by Github. However, its pre-eminent position allowed Github to more or less take for granted that every open source project out there would use it as its hosting service.
The problem is that Github hasn't been treating its free hosted open source projects and their contributors as real life customers who use it as a product. Of course, any software based product needs updates and upgrades but foremost a software provider has to listen to its clients' needs.
Github, relying on its number 1 spot, has neglected these needs to the point of sparking a pressing demand for action.
The cry for action was expressed in an open letter, signed by many top notch project maintainers, like Adam Bradley of Ioni; Dave Methvin of jQuery; Ryan Cavanaugh of TypeScript and more than 1,000 other devs.
In the letter now known as the "Dear Github" letter they collectively make the following statement :
"You have done so much to grow the open source community and make it really accessible to users. Somehow you have us chasing stars and filling up squares, improving the world’s software in the process.
However, many of us are frustrated. Those of us who run some of the most popular projects on GitHub feel completely ignored by you. We’ve gone through the only support channel that you have given us either to receive an empty response or even no response at all. We have no visibility into what has happened with our requests, or whether GitHub is working on them. Since our own work is usually done in the open and everyone has input into the process, it seems strange for us to be in the dark about one of our most important project dependencies."
They go on to enumerate the issues they would like fixed or upgraded. Looking at them, they're really nothing special or hard to do and if fixed would have very practical implications for the greater good.
For example, custom fields for issues:
"issues are often filed missing crucial information like reproduction steps or version tested. We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue"
or a better voting system:
"Issues often accumulate content-less “+1” comments which serve only to spam the maintainers and any others subscribed to the issue. These +1s serve a valuable function in letting maintainers know how widespread an issue is, but their drawbacks are too great. We’d like issues to gain a first-class voting system, and for content-less comments like “+1” or “:+1:” or “me too” to trigger a warning and instructions on how to use the voting mechanism."
isn't that much to ask.
Other demands, of secondary importance, appear on a separate list. Once more it goes to show that at its core, the problem is not treating the people hosting their projects as real life customers.
What is worse, besides angering the client base, GitHub's neglect has provided opportunity to other alternatives to take advantage of that slip and challenge the leader for its throne.
GitLab for example is aggressively looking for its own slice of the pie by releasing a counteroffer to the disgruntled projects in another open letter addressed to the "Dear open source maintainers" in which it states that it would be more than happy to work on the issues identified in the "Dear Github" letter and cater for all software projects, open,closed or paid, thus filling the current gap.
GitLab then addresses each of the three major issues appearing on the Github letter, explaining what it has done, or will do, about them.
For example, with regard to the issue of the "custom fields" request:
"In GitLab you can set a template for an issue and for a merge request.We’re also planning to add multiple templates, that you can use depending on the reason for making an issue.We’re also interested in exploring custom (required) fields."
"GitHub has a better UX and more features than GitLab. The advantage of GitLab is that you can freely install it on your own servers, hence a very cheap solution if you want unlimited private repositories for your team, compared to GitHub private repositories pricing."
"The big upside to GitLab is that it is all open-source"
and on the minus side
"Major con: The slowness is a major pain point for myself at the moment. I haven't hosted my own projects at GitLab so far, but just browsing other projects is quite terrible: every action takes seconds to complete. Every time you press anything you are looking at a 1-10 second wait. "
Of course GitLab aside, there are other contenders, each with its advantages and disadvantages. For example, Ubuntu's LaunchPad which recently started adding Git support into repositories making the switch from its Bazzar source control system.
Regardless of the answer to this question, one thing is certain: Github fell victim to its own success and with Pandora's box now open, anything is possible. Thinking the unthinkable, there is even the possibility, after so many years, of losing its hard earned crown to one of its competitors.
Facebook's F8 conference often seems more like a place to announce its future directions than anything directly relevant to developers, but Litho should be of interest to any Android programmer. [ ... ]