Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Making an Open Source Application More Successful? 43

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?"
This discussion has been archived. No new comments can be posted.

Making an Open Source Application More Successful?

Comments Filter:
  • by suso ( 153703 ) * on Monday March 13, 2006 @03:31PM (#14910440) Homepage Journal
    Well, it does help to post a question about it to "ask slashdot". I did the same thing 3 years ago [slashdot.org] with my num-utils [suso.org] 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.
    • by Black Parrot ( 19622 ) on Monday March 13, 2006 @06:17PM (#14911793)
      > 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.

      Well that's strange. I posted my "for a hot night" advertisement^w question to Ask Slashdot three years ago, and I haven't gotten a single phone call!
    • I have to agree: After seeing this post, I tried out your demo -- and lo and behold, this is precisely the kind of easy-to-use app I had been looking for my department. Chalk up some more users!
  • by sexyrexy ( 793497 ) on Monday March 13, 2006 @03:34PM (#14910463)
    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.
    • 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
  • Interface (Score:3, Interesting)

    by JordanL ( 886154 ) <jordan,ledoux&gmail,com> on Monday March 13, 2006 @03:36PM (#14910471) Homepage
    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.
  • by H4x0r Jim Duggan ( 757476 ) on Monday March 13, 2006 @03:36PM (#14910474) Homepage Journal

    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 [free-electrons.com]). 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 [www.ifso.ie].

  • Clearly... (Score:4, Funny)

    by Anonymous Coward on Monday March 13, 2006 @03:37PM (#14910483)
    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".
  • version numbers (Score:3, Insightful)

    by Anonymous Coward on Monday March 13, 2006 @03:42PM (#14910529)
    Plenty of people will skip passed applications when version number are < 1.0.
  • version number (Score:5, Interesting)

    by ianturton ( 655126 ) on Monday March 13, 2006 @03:42PM (#14910531) Homepage
    If you bump your version number to 1.0 you may well see take up increase. We certainly saw that with GeoTools [geotools.org] Version 1 never got beyond 0.96 beta. When wee restarted with version 2 we decided to bump the version number regularly and are now at 2.2.0 and 2.3.x. Usage certainly went up

    Ian

  • Simple (Score:4, Funny)

    by killmenow ( 184444 ) on Monday March 13, 2006 @03:42PM (#14910535)
    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."
    • 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!
  • by mysqlrocks ( 783488 ) on Monday March 13, 2006 @03:44PM (#14910551) Homepage Journal
    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?

    First, check out the book Producing Open Source Software [producingoss.com], 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.

    • 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 my pet project for quite a while now, and yes, I'm ready to let go and let it grow up. I guess one of the things I should do is make it more accessible to developers, but noone has r

      • You are welcome. You're right, it is a chicken-and-egg problem. I think you need to make it accessible to developers and hackers first in order to make the project feel welcoming even if no-one has specifically asked yet. People may have seen your website, "asked" the question to themselves, and then assumed that new developers where not entirely welcome (I am not saying that you are not welcoming new developers, merely that it could appear that way). The book I linked to goes into a lot more detail and exp
    • As a starting place, your website needs a little help.

      Seconded. Especially for end-users. Your product is a little more technical, so you don't need something perfect, but try to clean it up a little (have clear menu access to all the key parts of your site, organize the content a little better instead of having most stuff on the front page, have a news section for major updates/events, etc.). Also, make sure that it displays well in a variety of browsers (especially since with a technical audience, you'r

    • As a starting place, your website needs a little help.

      Thirded. Your site is lacking a lot of details I'd expect to find about an application.
      • System Requirements - Your install.txt file is the only thing that specifies a Zope version - i don't want to download an archive just to find out what it needs to run.
      • Install Guide - I know you have a fancy shell script installer but what about people that want to do it manually?
      • User Documentation - I don't want to have to download the archive to find some half
  • Advertise (Score:3, Insightful)

    by DarthChris ( 960471 ) on Monday March 13, 2006 @03:58PM (#14910668)
    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.
  • by AnonymousPrick ( 956548 ) on Monday March 13, 2006 @04:11PM (#14910772)
    Which brings up an interesting issue: get marketing folks involved with F/OSS?

    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.

  • 1. Spam Slashdot
    2. Create a webpage that gets a message across... "The Issue Dealer is an application for managing information" could mean anything.
    • I agree with #2. "managing information" is just too vague. I can manage information with my cellphone (phone book) or manage information with my kids (shave the cat one more time and theres gonna be a beating!). The project needs focus, and serious polish. Your website shouldn't look like those old IBM websites of 1994. Flash and flair shall get you there.
  • by swillden ( 191260 ) <shawn-ds@willden.org> on Monday March 13, 2006 @04:54PM (#14911138) Homepage Journal

    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.

  • by vrmlguy ( 120854 ) <samwyse.gmail@com> on Monday March 13, 2006 @04:55PM (#14911145) Homepage Journal
    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.

  • "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.
  • 4 practical advises: (Score:3, Informative)

    by Spy der Mann ( 805235 ) <spydermann@slashdot.gmail@com> on Monday March 13, 2006 @05:11PM (#14911268) Homepage Journal
    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 [archive.org] and after [codeblocks.org] 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.
    • 3. Revamp your website.

      Definitely a major point. I spent several minutes poking around this web site trying to figure out exactly what this program does, what it looks like, and why I'd want to use it. I finally found the screen shots, but while they tell me what the program looks like, it gives me no overall picture of the functionality in terms of RW use, let alone why I'd want to use it.

      If you're trying to attract users, at the very least you need to give them an up-front look at your program,

    • Post it on Sourceforge.

      Do you think that SourceForge is better than Freshmeat? I search Freshmeat when I'm looking for something, and read the front page regularly. I go to SourceForge when referred to a specific project or to file a bug report. The standard Freshmeat format provides more information than the default SourceForge home page, though some projects have elaborate and informative home pages on SourceForge.

      This also makes me think of a recommendation for the poster. If your software does s

      • I agree completely - Freshmeat is for announcing new FOSS software while SourceForge is simply for hosting FOSS projects. There are many projects that are announced on Freshmeat but are hosted independently, so Freshmeat is the best place to look for interesting projects.
      • > Do you think that SourceForge is better than Freshmeat?

        I'm not the poster of the message you're replying to, but here's my $.02

        Yes; from the standpoint of lending legitimacy to a project, outside of the core tech community, SourceForge is -much- better than FreshMeat.

        FreshMeat is extremely techie-friendly, and probably equal to or superior to SourceForge within that community. But realistically, there are a -lot- of people who aren't as tech-oriented. For these people, the existence of the project on S
  • 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/ [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 you
  • by hey! ( 33014 ) on Monday March 13, 2006 @05:18PM (#14911327) Homepage Journal
    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.
  • 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! (Score:3, Insightful)

    by LoveMe2Times ( 416048 ) on Monday March 13, 2006 @06:49PM (#14912032) Homepage Journal
    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 [zopewiki.org]. 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.
    • For better or worse, Zope is certainly not an obscure platform. Sure, it's not PHP, but it's the most popular framework in the Python world and it's a really nice application server. Check out Plone to see what it's been done with it.
      • I beg to differ. Just because you and I know what it is doesn't make it mainstream. In fact, obscure is reasonably accurate, I think. The most popular framework in the Python world doesn't add up to much. You made me curious though, so I did some checking around:

        Poking around shows that there's virtually nil uptake in the business world: Dice.com shows a grand total of 9, count 'em, 9 jobs for Zope across the country (USA). Surprisingly, Ruby on Rails shows more business uptake, with about 37 jobs post
        • Thats a very good and concsie reply. I see a business opportunity in measuting popularity here. Whats it called? A mashup I think. I conduct my research in much the same way as you using the same sources. Its a great way to measure the pulse of a technology/program/platform.
  • 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 i

You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page

Working...