On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Sun, 27 Jul 2008, Tom Werner wrote: >> I find it a bit confusing that some here seem to have a strong dislike >> for GitHub. It's true that we haven't been active on the developer list >> or in the #git channel on freenode, but we are constantly in #github and >> have answered a *great* many questions from developers that are new to >> git. > > Speaking for myself, I will probably direct some users from #git to > #github, then. > > The deeper reasoning: if you really do help by that channel, by all means > I want to provide you with the opportunity to do so. By all means! The users might be a bit confused about why you're sending them to #github, but we're happy to help them out if you don't care to. We actually employ a support person to man the channel and help out where he can. >> Perhaps it is the commercial aspect of GitHub that offends. > > In my opinion you can be as commercial as you want. Nevertheless, I would > like to see some direct benefit for me, too, for obvious reasons. That > does not need to be money; like Junio said, watching out for user > questions on the Git list would already be very useful, in two respects: > > - the core developers have more time for hacking on Git itself (which > would be good both for the developers as well as for you), Using this same logic, it follows that we GitHub developers would be better suited to hacking on GitHub (which would be good for the git community). There are only so many hours in the day. I've had many a GitHub user tell me that the GitHub interface and functionality helped them finally understand git and feel comfortable switching to it from SVN or CVS. It seems we can help bigger populations of git users by making the site as clear and easy to use as possible, so that is what we choose to do. > - if your advices can be enhanced (such as my gripe that "git show" is not > even so much as mentioned, in spite of being _the_ porcelain to inspect > objects in Git's object database, not cat-file, whose only role in > tutorials can be to shoo new users away) it will be early, which again > is a win-win situation for both core developers as well as for you, and Can you clarify what you are referring to here? I'm not sure I understand. > - just as in the past, I fully expect the main thrust of the major changes > in Git to be driven by user experience (just think of Git 1.5.0), and by > driving users away (and indeed, by driving yourself away, a bunch of > power-users), you would make that much more unlikely to happen in the > future. So, having you closer to the Git mailing list and #git would > again be a win-win situation. I totally agree with the direction that 1.5 has taken git. You guys are doing an awesome job with user experience. As I come across usability problems I'll be sure to bring them up here in the future. >> Having had to implement a git-daemon replacement that fit our needs, I >> have some ideas on how to improve git-daemon and fetch-pack with >> regards to error messages and logging. > > I might mention here that I think you are committing one of the biggest > sins in Open Source: you do not reap the full power of the community. > > I am sure, if you would have mentioned your needs first, possibly followed > by an early version of a patch, git-daemon would already be enhanced to > your liking, and these enhancements would be available to everyone > (including me, for example). But maybe that being available to everyone > is not in the best interest of a commercial outfit? The problem is that I'm only a casual C coder. It takes me a while to figure out what's going on in the git source. We needed a way to serve public git repositories from a hashed directory structure (e.g. /a/b/c/user/repo.git) and we needed it fast. In a few days worth of coding Erlang, I was able to meet that need (and also add logging and better error messages returned to the client). If I had, as you suggest, created a badly written patch and asked for help on the list, I'd probably still be trying to solve the problem. It's dubious that anyone other than us currently needs to satisfy the hashed directory requirement, and as such I would not assume or expect that anyone would be motivated to spend a bunch of time helping a C amateur satisfy that need. In the end I was responsible for making it work, and I did that the best and most efficient way I knew how. Like I said before, I'm happy to share my suggestions for better error messages and logging behavior, but I'm probably not going to be much help with providing patches. >> We like to design from first principles, see how good we can do, and >> then get feedback from the users. > > Maybe this is so contrary to Open Source that many are uncomfortable with > it. > > Also note that one of the major gripe with you making money off of Git > could be the following: we have over 500 contributors, and most of them -- > first and foremost of all, the two major contributors, Junio and Shawn -- > cannot make money from Git. Envy is wrong, but it is real. This is clearly false and does not do Junio or Shawn justice. It's not hard to imagine that these two (or any of the other contributors) could make money doing training for git at companies that have adopted it, or as consultants to firms that use git in novel ways, or as authors of git books. Scott Chacon gets paid right now to work on tools that use git as an underlying file system. In fact, by helping bring corporate interest to git, GitHub is paving the way for more and more people to make money from git if they so choose. I wouldn't be surprised if, down the road, Junio could be paid to hack on git full time via corporate sponsorship. The continuing advancement of git is of interest to a great many people. Some of which would gladly pay for it. Tom Preston-Werner github.com/mojombo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
