Github like any monopoly will come back to bite us. That is why I think we need an open source Github.
That said, the interface seems a bit too "inspired" by Github. I hope they rethink how an application like this should work for themselves rather than allowing Github to influence their designs.
I see this quite frequently among opensource projects, they try to make clones rather than making a better product.
TLDR: Think about how the UI should work in your application. Its different for everyone so don't blindly clone others.
That said, the interface seems a bit too "inspired" by Github. I hope they rethink how an application like this should work for themselves rather than allowing Github to influence their designs.
I don't understand your critique.
My impression of Gitlab is that they've done it exactly right. They copied the good parts from github but not the clutter, and it's looking pretty damn good so far.
Most notably they did not copy the non-hierarchical triple-menubar trainwreck of an UI-disaster (whoever came up with that at github should be fired three times in a row).
Instead Gitlab has a boring, utterly intuitive two-level hierarchical menu, consistently on every page. I love this boring menubar.
There are a couple reasons app developers should strive for originality.
Copying Github's design only reminds me of how your app is second to Github. That Github was the one who thought of the beautiful interface and that by using your app I will be using a copy and not the original. The copy is inferior to the original in my mind and I will never see the app as an equal. This really dampens the excitement I have for it because it might never be able to compete with the experience Github provides.
Another example is Open Office, everyone uses it and it does the job. But no one loves it, because its a copy. Its not the original and it will never be the same as using MS Office. Now compare that with Apple's iWork. Its not a copy; its an original. When I use it, I feel comfortable in knowing that Apple has worked to provide an experience that is second to none.
1. Most people I know like Github's UI, so it makes sense to copy it. MS Office is not known for it's UI experience. So it doesn't make sense to copy it.
2. Creating a good UI is hard work. When you're Apple, you have the resources to throw at iWork. An open source project doesn't have the same resources, and they might spend a lot of time to end up with something worse than Github's UI.
To me it's a simple decision:
1. Spend a lot of time and end up with something that could be better than Github but will probably be worse OR
2. Spend little time to copy a design everyone is familiar with and likes.
I think a better analogy would be Gimp vs Photoshop. Supposedly Gimp can do almost everything Photoshop can, but what % of designers use Gimp? They have been slowly moving towards Photoshop's UI because they now realize how much of a factor that plays in adoption.
I for one love LibreOffice Writer and find it to be much more intuitive and configurable than Word. Draw and Calc leave something to be desired, but the needs they fill are better served by Adobe products and R respectively, imho.
I agree on the menu bar. Consistency in UI being present on every page is something that deserves applause. There's a point to be made about similarity in overall look and feel to Github, but I don't believe that even Github has a clean-room implementation of a source code hosting web application. So,- tough luck. Add ability to make Gitlab skinnable and it's good enough for me.
I definitely agree with this, where I think the UI is too similar is in the color scheme, and other general look-and-feel things. The rounded corners if you will. GitLab could probably do something different.
I think "monoculture" or just centralization in general would be a better name than "monopoly" for what the OP is getting at. Hacking is all about decentralization to ensure free access. If github implements a policy (surely there's some action permitted by TOS, perhaps which most people would like, that you wouldn't), UI change, etc., you have no real recourse outside of convincing them it's in their best interest to change it to how you like it. With a decentralized system where you run your own node you can modify the code and behavior at your discretion.
On top of the possibility for customization and extension, having more independent nodes means less chance of catastrophic failure. The cloud is remarkably unstable; look at heroku's uptime and at cascading failures even in redundant cloud systems for an example. It'd take the whole internet falling apart for thousands of individual hackers' repositories to all break down.
There is always this thing about centralization. It makes initial social networks easier to form and the value comes from that.
And then we would like to see people eventually move to decentralized tools doing the same thing. But so far this second phase hasn't been easy. The reason is people building installing these decentralized tools.
We've spent the last 2 years building a platform that will make building and deploying decentralized apps in Node.js easy :)
A platform where one of your friends hosts something you like, you click a button and download and install it from them. Versions propagate throughout the system. The security is a key component -- you need to make sure it is signed by the developer. Also you can decentralize the app stores and centers of trust. If some of them are reporting the software as malicious, you will know.
That last part is hard. You are hosting the software on YOUR computer, so malicious software may be dangerous. It either has to run in a sandbox (as a website does in a browser) or it has to be proven to be safe by someone.
While I agree that Bitbucket and Google Code are interesting competitors, I think the "popularity" of SourceForge is misleading.
SourceForge is only big because they are already hosting so many projects. I haven't seen any intresting new projects there. And those being there are would mostly be willing to switch to GitHub, if they had enough spare time for that (it's not just the project switch, but also the switch from CVS or Subversion to Git they would have to manage).
They are between the conflicting priorities of providing improvements on the one hand, and making switching easy on the other hand. I fully agree with not making a 100% clone. However, being mostly similar to GitHub increases their acceptance among users who are already familar with GitHub.
Other reimplementations of big applications face similar issues.
For example, the similarity of LibreOffice (formerly OpenOffice) to older MS Office versions is an important factor that contributed to their wide success. Over the years, they were able to maintain a more consistent UI than MS Office.
You make a good point - the similarities will make the transition much smoother. On the other hand, the paradigms don't have to change with the user interface. You could maintain the similarities without cloning UI elements which they seem to be doing.
When facing a strong competitor, you have three options:
Innovate. This is hard, and if you aren't skilled enough to pull it off you end up with something inferior to the original.
Create some kind of gratuitous differentiation. If you're not qualified to innovate but you want to be seen as not copying. This is the worst option IMO.
Copy the leader exactly. (Hello Samsung!) This is what you should do if you can't afford to innovate (and if you can get away with it).
Unfortunately, open source developers who are too proud to copy but not skilled enough to innovate in UI is what leads to bad software.
Is making a round wheel copying inventor of the round wheel, or is it just using what we know, through trial, error, and customer and market feedback, works best? Or, to bring it up to the Internet age, take the Amazon.com checkout process. It is, arguably, the "best." (NOTE: I'm not going to take up space defining "best," but to try to nip the troll in the bud, I'm talking about "best" as Amazon, the world's largest Internet retailer, defines it, which is in ways it can and does test, measure, and optimize.)
The current state of the Amazon shopping cart and checkout experience is the result of billions of tests (transactions) over the past 18 years of its existence. In fact, we can think of Amazon as a giant "shopping cart testing and optimization machine" that displays its findings for all to see. To not use and benefit from those results is, let me try to find a word other than the "s" worD, maybe not a great idea.
My point is that Github is the market leader in what it does and to not identify and benefit from its best parts is maybe not a great idea. I would expect a strong competitor to GitHub to be strongly inspired by it. Obviously, they cannot (or at least should not) copy things that would infringe on GitHub's copyrights and trademarks, and not its color scheme, typography, and copywriting, but I would expect features and workflows to be very similar, sometimes even identical, to GitHub's. Microsoft Office vs. LibreOffice is an example that comes to mind. Don't reinvent the wheel. Use the knowledge and test results that you have available. Swim downstream, not up.
Copying every pixel would be smarter than trying to reinvent it from scratch. Knowing how much split testing Github does, I don't understand your logic. "Better" is a subjective (and perhaps moving) target, but 'just as good, while keeping it open source' is a more objective route.
That said, the interface seems a bit too "inspired" by Github. I hope they rethink how an application like this should work for themselves rather than allowing Github to influence their designs.
I see this quite frequently among opensource projects, they try to make clones rather than making a better product.
TLDR: Think about how the UI should work in your application. Its different for everyone so don't blindly clone others.