Slashdot Mirror
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?"
Well, it does help to post a question about it to "ask slashdot". I did the same thing 3 years ago with my num-utils programs. After that, I definately saw increased usage and it was added to a few Linux distributions. If you're lucky, the same will happen to you.
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.
Rex is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
You certainly have a winning interface.
OSS is hard to make successes with because, most often, the market is flooded with options, (lots of products), and most applications have, well, very specific applications.
FanFictionRecs.net
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.
Please help publicise swpat.org - the software patents wiki
The name is too comprehensible, and one might get a clue as to what it does. Try emulating a succesful project and change it to something like "Ekiga".
Plenty of people will skip passed applications when version number are < 1.0.
Ian
Get Oracle to buy you. Because, you know, as Larry Ellison says, "Open source becomes successful when major industrial corporations invest heavily in that open source project."
First, check out the book Producing Open Source Software, I found it to be a very informative read. As a starting place, your website needs a little help. It's a little bland but that's not the big problem. It needs to be obvious right-away how I, as someone interested in the project, can get involved. You have the mailing list info which is a good start but a look through the archives proves to be quite lacking activity. Your three target groups are end-users, hackers, and developers. How would someone start "hacking" or just playing with your software? Give them some documentation. What is the process for becoming a developer? Where do I submit patches, how do I get commit access to the repository? Where do I submit bug reports?
You need to also ask yourself if you're really ready to release this as an open source project. I don't mean literally under an open source license, like you have done. I mean, are you ready to let a community of developers and users take control of your project and take it in directions you may have not considered? It's been your baby so far (from what I can tell) so this could be quite a change for you but the rewards could be great.
Bradley Holt
I'm afraid you'll need to steer clear of such eunuchisms as “issue”: you'll attract wives (lower-case double-U) and other fickle audience.
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.
Don't you just hate it when people reply to your signature?
Or, maybe an MBA project for one /.'ers who are going for that degree and publish the project on Freshmeat or something? Why not? I've never seen a F/OSS project that deals with the business side. Maybe it's time for that.
Saturday is April 1. Slashdot will be shut down. Sorry for the inconvenience.
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!
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
1. Spam Slashdot
2. Create a webpage that gets a message across... "The Issue Dealer is an application for managing information" could mean anything.
Conformity is the jailer of freedom and enemy of growth. -JFK
At least for Linux usage, one of the best things you can do is to get your package into major distributions, so that when users are looking for something like your tool, they'll find it in the most accessible, easiest-to-install place. For commercial distros, this is a somewhat difficult thing to do, but a lot of desktop Linux users use a community-oriented distro, like Debian, Ubuntu, Fedora, etc. In most cases you can get your package into those distributions simply by creating the package and then volunteering to maintain it.
When creating the package, think hard about the description. You want it to be relatively brief, but accurate, and with all of the terms people would search for when looking for your package, but avoid "spamming" the package search. Also, make sure that your packages install and unistall very smoothly and cleanly, and do everything possible to ensure that the installation process requires no manual configuration steps. It's fine (and good!) to allow the user to tweak the configuration later, but try to give them something fully functional and usable right after the automated installation.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
Nothing for 6-digit uids?
"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?" you just did it.
Fascism is the greatest political ideology ever conceived. Sorry.
1. Post it on Sourceforge.
Open Source advocates often search sourceforge for projects that might fulfill their needs. Plus, sourceforge helps you build a community, and external people can analyze your sourcecode directly without having to download the tgz. It also gives you the advantage of having version control systems for the development.
2. Build a community, make a forum.
A community is very important, and user forums are a MUST. If you don't have forums, you also make the impression that your program is a "single user" program (single user programs often lack quality due to not enough user base, beta testers, etc.) and that its support might finish unexpectedly. (Making developer forums is also encouraged)
3. Revamp your website.
Finally, try to make a more impressive website, having a dull website can scare potential users away (typical thought: "if they program the same way they make websites...").
Compare a typical open source website before and after redesigning the webpage. Which one looks more appealing? By personal experience, I can tell you that if new users have to choose, they'll choose the software with better webpage, regardless of the software quality.
4. Advertise.
Finally, try to advertise in more places, make your webpages google friendly, etc.
There's sure enough already several other similar solutions out there which compete with you. So you should do something the others haven't done. Something which is obviously visible in the eyes of your users. So I propose first see that the GUI of your application fits the users and for that go to wyoGuide (http://wyoguide.sf.net/).
Of course there are countless other things you could do but concentrate on the important things first and do the rest afterwards. Just think the best advertisment you get is your happy users talking about your application.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
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:
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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!
Doolittle :
Bomb no.20 : To explode of course.
It might sound like a triviality, but you should chose a lower case name for the files you offer for download. Most linux users don't like upper case file names ;-)
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.
.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.
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
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.
Yes - rumours of Oracle buying Zend Technologies last month account for the steady and rapid growth of PHP since 2000. Not only is Larry right, he's capable of flattening space-time. Yay Larry!
29 mpg. YMMV.
1) Make a PDF brochure for your software. No more than two pages long and with pretty colors.
2) Programmer's Guide. Your product has got to have quite the draw for me to wander through source code trying to figure out what it is doing. Don't make me guess about database tables or magic numbers and magic words in the table that do this or that.
3) User's Guide. Most people who use it are not going to be computer types.
4) Fresh meat, slashdot, make a demo available for computer mags, etc.
First of all, make sure the program is ready to be released.
It has to be WELL and COMPLETELY documented! If there's no useable manual, then it's just another beta. I use a program routinely that's robust, full-featured, and poorly-documented. There are endless features I can't suss out, because not only are they undocumented but what they're tied to is also undocumented.
The user interface has to be as close to standard as reasonable, and has to work well. If it's obtuse or painful to use, it'll get tossed in the garbage ASAP.
The code needs to be written properly. In other words, clean, efficient, robust, and portable! If for instance it needs gcc version 4.4.2.3.8.1.0b (as opposed to any ANSI C compiler), then it needs fixing. If it needs gmake (as opposed to make) then it needs fixing. If the man page requires groff instead of troff, then it needs to be burned to the ground!
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
I've looked at your software several times, and each time I worry the GPLed sub-app will get orphaned - so I go with OTRS. sorry
nice app.