[Koha-devel] A Discussion on A Policy Setting Forth Standards of Code Submission, etc. [WAS: RFCs for 3.4 from BibLibre (serials & acquisitions)]

Nicole Engard nengard at gmail.com
Tue Nov 9 13:39:09 CET 2010


On Mon, Nov 8, 2010 at 9:45 PM, Chris Nighswonger
<cnighswonger at foundations.edu> wrote:
>>> 2. Given the problems we already have with a lack of development
>>> cooperation, this scenario at best does nothing to address those problems.
>>
>> This comes back to the question of whether you can force cooperation.  I
>> don't think we can, effectively.  I support codifying expectations and best
>> practices, but "requiring" disinterested, competing or downright hostile
>> parties to cooperate or pretend to cooperate seems destined to fail.
>>
>
> By the very nature of things, a project such as this entails a
> practical requirement of cooperation among competing parties. Just
> look at all of the vendors participating. While the vast majority are
> kind and well mannered toward each other, they are, in fact, in
> competition with each other in some sense of the word. And I'll not
> revisit my discussion of the fact that vendors and customers are in
> the business of "requiring" and "forcing cooperation" with each other
> all of the time in those little pieces of paper we call contracts. Now
> this is not to suggest that we begin any formal contractual
> relationships or that we attempt to "force" cooperation. But the
> recent work by ByWater and Software.coop on the EDI code and Catalyst
> and Biblibre on Biblibre's work illustrate that it is not beyond the
> realm of reason to expect and even strongly encourage competing
> parties to cooperate for the benefit of the thing that earns their
> bread and butter. And as for downright hostile parties, they should go
> elsewhere until they can leave off some of their hostility, imho.

This reply fits with a lot of what has been discussed in this thread
and it's not even my own words.  During a moment during the hackfest
we talked about vendors and their customers' expectations.  Someone (I
can't remember who) mentioned that we have to educate our customers
about the world they have just entered.  Basically they can request
features from us, but if those features are not guaranteed to be put
into the final product the way they spec them out.  Instead educating
our customers that they have entered a new way of working and
collaboration might make it a bit less likely that vendors run off on
their own and work in a silo.  Also Paul mentioned (and I love this)
that he doesn't think he has any customers who would fight this
process - that if he told them he can give them the feature they want
but it needs to be changed a bit in this way or that they would
probably agree to his suggestions because his customers are in it for
the open source aspects and I hope everyone else's are.

So, it doesn't really 'force' cooperation but it does make it easier
for us to cooperate if our customers understand the process of getting
their development ideas into the final releases of Koha.

Nicole C. Engard
ByWater Solutions


More information about the Koha-devel mailing list