Hi ya all, I would like to open discussion and collect some thoughts - and why not even best practices - on how people have and are managing Zope-projects that are too big for their companies or go momentarily over their capacity. Like we all know, outsourcing or hiring a contractor is not as straight forward as some people might think. Even with a well written specification - during the production issues might be raised that need elaboration and tightly knit co-opration between the customer and people who do the work. It is no wonder that user centric design and extreme programming ( usecases, usecases, usecases ) have become popular methodologies within Zope development. Distributed development has worked very well, though I'd say that is more thanks to certain individuals who are champions of a certain product or idea and make sure that those issues will be solved - rather than a development style or methodology. The facts that Zope and Plone evolve very fast are possibly issues that limit the amount how much people can and are willing to outsource. Since there are no designpatterns and well known metrics by which to measure developer's work for an non specialist it could be next to impossible to judge the quality of work during the project. Results can naturally be judged by the fact whether software works and meets the requirements. Also because of the nature of development I believe that for a lot of people/companies/organisations doing it by themselves and figuring out problems on their own is essential part of learning the system and becoming also better developers, adding more value to their own intellectual capital. If you would like to extend the framework - you most likely would like to get your new tools included into the framework core and share the future development costs with others. However this adds a new layer of complexity to the project management, since now the requirements are not solely your requirements but suddenly there are others who contribute their thoughs and want to change things. Naturally you could just release the readymade code - but that would not guarantee that anyone would take it and use it - or want to contribute back to it. So - when would I outsource or use contractors? If possible, I would only outsource clear bits of the whole product - something that requires as little as possible continuous communication and co-operation with other teams during the development. Optimal would be that each outsourced bit could be developed as their own separate projects / processes. If we would be talking about doing something that either party hasn't done before - I would definitely require someone from the contractor to join the onsite team if economicly feasible. Same would go if for example the reponsibility of creating an architecture would lay on the shoulders of the contractor. Reasons for onsite work are mainly for transferring ic from contractor to the onsite team, so that the work a contractor does would not create automatic lock in to just that contractor. How to do the work? If possible, a shared coding standard or a sort of concensus would be great. In any case a shared code repository and code review throughout the project would be a must. Tracker to manage bugs and other issues, including changes to requirements - and documentation written during the work, for example to a wiki. Regular meetings online or offline. Irc is good, but it is much better to have voice discussions and shared whiteboard / workspace. Clear metrics by which the project will be judged and payments paid. How others have done it? ( Just a good read : http://www.nwc.com/story/singlePageFormat.jhtml;jsessionid=LZX3DXZCSO1U0QSND... ) -huima