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