Re: SmartSVN - a new Subversion client.

Brian,

Our intention is NOT to create a derivate of Subversion, we are creating a
powerful Subversion client, which will communicate with your Subversion
server. I know, what I'm talking about, because we need to handle the
diversion of CVSNT and GNU CVS in our SmartCVS and this is a very hard job.

We definitely hope, that you can ensure for the future the one and only
Subversion-standard. Unfortunately you've choosen a license, which makes it
quite impossible to enforce this.

BTW, our SmartCVS users asked us approximately one year ago, "when SmartSVN
will be available". To this time we neither have decided to create SmartSVN
nor registered the smartsvn.com domain. But of course it was the most
natural thing to name our Subversion client "SmartSVN" - everybody would
have done in our situation.

--
Best regards,
Thomas Singer
_____________
smartsvn.com
Brian Behlendorf schrieb:
> On Sat, 20 Feb 2005 kfogel@collab.net wrote:
> 
>> Brian Behlendorf <brian@collab.net> writes:
>>
>>> Any particular reason you are using the "SVN" abbreviation in the name
>>> of a product that isn't part of the Subversion project, or even open
>>> source?
>>>
>>> I guess the rest of us will keep using "DumbSVN"...
>>
>>
>> Marc, just to clarify:
>>
>> I think what Brian's objecting to is not the mere presence of the
>> string "SVN" in your product's name.  Plenty of Subversion-related
>> projects already have that, as a glance at our Links page will show.
>> The issue is more the *combination* of that name, "SVN", with the fact
>> that you're offering something that takes the place of the 'svn'
>> client already offered by the Subversion project.
> 
> 
> Well, no, that's not quite accurate.
> 
> I think this community should be more protective than it is about the 
> Subversion name, and its SVN contraction.  I think it would be a 
> disaster if it ended up like the Linux community, where the confusion 
> over what-is-Linux has opened the door to FUD storms by competitors and 
> confusion by people outside the circle of Slashdot readers and others in 
> the know.
> 
> To illustrate I'll create a fake example far worse than the current one, 
> to make clear my concern.  Imagine a company who noticed the great press 
> and word-of-mouth Subversion was getting, and decided to release a 
> product called "SubversionPro".  Let's say such a company has never so 
> much as submitted a bug report or comment on the users list, let alone 
> fixed bugs or added new features.  Let's say they got smart and 
> purchased the Subversion keyword at Google and other search engines, 
> obtained subversion.com[1], paid for a positive review in some tech rag 
> that didn't make it clear that the "Subversion project" is an open 
> source project but instead linked to "SubversionPro", etc.  How would it 
> make the people here who contribute to the project feel to have our 
> public image essentially hijacked out from under us?
> 
> I've tried *extremely* hard to fight back the impulses within CollabNet 
> to pull a JBoss on Subversion, because I've always felt that doing so 
> would disincent other contributors, and disincent other companies from 
> also incorporating Subversion into their products.  I *want* to see the 
> community of core developers be much, much more than CollabNet's own 
> contributions.  That's why we chose a very easygoing license, and kept 
> the CollabNet imprimatuer to a minimum.  I want a large number of 
> developers to feel a sense of ownership over the name "Subversion" 
> because they've contributed to it; I don't want them to feel like that 
> investment (in code or street cred) enriches just one particular vendor.
> 
> The point made last week about thinking about _Crossing the Chasm_ and 
> thinking about the "whole product" resonated deeply with me.  All these 
> disparate projects using the SVN name really should be thought of as 
> part of this "project", speaking broadly.  This list has so far limited 
> itself to core libraries, the server, and the command line client, but 
> it's also the most logical place to start thinking about coordinating 
> the "whole product" as Subversion is know to the wider user community, 
> the same way that other aggregate projects coordinate.  If there are 
> lots of deriviate works that carry the SVN or Subversion name but are 
> outside of the sphere of the "whole product", that makes managing a 
> positive "whole product" experience much, much tougher.
> 
> This is why, for example, the Apache Software Foundation is pretty 
> fierce about protecting the use of its name - they don't want to see 
> people releasing products called "ApachePro" or "Apache++" or "MS 
> Apache", because of that confusion, but also because it's using someone 
> else's name without having earned the right to it.  Even if "SmartSVN" 
> isn't too far from other examples we've allowed, and even if I can trust 
> that the intentions of the SmartSVN developers are to contribute back 
> from time to time, I worry that we're slipping down a slope in a 
> direction we don't want to head in.
> 
> To be clear, I've got *no* problem with companies building commercial 
> and/or proprietary derivative works from Subversion source code.  The 
> more, the merrier, because that should lead (in theory) to more 
> developers and more development across the board.
> 
> To date, seeing examples of this have just been somewhat annoying to me, 
> but I've held my tongue on the basis of "let's see where it goes".  I 
> hoped the community would feel the same kind of urge and eventually 
> someone would say something.  Maybe that conversation has already been 
> had, and I missed it. Or, maybe people are *expecting* CollabNet to 
> provide some sort of leadership here.  I'm sorry to pick on SmartSVN and 
> Marc, and do admit that it was the end of a long week and it was more an 
> accumulation of events rather than specifically SmartSVN.  But am I the 
> only one who feels this way?
> 
>     Brian
> 
> 
> [1] - check it out.  turns out not to be such a hypothetical example.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org