On Mon, Nov 8, 2010 at 9:45 PM, Chris Nighswonger <cnighswon...@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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
