I think this gets at the crux of the problem that the community has been dealing with for some time. As I understand it, Liblime's customer insisted on development somewhat off the grid so they were sure to get *their* deliverable. So the farther away their development got from the community version (and no one in the community had any way of knowing what was in that other version), the bigger the hurdle has become for integration. One *could* blame the situation on the customer...<div>
<br></div><div>I hope that after KohaCon, a clear procedure is established that guides developers and people who contract with developers to ensure that development contracts include re-integration of the contracted code into the community version.This "development in the dark" approach has resulted in lots of good enhancements AND new features that are based on very old code making them nearly impossible to integrate into the community version. And there are conflicts between features because the 'has been dumped at the door of the rest of the community to resolve.This in turns slows down everything else. Part of the reason 3.2 has been delayed has to do with this very issue....trying to integrate as much of the Liblime/PTFS code that was based on an older version of Koha.</div>
<div><br></div><div>I believe it should be the job of the developer to ensure their code is based on the current version of the product and not leave it to the rest of the community's developers to wrestle with. If it is the job of the developer to do that, they will ensure that this process is written into contracts with customers. Then, when customers insist on developing huge blocks of code (multiple new features), they will know what that means --- a much bigger cost to them because of the gargantuan effort involved in getting their final product back into the community version. </div>
<div><br></div><div>The customer must also be made to understand that the "code in the dark and don't share 'til it's all done" approach -- that takes months, if not years -- is not only more expensive (assuming we expect the customer to pay for the ultimate re-integration of the code) but it is likely that they will not get the same product in the end because of the inevitable conflicts. I doubt that the client WANTS to stand alone on their own unique version of Koha. I doubt those conflicting features were so important that they were worth not having access to the rest of the community's contributions? I suspect if the features had been developed as Paul described (in the RFC light of day) they would have resulted in conflicts. </div>
<div><br></div><div>In other words, if the process hadn't been in the dark, the client probably could have had their cake and eat it too. Maybe even eating it right now. </div><div><br></div><div>Lori Ayre<br><br><div class="gmail_quote">
On Fri, Jul 2, 2010 at 6:33 AM, Paul Poulain <span dir="ltr"><<a href="mailto:paul.poulain@biblibre.com">paul.poulain@biblibre.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Le 02/07/2010 09:46, Stacy Pober a écrit :<br>
<div class="im">> AIR, the policy says that sponsored software featureswill go<br>
> through a testing cycle with the sponsoring organization, then will be<br>
> released to other Liblime customers for six months. After that, the<br>
> code will be released to the larger Koha world.<br>
><br>
</div>BibLibre devs are fully & always available.<br>
I have recently explained on koha-dev mailing list that we face big<br>
problems to merge our code into main repo.<br>
<br>
I can't imagine it will be possible to merge after : time to develop +<br>
time to validate by the sponsoring org + 6 months ...<br>
(not counting features that will have been developed in // by the<br>
community version, just speaking of the technical pain !)<br>
<div class="im"><br>
--<br>
Paul POULAIN<br>
<a href="http://www.biblibre.com" target="_blank">http://www.biblibre.com</a><br>
Expert en Logiciels Libres pour l'info-doc<br>
Tel : (33) 4 91 81 35 08<br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
Koha mailing list<br>
<a href="mailto:Koha@lists.katipo.co.nz">Koha@lists.katipo.co.nz</a><br>
<a href="http://lists.katipo.co.nz/mailman/listinfo/koha" target="_blank">http://lists.katipo.co.nz/mailman/listinfo/koha</a><br>
</div></div></blockquote></div><br></div>