[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: proposed export option

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 27 Apr 2010 13:11:32 +0200

On Tue, Apr 27, 2010 at 01:57:28AM -0700, Paul Breen wrote:
> For anyone who's interested, the details of the project I'm working on
> can be found at
>
> www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBidRequestId=1395905

Hi Paul,

On the above linked page, your client says:
"Following the coding guidelines for the project should be sufficient
to allow your contribution to be accepted."

This statement is not true and very misleading.
There a large number of other factors at play when contributing to
an open source project such as Subversion.

Of course, anyone can add specific features to Subversion for a client
and provide them with a custom Subversion distribution.
But if getting your work integrated into the official Subversion
distribution is part of the deal, you should be aware of the
implications of this.

Karl Fogel's book "Producing Open Source Software"
explains the implications well, especially this section:
http://producingoss.com/en/money.html

Quote of a relevant paragraph:
"""
Although money needs to be used carefully, that doesn't mean it can't
buy influence. It most certainly can. The trick is that it can't buy
influence directly. In a straightforward commercial transaction, you
trade money for what you want. If you need a feature added, you sign a
contract, pay for it, and it gets done. In an open source project, it's
not so simple. You may sign a contract with some developers, but they'd
be fooling themselves — and you — if they guaranteed that the work you paid
for would be accepted by the development community simply because you
paid for it. The work can only be accepted on its own merits and on how
it fits into the community's vision for the software. You may have some
say in that vision, but you won't be the only voice.
"""

So, the straightforward commercial transaction exists only between
the consultant and the client. If the client is happy with a custom
Subversion distribution provided by the consultant, all is fine and easy.

But when it gets to getting your work integrated into the project,
I think the second to last sentence sums up the situation much better
than what your client wrote:
"The work can only be accepted on its own merits and on how
it fits into the community's vision for the software."

So, with all that said, here is my own opinion:

The feature being suggested only applies to one particular use case.
From the point of view of your client it may well be worth adding because
it fixes a problem for them (it is unclear to me what the problem is exactly,
but that doesn't matter for the purpose of this discussion).
But from the point of view of the community, it may not be worth adding
because the majority of users won't benefit.

To see why, imagine requests for other options such as
  svn export --skip-files-bigger-than-10MB
  svn export --skip-files-containing-java-code
  svn export --skip-empty-files
Why should a general-purpose version control system address such
needs with an endless amount of command line switches, each geared to
the needs of one particular small subset of users?

In my opinion a new feature should:
 1) fix a well understood general problem
 2) fix it without getting in the way of other features
 3) fix it in a way that is general enough to be useful to all users
    who face the problem

You may get a different list of items if you ask other developers,
but in general you will need to justify the necessity of your
new feature based on the above and/or similar criteria.

Stefan
Received on 2010-04-27 13:12:22 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.