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.
Unfortunately, Fossil's web-facing part is somewhat neglected. Up to the point, that the issue tracker for Fossil itself has been practically closed and the docs moved out of the wiki...
I still use it as a nice dvcs though, mainly for the single binary file installation.
Where do you see docs outside of the wiki? (Duh, the rest of the internet...)
Also, where do you get the idea that the issue tracker has been closed? It's possible that the maintainer has gone on hiatus, and there's not as much activity as there was once, but I see they have fresh issues this week and a release just yesterday.
I think that Fossil is a terrific way to introduce anyone to command line, database, and scm who you intend to sell or gift with a 'database' of any kind. It's very odd to me how many people can't wrap their head around the concept of a file, or database, let alone ./configure; make; make install
I think that SQL is the most accessible language to those people, since it fits a simple grammar and statements end in semicolons, and the fact that Fossil repositories can come packaged into a sqlite database file means that two weeks after you got them to try using Fossil to keep their copy, there should be no magic left in the box, you can show them a database and they should 'get it'.
I have not tried this with anyone, but it should work... of course unless they just aren't trying...
Are you serious? Fossil's docs have been "embedded docs" for quite a long time now. Even the main page is served from a file within trunk (this is the url / redirects to):
For the issue tracker: just try to report an issue (without logging in with a dev account). It has been very long time now that Fossil is accepting issue reports only through email. It's quite an ironic thing to do for a project that's providing an issue tracker, isn't it?
So, is that the wiki or not the wiki? It says wiki...
I think you're only telling me things that sound like they've been done to prevent spam or addition of spammy content.
I get that a file in the trunk is not the wiki. There is a real wiki, with web browser controls, and it's not what they're using. But it says wiki, and if you're trying to edit it but not a Fossil developer, you're probably doing it wrong... you should have your own Fossil repo/server.
I'll admit I did not try to submit an issue, and I'm not using Fossil right now. I just use Git. My users don't want the timeline on their homepage. shrug
As I said, this is a file from trunk. It says wiki, because .wiki is the file extension for wiki-formatted files. Which you typeset in almost plain HTML, but that's another story.
And, actually, I am a Fossil developer. Or at least a whiner with a dev account. Believe me, I know what I'm whining about.
Finally, Fossil is not for homepages. I guess your devs like having a timeline on their Github...
There's also Gitorious, which has been around a while and is mature, full-featured, and provides both a SaaS [2] and the FOSS software you can host yourself [3]. I keep backups of some of my repo's there.
gitorious.org - the free open source hosting service (came first)
gitorious.com - the commercial company behind it (came later)
getgitorious.com - official doc, starting point etc (recently added as a common starting point)
It's not quite a "github clone" in the sense that it's supposed to be self-hosted. It would make it more of a trac/redmine concurrent, depending on how much work has gone into the wiki and project management part. Is anyone actually using it?
And ironically, the source code is hosted on github.
I started Gitlab.com last month and we already have more than 250 people who have created an account.
Many companies are already using Gitlab behind their firewall: Phusion, Thomson Reuters, Michigan State University, see the bottom of the Gitlab.org front page for more.
I'm not a core contributor, we're building on the work that was already done. However, we are working fulltime on this and we work in the open and are sending all our work upstream. So we hope to become core contributors and help the Gitlab project flourish. Read more on http://blog.gitlab.com/contributions/
There're a lot of people who don't want to use GitHub for whatever privacy policy.
If you consider using Gitlab as a in-house self-hosted "GitHub-feature like" alternative, Gitlab is really good! We use it for our projects and it runs quite well.
We did a 45 day trial. To call it disappointing would be a vast understatement. Performance problems, no root access, no direct repository access, poor tooling (had to wait for support to write us a script). We were actually locked out of our repo with no recovery options for about 4 days before we gave up on Github support. I do love Github, just hate their "have your own" VM product, it is bad.
After that we tried Gitorious (back then it was still an unholy nightmare to install) before finally landing on Gitlab. Gitlab isn't perfect, sometimes the ruby process likes to eat gigs of memory and has to be restarted (we have very large repos)...
But Gitlab has a great trajectory, every release is a great step up and I find the multiple branches working mode more natural than the multiple repos method that github has...
Huh..we've had full root access since the beginning. (Github FI) Even across all of their releases. There's a place to drop your public key in.
Github support has been variable, but generally good for us. The switch to a VM was touchy at first, but once we gave it enough horsepower, things were fine.
In order to preserve the integrity of the appliance and ensure that it remains in a consistent state, we have these limitations in place:
- Root access is not provided.
- The admin user password is not provided.
- Installation and execution of third party software is not permitted.
- Modification of the underlying VM configuration is not permitted.
Bypassing any of these limitations will void all warranties and may put your installation in an unsupportable state.
Totally agree. We have about 500 devs on enterprise github (which is totally different than github:fi) and it is terrible. There have been so many issues including constant service failures that require reboot, missing / disabled features, poor ui choices that we are still cleaning up, the list goes on.
I still can't even limit access to it using an ldap group. If someone works for the company, then they can access it. Totally unacceptable for a product that licenses based on numbers of seats.
Atlassian Stash was released five months ago for Enterprise teams adopting Git behind the firewall. Stash is installed on your servers and gives you full control of your Git environment - security, user management (LDAP), infrastructure support and pull requests.
Also: don't get me wrong, i love Github and what it's doing for our opensource culture, but like everything else, sometimes there're other requirements.
I'm using it right now. It's rather lightweight and is easy to setup on a low end VPS. The git-related code has features Bitbucket only just added: side by side diffs, comments at line number, activity log...
The issue tracker is rather basic (like Github) so you guessed correctly -- many people are using it alongside Redmine. I've created a simple patch and theme to tie the two together [1] - something that would be impossible with Github. Between the two it's had a significant positive impact on recent projects for both me and my clients. It's been much easier to grasp the current state of the project than using just gitk or a standard file browser or cli client. I expect to see many more Gitlab installations in the future. The ability to customize it for a need is invaluable.
I've set up Gitlab at Northeastern University to explore it as an option for replacing our cgit install(s). I like the UI, but my only problem with it is that it doesn't support putting repos under a user namespace like Github does (with Gitlab, rails/rails and ali/rails can't exist on the same system). AFAIK there's no plan for Gitlab to support this, but it looks like Gitorious already does.
I'm the founder of Gitlab.com and this is very high on our list of priorities. All our code is open and we will try to merge the changes back into the main project. This functionality is the most upvoted item on our feedback site https://gitlab.uservoice.com/forums/176466-general/suggestio...
I'm confused by one thing. I found this awesome jpg checked in on the GitLab Django demo project: http://demo.gitlabhq.com/uploads/note/attachment/2449/687474... Seems like everything else on the demo repo requires me to log in but I can access this file without authorization... Why is that?
Found it in the Django demo project attachments tab: http://demo.gitlabhq.com/django/files which requires login.
It's gloriously ironic! A photo mocking Rails security attached to a private repo... that's not secure.
You are right that attachments are only hidden and not protected by default. GitLab uses the CarrierWave gem to store attachments and this defaults to a publicly accessible directory. You can configure the behaviour of the attachment in https://github.com/gitlabhq/gitlabhq/blob/master/app/models/...
It's not mentioned in the release note, but I find implementing "Mix commit notes with merge request notes on MR show page" (https://github.com/gitlabhq/gitlabhq/pull/1630) the greatest change in 3.0. We are using merge requests as a tool in code review, and this commit finally allow us to go through all comments of an MR in a single page. It would be perfect if the issue "Save few lines of code with Merge Request comment like github does" (https://github.com/gitlabhq/gitlabhq/issues/1007) is implemented, as this would allow us to finally reliably comment directly on the "diff" tab.
I wonder if the grammar mistakes are beneficial for adoption or if it drives people away (no, really). The "who is already use" line on the homepage reminds me of "All your base are belong to us." I could see it appealing to a certain audience of programmers, IT support, and the like -- particularly those with a background in gaming.
Has anyone done any A/B testing on something like this?
[Edited: I'm _really_, _really_ not trying to be the grammar police here. I'm in no position to do so, and my grammar is faaar from perfect. I'm just wondering about the actual impacts (or lack thereof).]
As has been mentioned, you see this a lot in projects that are started by a small core group of programmers that have english as a second (or additional) language but are attemtping to develop to an international audience. It's open source though, so us native speakers are more than capable of helping them out.
Judging by the downvotes and this reply I think I made a mistake in making whether or not it's meant to be humorous the focus of my question. It seems like it should be intuitive that grammar mistakes == bad conversion, but I'd love to see numbers on it since I really doubt it's hurting them much, if at all, in this case. C'est la vie.
We've been using GitLab for about six months and it has been great. The developers iterate very quickly and they are totally receptive to pull requests (have had a couple accepted and one rejected for good reason).
If you install it on Ubuntu, their wiki has instructions that you can pretty much copy and paste; the most complicated bit probably being the gitolite setup, which is what it uses internally for repo auth.
Timely for me.
At my workplace, we are migrating to git and the devs would like to use github, but management is expressing reluctance to either rely on an external host or fork out for github enterprise, despite our arguments.
I was already planning on installing gitlab this week to try it out.
Anyone here got any advice or suggestions on using it as a Github replacement for a small team?
We're on an old install of gitosis at my shop, and also keeping an eye out for something to switch to. Gitlab certainly looks appealing, especially given its similarities with github. Having used Gitorious, are there any strengths or weaknesses you see in GitLab that would have either prevented you from using it or made you choose it over Gitorious were you to make the decision over again?
At the time when I was looking Gitlab was in its infancy, and Gitorious was pretty much the only thing out there. The search wasn't exhaustive as it was a "we need to get this working, now." kind of project where we didn't really get a lot of time to play with different platforms.
I liked Gitlab when I ran it for myself for a while. It was great; couldn't knock it in anyway except for (at the time) setup instructions that weren't detailed/accurate enough to rely upon, especially regarding the main dependency gitorious. The big sell for this is simple, or even trivial, setup.
I was just a single user so most of the functionality was a loss, so I transferred to bitbucket (free private repos) knowing full well the potential risks. It saved me the effort of keeping my own server up to date and secure (I'm not the pro, I can trust github or bitbucket to know and do better) at the cost of no longer being self sufficient.
That said, I'd recommend this for any organisation that wants its own github, doesn't want to pay enterprise money, and doesn't mind doing all the hard work itself. And that's not faint praise, because it was fucking good when I did use it (while it was mid-Twitter Bootstrap conversion).
I am using it for a small project in my company and I'm pretty happy with it. It's nice for enterprise-level projects that are not Open Source.
You could pay for GitHub or even get a private BitBucket repo for free, but some companies just prefer having their own thing.
Yeah, uh, there's plenty of room for people like me who have lots of repos that either MUST or should stay private, but neither wants to use BitBucket, nor pay $5k/year, although that is pretty cheap to start with, my projects aren't for revenue generation.
You are reading it wrong. "Gitlab does not run on Windows" means that you should deploy this on a linux _server_. You can still use windows on your local machine, and push your changes to a linux box. It's true that you will have to have another machine, or a virtual box to use gitlab, but I believe that's how small/medium companies work.
> There exist plenty of genuine windows devs out there that use git, or devs that switch between OS'es for different tasks (myself included, I'd boot up windows to work on graphics/games)
Yes, but you probably shouldn't be running a code hosting platform on one of your developer workstations.
I'm pretty sure it would work from a client point of view (it's still git after all), just that they won't support you running their web app on windows.
I've been using gitlab for a while, and so far I like it. It has a few weaknesses here and there for sure, and the UI has some wonky aspects, but overall it works quite well.
We've been using Gitblit (http://gitblit.com/) in the office for new projects and are quite happy with it. It all comes together when you hook up Groovy push scripts which we use to notify our Jenkins instance to test and build which in turn pushes it to our dev server for deploy.
mattdebord and estel: I'm one of the core Gitorious committers. What specifically did you find messy? The initial setup or GUI/UX? Honest question, as we're constantly trying to prioritize based on the painpoints of users. :)
BTW we've recently addressed the complicated manual setup with a new, automated installer that gets you set up within 30 minutes: http://getgitorious.com/installer
Does the web editor support editing files in a bare repo ?
Yes.
The trick is that lib/gitlab/file_editor.rb checks the file out, modifies it, commits it, and removes it. I read this from one of the comments in the original post.
Fonts look really horrible in Chrome on Windows. That has been a problem for a long time and they've still not done anything about it. I know that Google doesn't let any employees use Windows so that explains why they overlook stuff like this. But it's a big deal, so I'm uninstalling Chrome from all of my Windows computers now.
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.