If you provide something that GitHub doesn't have it will make for a much more compelling sell.
Currently GitHub doesn't give you fine grain access controls, this is something you could capitalize on and provide for clients. Something they could go back and say as awesome as GitHub is, they can't do this so they have to choose you.
A few examples.
- I only want [release dude] to be able to push to any release/* branch.
- No one should be able to force push to master
- No one should be able to force push to release/*
- release/* branches must follow the regexp [...]
- The user bmeyer can only create branches in bmeyer/*
- The user bmeyer can only push commits to the branch master
if the patches touch files in src/network
- Users that don't have a single commit in the repo can't push at all. (After analyzing an internal project this one rule would have caught most of our breakage and forced the first commit by a new user to be pushed by another developer who would be more likely to catch basic errors such as build.)
- Users in the group [foo] only have R access to the entire repo
Really go check out the rule support in gitolite which is a good model to start with as it is very expressive and allows for doing a lot of stuff. http://sitaramc.github.com/gitolite/rules.html
Disclaimer: Having made my own GitHub clone I have thought about this a fair bit. (GitHaven, which sadly was killed by my works legal dept before it could get off the ground.) If the feedback is about your UI or some minor feature that GitHub has that you don't, ignore them because if you solve that problem you are still in the same boat and they will go with GitHub. You need to solve an existing users problem so there is someone out there who will be shoving money at you to make their problem go away even if you made your UI ugly and barely working.
I think you are right that Gitlab would be a more compelling alternative with some major unique features. You give great suggestions for better access controls.
Access control in Gitlab is currently done with the following roles: Guest / Reporter / Developer / Master. See http://imgur.com/yFkVb
Would that be a start? Which of your examples do you need most?
A git server frontend is really about three things (I would say in this order)
1 Providing permissions to access the repository
2 Providing a visual way to browse the source code and link to the source code (sha X, file Y, line Z)
3 Slap features on top of the above two (bug management, code analysis, doc generation, auto publishing like gh_pages (awesome btw!), code review, task analysis, etc etc
Really checkout gitolites permissions. The ability to create devs into group (test/release/intern) and then on top of that apply 'R', 'W', '+', to any or specific branches and or files creates an expressive set of rules.
When I was working on GitHaven I also had a simplistic permissions model like GitHub has. But the more I talked with end users the more edge cases I found and the more I realized how the permissions is really a core bit of the thing I was building and if I were to hack on GitHaven again I would either built it on top of gitolite or build something just as expressive, if not more.
P.S. set your email in your HN account. As I have spent too much time thinking about this problem I would be happy to buy you a virtual beer on facetime or whatnot to share what I have learned about the problem if your interested.
Edit: from the description it sounds like it is already built on top of Gitolite :) So making a fully feature UI for their permissions should be easy.
Good insight about the functions of a web front-end. I totally agree. And I think the first two are a priority before slapping features on top.
Gitlab is build on top of Gitolite so setting granular permissions should be doable. I worry that the combination of groups and branch settings will be hard to maintain unless you name your branches consistently.
I'm very interested in talking to you to learn from your thinking. I've set my email on HN, my Skype handle is sytses and my contact info is on http://sytse.com/contact
I applaud the effort, but I guess I don't really understand what, exactly, it is. A GitHub clone? Hosted Git with no interface?
For example, take your first sentence: "Gitlab is an open source solution for version control of your coding projects." Doesn't that describe Git itself?
Assuming that Gitlab is an open source GitHub-alike, I'd make that clear right up top: "Gitlab is hosted Git with an open source web front-end." Then, if possible: screenshots.
I wouldn't make the one private repo your selling point, either, as others have pointed out. I would go with the open source angle -- that's your only real differentiating feature (that I know of), and the one that you should really emphasize.
As you suspect Gitlab is hosted Git with an open source web front-end. I changed the first line of Gitlab.io to your exact quote, thank you for the suggestion.
