This content originally appeared on Laura Kalbag’s Blog Posts and was authored by Laura Kalbag
Previous posts on the mentoring project:
- [Mentoring a project: the idea](/mentoring-a-project-the-idea/” target=”_blank “Mentoring a project: the idea”)
- [Mentoring a project: the right project](/mentoring-a-project-the-right-project/” target=”_blank “Mentoring a project: the right project”)
- [Mentoring a project: finding the right people](/mentoring-a-project-finding-the-right-people/” target=”_blank “Mentoring a project: finding the right people”)
- Mentoring a project: the project
It’s been far too long since I wrote about the mentoring project. I’ve been incredibly busy and really needed to dedicate more time to make it a success (more about that in another post!)
Last time I wrote about the project, we had just started to get the contract sorted. I use an evolved version of Andy Clarke’s Contract Killer for my client projects. Over the last four years I’ve amended it, and added in extra chunks, to prevent myself from repeating the same mistakes on multiple projects.
I reused this contract again for this project, adding in some extra text about my responsibility as a mentor to the client and mentees. We then decided, prompted by the client’s desire to potentially share the code with other community projects, and Yago’s knowledge of Creative Commons licenses, to license the code under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.
Licensing code
It’s an interesting and important part of the contract, and merits discussion. Previously I had always used the Contract Killer’s lines about licensing where the client has all the rights to the graphics/design elements, whereas the developer has the rights to the code and licenses it to the client for one use.
This always seemed to make sense to me before, it restricts the client from rehashing your code for a different project, or even reselling it to others. But code is not a static one-off document. A website, and subsequently its code, is a living document which is usually frequently updated, fixed and improved upon. How does this then work with a one-use license? Are we then telling clients that if they need any code to be changed, they must re-hire us for the job? This wouldn’t work for most client-developer relationships. As an industry, we seem to have mostly moved to a model where we give clients the tools and knowledge to keep their own sites updated. Maintenance contracts are a thing of the past for all but the most complex systems.
Yago found the perfect license for our particular case, where we wanted to allow the client to share the work on a not-for-profit basis, but I do urge you to look into the correct license which really makes it clear what the client is and isn’t allowed to do. And the wonderful thing about Creative Commons is that they write the licenses in plain English. This means the licenses work with the Contract Killer, and also makes it easy to find the best license for the job.
It all takes time
Sorting out the contract took a lot more time than I’d have liked. When so many parties need to sign a contract, it can take a lot of to-ing and fro-ing before it’s agreed upon. Add in email-based communication and people working on the project part-time, and it took us a good couple of weeks to get it all ironed out. Far too long.
I use Right Signature to get documents signed online, and I was jumping into it too quickly. It’s fairly quick to email a PDF (or even better, pasted text) of the contract for all the signers glance over before they need to sign. As fantastic as Right Signature’s sequential signers option is, it’s a complete pain if you get to the last person to sign the contract and they need to make an amendment!
After the contract
Once the contract was signed, having roles within the project actually become useful. Whilst I expected Yago, Sibylle and Phil to work as hybrids, collaborating on design and development, their responsibilities to lead on front-end development, content and WordPress and design (respectively) meant each could be responsible for planning more in-depth requirements for that area. These requirements took a while to nail down but provided a structure to work from, and gave each mentee a better idea of what the others were doing.
One comment
Read the original post, 'Mentoring a project: contract and kicking off'.
This content originally appeared on Laura Kalbag’s Blog Posts and was authored by Laura Kalbag
Laura Kalbag | Sciencx (2013-05-07T18:58:42+00:00) Mentoring a project: contract and kicking off. Retrieved from https://www.scien.cx/2013/05/07/mentoring-a-project-contract-and-kicking-off/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.
Moreover, by using a license that permits re-use, modification, etc., you are clearly saying, “I am not locking you in to my services, if you’re not happy, you can go else where with no problem; I’ll try and keep you happy”. And I think that’s valuable in and of itself.