Making an Open Source Application More Successful?

morphex asks: "I've written an application for information and task management called the Issue Dealer that has hundreds of users, many of them very satisfied with how it works. However, new user growth has been slow, and there's not much of a community surrounding it. What can I do to encourage wider use of the application, and what can I do to get more developers interested in development and bugfixing? In short, what's missing in this picture to make it an Open Source success story?"

Comments

Part of the problem here

[sexyrexy]

Is that you're not filling a need. I have also written an issue tracker ([Companyname] Issues) that manages Software, Hardware & Networking, Building Maintenence, and a separate interface (same engine) for customer-related support tickets. I also know two other people who have written such software for their companies. For OSS, or any software for that matter, (or any product, for that matter!) to take off is that it has to fulfill a previously unmet need, or it needs to fulfill that need in a significant way that no existing tool does. If you can articulate why/how your software does this, then things will naturally take their course.

Make presentations about it

[H4x0r Jim Duggan]

A lot of people get interested in technologies when they hear it examplained and can ask the developer - and face to face is much easier than by email.

To really get the value out of it, try to have your presentation recorded (like these from FOSDEM and other conferences). And if you really want to get picked up by search engines and be accessible to deaf users and others with particular needs, event transcripts make for greppable copies of talks and presentations.

version numbers

[Anonymous Coward]

Plenty of people will skip passed applications when version number are < 1.0.

Advertise

[DarthChris]

You need to find ways to make people aware that your app exists, and you need to make them aware of just why they should use your app rather than someone else's. The main issue I have with places like Sourceforge is the sheer number of projects that do the exact same thing - if you can give me a clear advantage of your progam over others, I'm more likely to use it.

follow up on "articulate"

[marcus]

Write an article about it.

Describe the purpose, design, and function. Include whatever clever applications of computer science principles you have used and why.

Interview some users, get their words and ideas down.

Describe current shortfalls or flaws, and where you want it to go and how you plan to get there. Close with whatever special features make it a killer-app.

Proofread.

Spellcheck.

Have a colleague who can comprehend the material proof it.

Submit everywhere *nix articles are published(I assume it is not an M$ app), including here and not just the e-zines, but also the tree-zines. You might even get paid(if a tree-zine publishes you will get paid).

Profit!

What is it and what does it do?

[vrmlguy]

First, the screen shots should be on the front page. I poked around and couldn't find any, then stumbled across them by accident a few minutes later.

You claim to handle "issues and relations". Define those terms. Give me a concrete example of what the tool is used for. Arrange the screenshots to tell that story.

Who are your target users? Tier one support? Tier two? Project managers? All of the above? Have a story for each.

OK, It's about effective communication.

[hey!]

First thing, people need to know you exist. So you got yourself on the front page of Slashdot, well done. Now onto step 2.

Step 2 is, you have to communicate what marketing people would call a "market position". What this amounts to is a succint message which tells the person looking at your product the exact niche it fills that nobody else can.

If you fail to define for yourself what your market position is, your project may have no justification for its existence, unless you luck into it. If you fail to communicate what your market position is, you can't motivate people to bother checking your project out, unless they have a lot of time on their hands and nothing interesting to do. This may artificially limit your user base.

Your web site starts this way:The Issue Dealer is an application for managing information. Well, the same can be said of Oracle. Or the Reiser File system. As you go on, I gradually get the idea what this product does, but you never close the deal. After reading your web site, I still don't make it clear why I'd want to use it rather than, say a CRM with issue tracking, or Bugzilla or Microsoft Outlook. Unfortunately, your demo site doesn't inform the user much more as the data is not very enlightening to somebody who is not part of your project.

You need to come up with a single paragraph that informs the user exactly what your software does that uniquely benefits him. After that the next most important thing is to clear up any misconceptions the user may have that your product is "just like" something he's already familiar with.

For example, let's do a makeover here on the first couple of paragraphs of your front page. Admittedly, it is not very good since I don't know what your product actually does:

The Issue Dealer is a tool that combines the documentation power of a knowledge management system, the organizational impact of an issue tracker, the brainstorming capabilties of an outliner, and the collaborative power of a weblog into a single easy to use system. Organizations use Issue Dealer to make sure that all the important things that come up in the day have a place to go where they will not be lost, whether they are customer support issues, ideas, goals, or reference information.

While it might seem like a system that does all these things has to be complex, it's actually the opposite. Where special sytems gain their power by adding lots of aracane and seldom used features, Issue Dealer gains its power by bringing all your tracking activities under a single roof. Your users will appreciate not having to learn many different systems with all kinds of complicated bells and whistles, or having to decide whether a particular issue belongs in the bug tracker or CRM system. Above all, Issue Dealer is a fun and interactive way for your group to stay focused and improve performance.

Your IT department will appreciate not having to learn how to install and maintain a half dozen or more complex systems built on incompatible technolgies. And since it's web based, installation and deployment is a snap. Because Issue Dealer is Open Source and uses all standard components, your organization will enjoy a high degree of security and flexibility without paying through the nose for it. And while Issue Dealer works with your email system, it isn't tied to it so tightly that your tracking system is affected by the security and scalability issues that often afflict email.

Issue Dealer is ideal for a highly creative small business, or group within a larger business, that's more interested in improving the consistency of follow through than on maintaining multiple systems that do more or less the same thing.

Now, I'm at two disadvantages here: (1) I'm not a marketing guy so I don't really know how to do this professionally and (2) I don't really know what you're product is about. The problem though is after looking at your web page I still don't REALLY know what it's about. There's nothing to motivate me to download and try this thing.

jump to conclusion mat...

[arabagast]

that name instantly made me think of the jump to conclusion mat, don't know why.

My advice would be to simply make an "about" page on your site, explaining different usages and the like. This is often the first thing I check out when I come to a website about a project that is previously unknown to me. Some colors on that website wouldn't hurt either. Remember, first impression counts!

One word: Roadmap!

[LoveMe2Times]

In addition to the other good comments here, I must add that one of the first things I look for from a FOSS project is a Roadmap. One of the primary benefits of FOSS to me, as a developer or potential developer, is my ability to affect its direction. But I need to know where the current developers intend to take it. I'm usually looking to take advantage of the 98/2 rule: get 98% of the work done for me by expending 2% of the effort. In other words, if your project almost meets my needs, then is it better for me to adapt your project rather than start from scratch? Knowing what direction you intend on taking the project helps me make that judgement.

Also, you really need to more prominently display what technologies you rely on. I see burried in the download section that you run on the Zope platform. Since Zope is such an obscure platform, you should mention how easy it is to integrate with other platforms. ie, do you have a web-services interface? Even though you don't make Zope, your potential users/developers probably want to know if you can run it side by side with Java or .Net. For example, since Zope runs it's own webserver by default, you might want to include a link for people who are already using Apache. Since you chose the obscure platform, it's your responsibility to point out this information. Linking to the Zope page and documentation would be a good call too.

Finally, you should just mention up-front that it's GPL. Making me click on a link just to see your "license" makes me think you've made your own. I might skip your project altogether without looking at the license (who wants to deal with another license?), so spare me the trouble and just say GPL.