Ever wonder why some open source projects are insanely popular and others struggle to get mind-share? I do, all the time, especially since the “insanely popular” part is what I’m striving for as a Community Manager at Novell. I recently read a great book entitled “Designing for the Social Web” by Joshua Porter. In his book Joshua describes the life-cycle of a user interacting with a website and points out the various hurdles that must be overcome in order to create an active user. This got me to thinking (dangerous) about the similarities shared between the life-cycle Joshua outlined and what open source projects go through. I thought I’d write down my thoughts on this topic before I forgot them
Unaware User -> Awareness -> Interested Potential User
Once you think you’ve got a handle on describing the nature of the problems you solve its time for some outreach. This requires a Press Kit to be effective. What’s in a Press Kit you ask? You should have a simple document that describes your solution and provides information anyone could use to get “their feet wet” with your project. Make sure it is simple and describes your solution in terms of the problem it addresses and not the technology it uses. You also want to make sure you have links to more detailed information, and also contact information for a couple of people skilled in answering questions. Why more than one contact? I’ve found that usually the press have very short deadlines for filing their stories and what if you’re not around?Once upon a time there was an Unaware User who had an unmet need of some kind. In this stage the user has a problem (need) that is unsatisfied and is unaware of your solution. This is our first hurdle. We must make the Unaware User “aware” of our project or solution. This is where marketing and viral effects come in (aka. all the social things that most techies don’t like).
Solve a Real Problem
What does your user have at this point? A need and the desire to solve it, that’s it. So make sure that the information you provide to the user is as clear as possible on what it is you do and what problems you are trying to solve. This means making sure your message is targeted at real problems and that you aren’t just talking about technology when you reach out to a user.
Once you think you’ve got a handle on describing the nature of the problems you solve its time for some outreach. This requires a Press Kit to be effective. A Press Kit is a simple document describing your solution and provides information anyone could use to get “their feet wet” with your project. Again, make sure this is described in terms of the user and not the technologist. You also want to make sure you have links to more detailed information, and also contact information for someone in your project who could answer questions.
Once you have a press kit, read everything related to your niche or industry and find out who the writers are that cover that area. This will give you a list of people to send your information to. You can also create a section on your project’s website and ask your users to submit any bloggers or journalist that cover your space. Once you’ve accumulated your list send a personalized note to each one on the list with a brief summary of your project and why you think it is newsworthy and don’t forget to include a link to your Press Kit.
Work with Other Projects
Of course there are other ways to get the word out. Being an active and productive citizen of other projects is a great way to introduce users to your project or solution. Reputation is an awesome thing. If you have a reputation for helping others and contributing to projects, people will be happy to lend a hand when you need it. You may even already have some followers if you are actively participating in other communities. I recently heard the founders of GitHub talk about their startup experiences at the Open Source Bridge conference. They specifically mentioned their involvement with Rails as one of the reasons they thought GitHub had been successful in the beginning. If that’s not a testament to playing well in the sandbox nothing is.
Find Your Sneezers
Another important ingredient for creating initial awareness for your project is the “sneezer” effect (aka. finding users that spread the word for you). A good way to do this is to focus on a specific set of users and focus on helping them be successful with your project. This is an excellent way to find and attract your initial Sneezer group. The more niche your segment the better. Show some group of users a little attention and they may repay the kindness by adopting and spreading the word about your project.
Interested Potential User -> Usage -> First-time User
So now you’ve cleared one hurdle and you’ve created awareness for your project or solution and have an Interested Potential User. This means you’ve reached your second hurdle which is Usage. Usage means different things to different software projects. It could simply mean visiting a page and getting a user to register for your service or it could mean installation and configuration of your software. If your project is similar to Kablink or iFolder, projects I’m involved in, Usage implies getting users to download and install it on a server. No matter what the process is your job is get the Interested Potential User using your software.
Make Getting Your Software Easy
So what are some suggestions. One, create as many ways for interested users to get your software as possible. Make sure they don’t have to search for the “Download” button or fill out a form to get your software. Also, its a good idea to get them as close to using your software as you can without them having to do anything. One way to let people get their feet wet without any commitment is to have an online demo (works in some cases), or a LiveCD, maybe setup a SuseStudio project that people can use, or a VMware image. The point is to ease the burden of getting involved with your project to a ridiculous level. If its so easy you think your Grandmother could get started using your stuff then you’re in the ballpark:-).
Install should be a “No-Brainer”
But even if they’ve been able to “test-drive” your software they still may need to install it at some point, so again the rule is “MAKE IT EASY”. If your newly found user has trouble with the install and configuration you’ve likely lost them forever. Users poking around looking for a solution to their problems don’t like to drop to command lines or use MySQL clients to install a schema. They want to have everything done for them and feel like a million bucks when they tell their friends how they installed it without any help.
First-Time User -> Understanding -> Regular User
Okay, let’s say we’ve kept our Interested User this long and she is using our software. First, congratulations, you’ve made it a long way. Second, now’s where it gets hard . Our First-time User now has to have the “Ah hah” moment where they “get” what it is we are doing for them. I call this hurdle Understanding. Even with all the messaging we’ve done about solving their problem we still need them to understand and appreciate the way in which we solved the problem. Our new user must have a clear understanding for what it is we do and how we do it. This means complexity is a killer. I don’t know about you but I never read the Help document or peruse the User Guide unless I absolutely have to and that’s usually a very bad thing. If a user has to resort to Help and Tutorials chances are you’ve lost a good chunk of the initial momentum you had. Let’s put it this way. You’d better have some really, really, really good help and gets them back on track quickly.
The Easier the Better
Basically, the goal for overcoming the Understanding hurdle is to let your solution to the user’s problem shine through while not leaving the user scratching their head. Think about some of your most used applications. They are very utilitarian and easy to use: email, Twitter, and the browser come to mind. These all have common characteristics, they are easy to understand and solve real user problems. If users are left wondering where they are in your application or don’t understand the solution you’ve provided you’ve likely went through a tremendous effort to get them this far only to loose them because your application simply didn’t make sense to them. “Made sense to them” is key here. Maybe you solved the right problem but perhaps you did it in a way that was just not intuitive to your target audience. The best you can hope for here is to provide some way that users can provide you with feedback before they leave. If you’ve got some great tips for getting over this hump I’d love to know about them.
Know Your User Through Testing
This is the one that gets most of us. We solve a problem the way we’d like to see it solved. Right?? Well, that’s great if you’re the only one who will ever use your software. If for some reason you’d like to see others use it then … you probably want to do a couple of things. One, release often. Yes, this is the new mantra of web enabled software so I won’t dwell on it. Two, take the time to find a user you think matches your target profile and do some basic testing of your ideas. I recently found a cool program called Balsamiq Mockup that’s free for open source projects and allows you to bang out a quick UI prototype of what your thinking, but even paper prototyping would work, just make sure that you are using real users to test your concepts.
Use Common Paradigms
For all you creative types out there … don’t even think about it. Yes I know you think you’ve built the most intuitive new interface to hit the market in years but you haven’t unless the only person using your software is you . Users get accustomed to doing stuff in a certain way and NOONE LIKES TO CHANGE. I shouted that so I hope you heard me. That new navigation widget you created that is a combination of a Sitemap and Breadcrumbs is NOT a great idea. Why? because it’s new. Users want things they understand and if you’ve strayed to far from the norm they will be confused and confusion is death.
Regular User -> Utility -> Passionate User
At this point you’ve got a Regular User because your solution indeed does solve a valuable problem and fulfills some user need. The next hurdle is converting this Regular User to a Passionate User. Your dreams should be filled with thoughts of Passionate Users everywhere using your software. Why? because Passionate Users are like gold, they provide an endless supply of riches for your project. Passionate Users tell others about your project which helps you overcome the Awareness hurdle. Passionate Users help refine your product. Passionate Users give you access to highly motivated test subjects who endure great hardship in an effort to improve your project. But mostly Passionate Users are your bread and butter when push comes to shove and you need help with your marketing efforts, testing, or adding just about anything. These users are what every software project, or company for that matter, wants and needs to have widespread adoption.
So how is a Passionate User created. Good question, I wish I knew. I’d be filthy rich on a beach somewhere with a Corona in my hand:). What I believe to be the key (and correct me if you think I’m wrong) is that Passionate Users are created through a combination of great Utility in your software and supportive users in your community. That combination is a powerful one. If your software is easy to use, solves real problems, and provides and increasing amount of Utility as users become more adept at using it, I’d say your project has a great chance of creating Passionate Users. However, if you combine great software with a community of users willing to lend a hand to get someone started and make them productive in a friendly welcoming way, I’d say you are well on your way to creating the next big thing .
Passionate User -> Developer Support -> Contributor
In most cases you will probably be thrilled to have an abundance of Passionate Users (I would), but we’re talking about open source here and open source needs contribution from the community. So how do we get our Passionate Users over the next hurdle and get an OSS Contributor? Well I believe the requisite step involves making sure the tools are available that allow people to solve their own pressing needs. Like most software usually some customization is needed to make it fulfill your user’s needs exactly. Projects that provide an architecture that is easy to understand and extend, documentation describing that architecture, and tools that make getting started in development easy (aka. SVN, forums, mailing lists, IRC, code examples, etc) have a very good chance of converting passion to contribution. Think about WordPress. Simple concept, easy to understand, great utility, easy to extend, and guess what? almost 6000 plugins. Wow!
Not only are tools required but you also needs someone to help explain all the subtle nuisances of your architectures and process for contributing. This is where it helps to have a welcoming and helpful community behind your project. The easier it is for new or experienced users to work with your community the more willing they are to help out and try to fix their own or someone else’s problem. This means starting out you may not have many outside users that can help with this. If that’s the case, you’d better make sure that everyone that’s involved in your project participates in your community and acts like you’d want new Passionate Users to act. This means lots of helpful advice, no snippy comments, and plenty of discussion about what problems you are trying to solve and why you’re solving them the way you are. The best quote I’ve heard recently that describes this is … “He who outteaches, wins”.
So, I know this has been a long post but I hope it was worth it. I also would love to hear some of your ideas for clearing hurdles. Leave a comment and let me know your thoughts. I’d better get started implementing some of thisby