On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin

 wrote:

quoted text
> 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.

quoted text
>

> 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

quoted text
>  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

quoted text
>  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

quoted text
>> 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

quoted text
>> 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@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html