3 steps to writing an open source project case study

http://opensource.com/business/15/4/create-community-impact-case-studies

Image by : 

opensource.com

​

Case studies about open source project participants and users are a great way to showcase your project and how it works in the real world.
Such studies will highlight interesting features of your software, demonstrate different (and potentially unique) ways your project is in use, and foster positive communication among members of your community.
Case studies are also about transparency: while talking to the end user of your software, you can also learn about things that are not necessarily running smoothly in your project. And although no one loves to hear about the things that are going wrong, such feedback can also be invaluable to you and your team.
In this article, I'll explain how to create an open source software project case study.

Three basic steps

Putting together a case study is not terribly difficult, and should (depending on your writing style) only take about two hours of time total, including the actual interview time. The three basic steps are:

• Finding a case study subject
• Interviewing the case study subject
• Writing the case study

Finding a case study subject

Often, locating a potential subject for a case study is the hardest part of any case study project. This is often due to discovering potential subjects and then (if you find someone) getting them to agree to participate.
Ways to locate subjects include:

• Monitor your channels for particularly active end-users. Typically, if someone is spending a lot of time on your mailing list, IRC channel, or forums seeking answers to their questions, then it is likely they have a large stake in ensuring your project works in their environment. Many times, that means a production-level deployment, which is what you are seeking.
  
• Monitor your channels for new end-users. If you see anyone new in your channels, check their domain name and use that to learn more about where they might be deploying your project.
  
• Introduce yourself. Reach out to these users. Find out why they are using your software, see if they need specific assistance, and (if they do) try to coordinate their getting in touch with the right person on your team to help them. Along the way, you can learn more about the type of deployment they have (personal or business).
  
• Invite them to participate. You should have a standard invitation email/message to use for case study participation. The invitation should include:
  
• A clear introduction to you and your project if you have had no prior contact
• A straightforward request to interview them for the case study
• An outline of what you will need (length of interview, method of communication, time frame of case study)
• Details of where the case study will be published
• A statement that says they will have final review approval of the case study before it is published

This last point is important. When a journalist writes an article about a person or company, they rarely–if ever–grant final review access to the article. This keeps the article from becoming little more than a positive public relations piece instead of a balanced piece of work. For a case study, however, this kind of review is not a problem. Indeed, it can help assuage any nervousness the case study subject might have about discussing too much about their organization's infrastructure.

Conducting the interview

Once the invitation is accepted, be sure to follow up with the interview subject and work with them to arrange an interview time that is convenient to their schedule. They are doing you a great service by agreeing to participate, and they should be treated with courtesy.
When you schedule the interview, 30 minutes should be fine. Try, if you can, to schedule 30 minutes, but have space on the back end in case it goes long.
Video chats are best, if it can be arranged. (Skype, Google Hangouts, BlueJeans are all recommended.) Phone calls also work well, though are more inclined for interruptions in the conversation.
If you are a great note taker, then do that. But for most people, have a recording made of the conversation. Most smart phones have recording apps. You're not looking for high fidelity, just something to go back and review quotes and important points in the conversation.
There is no set formula for interview questions, as any conversation can take a sharp detour into really interesting threads that you can pursue. But to keep things on track, generally try to get these topics covered for your case study:

• History of the organization
• Events leading up to the introduction of the project
• Implementation/deployment of the project
• Value of the project (SEO, perceived value)
• Technical details (hardware used, number of users. etc.)
• Specific use cases (if applicable)
• Relations with the community

In all of these questions, try to get a balanced view of the topics. Find out if there were any problems along the way. Let your case study subject air any grievances, if any. You may not necessarily include them in the case study, but you can at least take them back to the upstream community as something to improve.
One thing to avoid, unless the subject absolutely insists on this, is sending them a set of questions and having them write out the answers. Very occasionally some people will request this method of interview, but typically that's a lot of work to put on a person and invariably they will take a very long time to reply with their answers.

Writing the next great case study

Pulling together your interview materials into a usable case study is at once pretty straightforward and the most daunting. You have all of the facts and information, but how to write the case study well?
Everyone's got their own style of writing, so this is a very subjective task. One recommendation that might help is try to remember a point in the interview where you said to yourself "that's really interesting." It could be something obscure, but as long as it personally resonates with you then it becomes much easier to convey that personal connection to readers. Build on that point. Lead with this in your case study and make it the hook that attracts people to start reading the article.
As you write the study, always keep in mind that you are telling a story. Yes, it is rife with technical details and IT jargon, but that does not mean it has to be dry. Be conversational, and hit all the points you want to make.
One word of caution: when you do let the case study subject review the draft of the study, be sure not to let them add blatantly marketing-oriented phrases like, "the number one maker of widgets" after their company name. Even innocuous phrases like "an industry leader" are self-serving and can skew the effect of the entire study. If you are patient and explain that the study alone is worth some positive press on its own, most case study subjects will be understanding.

Post-case study tasks

Once the case study is complete, reviewed, and posted on the appropriate platform, be sure to share it with your community directly, as well as through any social media channels your and your community might have. Of course, now is not the time to rest too long on your success. Given the length of time it can take to locate case studies, you may need to start looking for another case study candidate soon.
The work will be worth it. Case studies are a great way to highlight the success of your software project and share some attention with community members. It's a win for everyone, with only a small investment of time.