Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Technology

HOWTO Go About Marketing to Developers? 268

Posted by Cliff from the where-traditional-marketing-strategies-fail dept.
byrnereese asks: "My company has finally realized that one of the keys to our success will be to create a strong developer program (IBM's Developer Works, and Palm's PalmSource come to mind as examples). It just so happens that I have been appointed to lead this program. Now I have a lot of my own ideas, but I wanted to ask a large developer community directly the one question I know I am going to have to articulate a coherent answer to at some point: 'What is the most effective way to market a toolset, or development platform, to a developer in order to encourage them to build products using your product, without turning them off at the same time?'"
This discussion has been archived. No new comments can be posted.

HOWTO Go About Marketing to Developers? More

HOWTO Go About Marketing to Developers?

Comments Filter:

  • FREE, As in Beer. (Score:2, Insightful)

    by mass ( 65691 )
    FREE, As in Beer, as in give it away. Charge for support, instead...
    • This isn't a troll- this is the exact answer. It may not be viable as a business model- but if you want a bunch of people to use your stuff, give it away.

      .

      • Re:FREE, As in Beer. (Score:2, Insightful)

        by Zurk ( 37028 )
        Palm did the exact same thing initially -- they gave away the OS (ROM dump of several versions of debug OS), devtools, emulator etc etc.
        They still do if you sign the NDA and fax it to em.
        They sold the hardware with the non debug OS.

        do the same. give away a DEBUG version of your tools which cant be used in production and SELL the complete non debug production version.
        just dont make the debug version an eval or time limited. let it print gobs of debug messages and make it bleeding edge.

        That'll be $400 for my consulting fee. Thanks. ;)
    • Doesn't have to be FREE, just provide a nice discount, both Palm and Sony has developer programs that provide nice discounts for the products. They have a 3 per item limit, which is fine to avoid abuse.

      They are also quite open with the specs, Palm provides/helps with free tools (GCC) to compile. This helps the student/hobbiest not feel guilty about spending hundreds for development tools that they haven't used as much as they thought they would.

      • Re:FREE, As in Beer. (Score:2, Insightful)

        by i0lanthe ( 198512 )
        Doesn't have to be FREE, just provide a nice discount, both Palm and Sony has developer programs that provide nice discounts for the products.

        hmmm. The goal of Palm and Sony is to sell hardware (PDAs); as such it makes good sense to give away development tools, emulators, etc., and (when convenient) to provide limited discounts on some models of the hardware for registered developers. Poof! Lots of third party software, lots of reasons for non-developers to buy PalmOS instead of a competitor's product.

        Fundamentally this kind of "free stuff" is about making your real product more attractive to its target audience.

        If the development toolset is the real product, then you can't give it away and survive; you can't even discount it to developers (because your whole market is developers so that would be "everybody"); instead, probably take the crack-dealer approach, "first hit is free, you're hooked now, you pay".

        If instead the development toolset's relationship to the product is "effortlessly [from your perspective] causes the creation of things that make the product itself worth buying", then yeah, cast your bread upon the waters and get it back 1024-fold or whatever... don't necessarily make everything free but make enough of it free (or make enough of the specs open that other people create free/cheap tools) so that the most shoestring-budget developers truly only "need" to buy your actual product, your PDA-or-whatever (and if you have different interchangable gradations, from "minimalist free toolset" to "all-singing all-dancing commercial toolset", you can work the crack-dealer angle back into it after all... here the comparison to PalmOS development tools definitely breaks down because it requires actual effort to move a project's codebase from the gcc-based tools to the commercial tools, so it becomes hard to justify moving in either direction.) And if developers are only a tiny fraction of your real product's real audience, sure, you can probably afford to give developers some discount on the product itself, after you've finished thinking about how cheap you can make the tools.

    • Re:FREE, As in Beer. (Score:2, Insightful)

      by Anonymous Coward
      Charging for support only works if your documentation sucks. And if your documentation sucks, they'll pay for something else. People will pay for documentation, but they'll pay Tim O'reilly, not you.

      If you really want developer mindshare make it so that they don't need to pay for support. This is even more important than free beer, and is the real draw of open source software.
    • Making it a fully backend focused is one possible stategy, others might be to find complementary products to bundle with, write a book and include a limited version of the software that can be upgraded to a full version for a discount, bundle with training at a discount etc. For an excellent start with brainstorming marketing ideas get hold of all of Jay Abrahams marketing material, especially the Protege course [abraham.com] , and get Dan Kennedys Magnetic Marketing [kennedysite.com],if you immerse yourself in it I'm sure you will find the right strategy for your company.

  • The Best Way... (Score:4, Funny)

    by Anonymous Coward on Monday August 26, 2002 @04:45PM (#4143791)
    is to use beer and naked chicks.

    Yep.

    Other than that... having a *good* toolset would help.
    • Yeah, but that's the best way to market anything to anybody.
    • The real best way is to target management, create a toolkit that enables managment to micro-manage everyone of the coders behaviors -- and great report generation abilities. Don't worry so much about how useful it is to the programmer, that isn't the important part..

      Market this directly to management so that they will buy it without even consulting the developers and help them create new "company policy" that makes it the only allowed development enviroment/tool-kit.

      Now, the developers will rise up against this, but do not fear, in this economy they are a dime a dozen... management can just buy some new ones, and measure their success with brightly colored graphs. :)

      (yes, I know I have an evil mind)

  • Make it friendly (Score:5, Insightful)

    by nate1138 ( 325593 ) on Monday August 26, 2002 @04:45PM (#4143793)
    Just focus on the advantages you have over your competition. Unlike many markets, yours isn't full of people that can't tie their shoes. These are the folks building the products and systems people depend on. Many of them are even responsible for making decisions about large technology puchases for their own companies. So basically, don't lie to them, don't overcommit, and simply show why your option is best. Also, having reasonable terms of use is helpful. Nobody I know likes to be told how to use a product that they just paid for.

    • Re:Make it friendly (Score:4, Funny)

      by cjpez ( 148000 ) on Monday August 26, 2002 @04:46PM (#4143809) Homepage Journal
      Unlike many markets, yours isn't full of people that can't tie their shoes.
      I don't know about that one . . . Personally, I avoid the whole issue by wearing boots w/ buckles and straps and the like.

    • Re:Make it friendly (Score:2, Insightful)

      by jrj102 ( 87650 )
      Unlike many markets, yours isn't full of people that can't tie their shoes.
      Sadly, this has not been MY experience. I have met some seriously stupid developers. I don't mean "can't write a decent algo" stupid... I mean "what's the number for 911" stupid. I always thought that the mindset required to be a programmer/developer would act as an intellectual filter of sorts... but alas, that idealism was based on the assumption that everyone in the industry would be at least marginally productive, which is often not the case. Now... Getting back on the thread... I hate to admit it, but nobody seems to have licked this as well as Microsoft. The OSS projects I've worked on did not have very good developer documentation because documentation is not fun. Even companies like Macromedia (I do a lot of ColdFusion work) don't do a good job of supporting developers. However, Microsoft's MSDN is an excellent resource when I'm writing code for people on the dark side. I hate to admit it, but their developer support is one of the few areas where I have to give them some credit. --- jrjones@criticaldomain.net

  • Don't push, Design, Describe & Publish (Score:5, Interesting)

    by lprimak ( 538633 ) <lprimak@nosPam.hope.nyc.ny.us> on Monday August 26, 2002 @04:45PM (#4143796) Homepage
    The subject says it all. Don't push your thing onto developers. Just publish it. If it's any good, people will use it. Sourceforge.net is one place to do it. Design your tool in an OO and component-oriented way, so people can mix-and-match your tool with others they are used to. The biggest mistake you can make is to develop a monolithic "infrastructure" that can't be used interchangably with other pieces and is required for all further development. Noone is going to use that. Publish small components, each of which do a single job really, really well, and then integrate them in a component-oriented fashion. Good Luck!
    • Include a broad spread of working examples ranging from `hello world' level through simple demos and games to a few fully working applications. And dual BSD/GPL licence the lot of it.

      A big draw for me is having somewhere to start, being able to pick up a working app, however small, and stretch it to fit. The dual licencing is needed to enable both proprietary and OSS development based on those examples. BSD to allow BSDish and proprietary stretching-to-fit and GPL to allow Free stretch-to-fits.

      Also, set up a site with stuff like the PERL repository or PHP's PEAR system. Your users will expand your template base for free, benefiting everyone except (possibly) your competition.
      • Another business model would be to license the toolset under GPL, and sell a different license to anyone who wishes to make a non-GPL product. This has the added benefit that anyone can start working on a project, and once they're done checking the feasability, then they approach you for licensing. While the company may lose some sales from that, (fewer unnecessary sales), they will have more user satisfaction.

        This business model can be stretched to include distributing the API in a closed source way, but free (beer), if you license it properly.

        I think the real issue is advertising the product. How do you get your name out?
        If you can get on slashdot, that's good. Advertising on google seems to be pretty good too.
  • Well, that's what most companies seem to think...

    - Freed

  • Don't lock them in (Score:5, Insightful)

    by Myshkin ( 34701 ) on Monday August 26, 2002 @04:47PM (#4143814)
    One of the most important things that I look at is how locked in to a particular product will I be if I use it extensivelly. This means:

    1) If there are standards, support them.
    2) If there are file formats, document them.
    3) If there are APIs, expose them.
    4) If you discontinue support, open source the code.
    5) If the company goes belly up, open source everything.

    • Re:Don't lock them in (Score:3, Informative)

      by Lechter ( 205925 )
      That brings up a good point: if you have good documentation that's also open, so developers can see before they pay, than I think coders will be much more likely to adopt your product. After all, one of the great advantages to Java is the excellent documentation that Sun freely provides.

    • Re:Don't lock them in (Score:5, Informative)

      by 2Bits ( 167227 ) on Monday August 26, 2002 @05:20PM (#4144057)

      2) If there are file formats, document them.
      3) If there are APIs, expose them.

      This is especially important. Good documentation is the best you can offer to developpers. Ok, most of them won't read, but eventually they will, and they expect good docs to be available, when they need it.

      Also, publish examples, a lot of examples, and nice examples too. Publish advanced tricks to do things with your tools. The worst thing I hate about some vendors is, they try to keep everything secret, and hope that you will pay $3K for a 2-day introduction /concept training, then another $3K for first level training, another $3K for second level training, and so on.

      As soon as I find out this, I don't use their products, period.

      Last, and not the least, make your knowledge database searchable on the web, and accessible to everyone, including people who have not paid for the license (yet).

      • Example code (Score:4, Insightful)

        by pommiekiwifruit ( 570416 ) on Tuesday August 27, 2002 @06:10AM (#4147243)

        Also, publish examples, a lot of examples, and nice examples too

        How about this, to distinguish yourself from every other tool vendor: publish examples that don't have bloody big bugs in them that cause you to lose a days work trying to track them down!

        This means when you update the API, you should update the examples so that they work, they use the recommended API, and they are following general good coding practice. Don't fob off writing examples onto someone who

        • (a) doesn't know the api and
        • (b) couldn't code their way out of a paper bag anyway.

        </rant>

        • And (c) test your example code

          This one is nearly as important as avoiding restrictive licenses. (What restrictive is depends on your purpose, of course.)

    • That's a Good Start. I am a cross platform developer, and use other
      companies' APIs on a regular basis.

      Here's my personal wishlist:

      1) OO design is good. c++ is good. Having simple interfaces with a
      uniform (or at least consistant) convention is very good. Having
      non OO (procedural) methods to standard types is also good, given
      the option of both, but not as good. Complexity at need is good,
      complexity by default is bad. Document everything, with examples
      and complete, buildable projects.
      2) Support all compilers and linkers and so forth that you can on as
      wide a range of platforms as you can. This is very important! I
      have had to recommend against outside products that might've been
      much easier than doing something in-house, because they were only
      available on one, or two, or three of the platforms we need to be
      fully supported on. I've had to make hard choices about versions
      of operating systems and libs that I supported because of ABIs of
      outside libs, and I've had at least a couple of run-ins with ABIs
      not being matched on two required outside libraries. If you have
      ever had to dlopen a static linked wrapper designed to call a lib
      compiled on Forte 6.x, in c++, and another calling g++ 2.9.x, and
      replaced the nice OO architecture of the original API with one in
      C, because that's the only way to get the two linked to the same,
      in this case gcc 3.1, c++ application that they are needed in, it
      is with great respect that I salute you, my fellow... (*)
      3) In liu of open source, use a 3rd party "source available" policy,
      which essentially means, there's a copy of all of the source, the
      most recent version, on long term archive in the hands of a third
      party, kept under lock and key, to be released, as stipulated, to
      the customers, alleviating fears of a critical library provider's
      disappearance. This strikes me as a good balance between the not
      so practical open source community policies and the paranoia of a
      company that spends and makes millions of dollars on their IP. I
      won't say much more,
      4) Remember, exposed APIs should not be changed often, and if you do
      find that they must be changed, never make the change subtle. If
      you can, make the change an extension that leaves the behavior of
      the original calling convention intact, and simply adds options.
      5) Don't feel the need to expose internal APIs and architecture that
      may well change, if it does not have anything to do with the APIs
      that expose your interface. Focus on the interface for shipping.
      Implementation details are your business, and nothing sucks worse
      for your customers than having some old-school member of the team
      discover that he can shortcut the interface with some exposed API
      that allows him to get at the raw data and cast it into something
      low level, only to have things break when the next version ships,
      with no easy answer to the inevitable "what the @#!!$ happened?".
      6) If you are going to ignore 5, whatever you do, never document the
      shortcut somewhere deep in a "secrets" book. Whoever that was at
      Oracle, the last rant was aimed at you...
      7) Standards are good. Solid design, with documentation, is better.
      I would rather use something documented that worked. This is not
      a rejection of standards. I prefer things that use standards and
      can be moved to other implementations of the standard. But there
      is a limit to what you can do while supporting an incomplete, and
      many of them are, standard. ODBC is simply not as good as OCI on
      Oracle, and that's why we support OCI based access (and CLI, OLE,
      and so forth for other databases... and ODBC for whatever's left)
      8) Product robustness is more important than flash. Don't overstuff
      the feature set until the core is rock solid. If you are writing
      audio editing libs, don't worry about adding all the catchy sound
      filters... focus on writing a good plug-in API.
      9) Plug in APIs!!! I can't say it enough... give developers a means
      of extending your API. This is critical. And, try to make that,
      as well, as cross-compiler and cross-platform as possible.

      *) I try to compile versions of external APIs for each major target,
      generally meaning native cc, gcc 2.9.x, and gcc 3.2 (now) on each
      platform we support (Linux on several hardware platforms, Solaris
      on sparc v8 and v9, HP/UX, AIX, Win32, MacOS X (X.1 => gcc 2.9.x,
      X.2 => gcc 3.1, carbon => Metrowerks CW 7.x & 8.x), and while the
      original effort was a hassle, the maintainance has been at most a
      20% drain on my time... a single developer. I've recently added,
      on Win32, an initial effort to get Borland C++ working as well...
      I'd really like to see this same sort of thing from other people.

  • nothing gets my attention like freebies. Even if it is cubicle trash, it will get me long enough to look at your product. That is what counts. Email is a NO NO, the spam content going thru the roof ensures that I delete ANYTHING I don't recognize immediately and if I have to take the time to filter it personally I am gonna be annoyed.
  • I would suggest being very open and helpful to developers, they are more likely to stay with you if they are happy and want to do more.
    Community is a good way to expand pr - have some forums and let the developers make their voice heard,
    you will be greatly rewarded...

  • i don't think it's possible (Score:5, Insightful)

    by cballowe ( 318307 ) on Monday August 26, 2002 @04:48PM (#4143820) Homepage
    I pick my tools based on what works, not based on the marketing. I listen to other developers, check news groups and web commentary, and eventually pick the right tool for the job.

    The better the tool, the faster word will spread but it's gotta be a significantly better tool for its intended purpose than what developers are already comfortable with otherwise they'll have no reason to switch. Picking up a new tool requires a temporary drop in productivity - the only way to offset this is to have it be much easier to work with in the long run.

  • Simple (Score:1, Redundant)

    by Target Drone ( 546651 )
    Just hire super models for your sales team.
  • Seriously. Nobody is a bigger pain than a developer (I say this as a developer). If you do, count on considerable support costs up front.

  • easy (Score:4, Funny)

    by Chundra ( 189402 ) on Monday August 26, 2002 @04:55PM (#4143874)
    email marketing [palm.com]. It works, and developers really appreciate the convenience of receiving email marketing.
  • Exactly how much do believe in what your company is doing? The most effective way to market a toolset is atleast not to introduce your company as a collection of morons who do not realize anything.

  • Marketing to developers... (Score:4, Insightful)

    by scherrey ( 13000 ) on Monday August 26, 2002 @04:55PM (#4143878) Homepage
    Realizing the necessity is a great first start. Building a community of users is critical. Without knowing what your product or target audience is, I'd suggest making a strong developers release available for free - you can require registration for activiation, however. Next post as many good, *useful* examples of using your product for people to download. This combined with good documentation and tech support will build a loyal customer base which is worth an enourmous amount of money to a company. Some examples of good communities I've seen are the old Team Borland (circa 1990) where both Borland employees and capable users provided online advice/assistance for their products. The TeamB volunteers received free products/support and each year were actually flown out to the developers conference for free. Another good example in the embedded field is the AVRfreaks ( http://www.avrfreaks.net ) which is a support community for the ATMel AVR embedded processors. I don't know if the site is company sponsored or not but the resources there are great and there's obviously a lot of user-community participation. People looking to decide on whether to use an AVR chip or someone elses will feel a lot more secure choosing AVR thanx to the content of this site and multiple examples of real world usage of their products here. Its a competitive advantage you won't find listed in a checkbox in a trade rag review (perhaps they should) but real-world developers appreciate this more than most things a company actually pays for (like expensive ad-slick campaigns) - it shows they can actually get things done with your product and avoids vapor-promises.

    Good luck!

  • Free is good, not not required. (Score:5, Insightful)

    by haplo21112 ( 184264 ) <haplo@ep[ ]na.com ['ith' in gap]> on Monday August 26, 2002 @04:55PM (#4143882) Homepage
    Honestly if you want me to use your tools:
    1. Good! no Excellent documentation is a must, if I can't figure out at least the basics of how to use the product in about 5 minutes...I don't have time for it...I'll move on to the next guy or just use what I already have...
    a.) Lots of code examples, and documnent everything, assume nothing...
    2. Stright forward use.
    3. have people that have a clue ready to answer my questions if I am still lost.


  • Really, the biggest thing I need to know is of its existence. Then get a limited piece into my hands. I know many people have a development edition for free, only charging for deployed versions.

    For the developer program itself, give me good info that keeps me coming back to the website. Have source code showing examples of less-used features. Have a support database with the most common errors using the tools. Give me a chance on finding the answer myself.

    • Heh. I think you meant *ask* on slashdot.

      I mean, while this isn't the busiest thread I've seen today, it's attracted some attention. Just send a press release to /. announcing that you have developed a new set of tools that's open source, and you can jump start your developer base.

      Shame the original post didn't mention what company/product this was for.
  • Marketing to TV viewers or AOL lusers is a totally different beast than marketing to developers. Save the bullshit and fluff for the morons who will believe it. You can't bullshit a bunch of developers. If your product sucks they will know it! If it has problems -- admit it or else you risk a public humiliation. Let the developers come up with their own uses for your product! Don't lock the developers into your way of doing something (remember the CueCat ???).

    If you sell a good product or a real value-added service than you will suceed. But, developers can root-out bullshit a mile away!

  • Treat them like developers (Score:4, Insightful)

    by maiden_taiwan ( 516943 ) on Monday August 26, 2002 @04:58PM (#4143905)
    - Your product should use industry-standard vocabulary instead of inventing your own jargon for everything. This way developers can understand what your product does and compare it to others.

    - Your web site should contain actual technical information, not just so-called "white papers" extolling your virtues. Put your full manuals online for potential buyers to read.

    - Don't bother sending nontechnical salespeople. We don't speak the same language and just annoy each other.

    - Have a fully functional demo version for developers to try free.

    - Give out a few free copies to prominent developers for review.

    • Some companies made the mistake of sending market droid to the Boston Computer Society PC Technical Group meetings to present. These market droids were eaten alive.

      In 1995 A Microsoft Evengelist said that the Microsoft vision is one PC per person. Of course, when asked how many people had more than one PC, about 90% raised their hands.When asked how many had more than than one PC with them, only a few raised their hands.

    • Re:Treat them like developers (Score:4, Insightful)

      by Amazing Quantum Man ( 458715 ) on Monday August 26, 2002 @05:43PM (#4144207) Homepage
      Have a fully functional demo version for developers to try free.

      Do NOT require an email/snailmail or phone number for this. We don't want marketing BS cluttering up our phones/mailboxes. If we like it, you'll hear from us. Otherwise, be prepared to have a lot of downloads from

      Name: J. Random Developer
      Title: Linux God
      Email: bite.my.shiny@metal.ass.dude
      SnailMail: 123 Any Street, Anytown, AK, 99999
      Phone: 900-FOR-SEXX

    • "- Have a fully functional demo version for developers to try free. "


      yep, with online application for key renewal to extend trial.

      So many times I've downloaded something to have a play, had a quick look then forgotten about it for a while. Then, when I get time to look, the '30 day trial' has expired...

      .02

      cLive ;-)

  • This is easy... (Score:4, Funny)

    by SPYvSPY ( 166790 ) on Monday August 26, 2002 @04:58PM (#4143906) Homepage
    ...just make ads that disparage lawyers, Apple Computer, the government, Star Wars: Episode 1, and forego proper grammar and spelling.

    :P
    • ...just make ads that disparage lawyers, Apple Computer, the government, Star Wars: Episode 1, and forego proper grammar and spelling.

      But then they would be competing with slashdot's content.
  • Easy: Developers listen to developers. If you can find a way to pitch such that the message is backed up by some normal run-of-the-mill geeks, I think thats one key. There's no advertising like word of mouth, so messages should play off word of mouth and basically a demonstrated base of support from the developer community.

    Specs and competative differentiators were ruined long ago by the hyperbole in IT advertising, so those kinds of angles arn't usually so compelling to developers. We like what other developers like, so if you can play off that, that'd be a plus.

    Also, I think developers often look at new products as inventions or software that was just sitting around waiting for somebody to invent them. Companies that act like they are technical gods are a turn off for me; much better to have a company that sells its ability to interact and co-operate with the development world rather than a company that acts like developers should worship them for discovering the 'holy grail' of whatever technology you are selling. We can see past superficial bull, so just act like the girl next door that knows shes nothing all that special, but that she wants to play and have some fun with *us*, and we'll be all over you.
  • They might have a "portal" for developers, but the stuff I need isn't there. Want to make "friends" with developers? How about full (NOT SANITIZED!) Q&A database from the programmers and one that is searchable. Also make it easy for the programmers to enter a new issue. Everything else is secondary!

  • Make it easy to get started ... (Score:3, Insightful)

    by Titusdot Groan ( 468949 ) on Monday August 26, 2002 @04:58PM (#4143909) Journal
    There's nothing worse than seeing a new technology, sdk, ide, or ... and when you install the evaluation the first thing you have to do is become and expert with the new tech. Most successful technologies have made it really easy to download and start trying it out. If I can hook your application into mine in a couple of hours, I'll give it a try -- if it takes two days I won't. Provide lots of examples and make sure your equivalent of hello world can be up and running in a few minutes work. This doesn't mean target idiots, I don't need my mom to be able to install and run in 20 minutes but don't make me read the manual to learn that I have to move some directory into my jdk1.3 directory, edit the classpath, copy a jar file into some other directory and then ...
  • Add functionality and features, but NEVER make it difficult or tedious for the developer to get to the raw code. If your IDE allows you to stick Widget X on the screen, give the developer a very concise, direct way to mess with the true source code of Widget X. That's the biggest gripe I hear when it comes to those super-helpful IDE's.

  • Hookers and Blow (Score:4, Funny)

    by teamhasnoi ( 554944 ) <teamhasnoi AT yahoo DOT com> on Monday August 26, 2002 @04:59PM (#4143911) Journal
    have always worked for me. Our sales are up, and so are our customers!

    Luv, Bill

  • Relevance, Integration, Samples (Score:5, Informative)

    by brio-dude ( 146772 ) on Monday August 26, 2002 @04:59PM (#4143912)
    Relevance

    Show how your product solves problems that developers face when implementing their solutions. Describe how the product works in terms of how a developer sees it. At the same time, describe how it works in terms of the business benefit it provides since the developers will probably influence their manager to purchase the product. Perhaps issue an evaluation guide for developers, and one for their managers.

    Integration

    Show how your product integrates with programming languages, dev tools, and platforms. Focusing on productivity gains, for example, that result from using the product can help developers and their managers make more informed choices - it also gives your product a tangible result (cost savings) that just about anyone can appreciate.

    Samples

    Provide lots and lots of samples - Samples for really simple things and samples of complete, working systems. A lot of a developers' product's success lies in its samples since the samples can be easily modified and integrated into an application, or in some cases, used as the basis of a new application.

  • Top ten (Score:3, Informative)

    by iamsure ( 66666 ) on Monday August 26, 2002 @05:00PM (#4143920) Homepage
    1. No lock-in. Make it easy to switch between tools from rivals, to prove that you care about the developer and want them to try it.

    2. Non-crippled evaluation - No time limits, no nags, none of that. If someone sends me software thats crippled, I let them know thats what I think of their software! (Its crippled).

    3. Downloadable, or overnight shipping - Dont put artificial limits between me liking the idea of trying it and getting to try it.

    4. Unbiased, widespread public reviews of the software. Dont buy reviews. Just hand it out, let em try it and write about it. Stand on the value of the product.

    5. Open-source. I prefer open-source software. I *DEEPLY* prefer free(dom) software, but I know thats rare in the commercial sector. At least let me know that the source is well formatted, well designed, and open to contributions from outside your company by opening the source.

    6. Standards-compliant. I dont care WHAT the product is, there are standards it should follow. Html editor? You betcha. Perl IDE? Absolutely. Follow standards, and shout about it!

    7. Price - Make the price compatible with a developer budget. In other words, super cheap to use at home, and fairly pricey for commercial use. Get me hooked on a product at home, I *will* tell my boss I have to do it to get work done.

    8. Freebies - shameful but true, companies that send me cool freebies do get a little bit extra attention, or at least get a look. I'm NOT talking about magazines. Think toys. Think polo (business) shirts. Think posters.

    9. "The spokesman effect" - Ensure that your company has good spokesmen. Whether in sales, in service, on the phone, or even corporate spokemen.

    10. BABES - I love booth babes.
    • 2. Non-crippled evaluation - No time limits, no nags, none of that. If someone sends me software thats crippled, I let them know thats what I think of their software! (Its crippled).


      1. Give Away Fully-Functional Software For Free
      2. ?????
      3. Profit!

  • There are many good suggestions in previous posts such as well documented API's, source code, examples, good help files, good support, direct contact with your developers, servers to use (such as the strong arm servers compaq opens to developers to write for that processor/platform)

    One suggestion - I've noticed that platform creators like to write about their sdks in trade magazines, on websites, and newsgroups about the details of their sdks and why developers should use them. One good example is Miguel De Icaza and the Mono project. He wrote in detail about it in Dr Dobbs about the technical merits of using the Mono framework on Linux to run .Net applications. That article shed some light on Mono and cast aside the FUD that propogates when you have a void of information. If people don't know your position on the advantages of your platform then they will assume things.

  • No bullshit and hype (Score:3, Insightful)

    by Tablizer ( 95088 ) on Monday August 26, 2002 @05:01PM (#4143925) Journal
    Many of us developers cannot stand it when we see something like, "Our new tool X allows one to use the new Foo paradigm to its fullest. Everybody knows that Foo increases productivity and does the dishes, so we introduced X to help you tap into the benefits of Foo".

    It would be less irrating to see, "Our new tool X helps one get the best out of the Foo paradigm. If your shop is into Foo, then we invite you to look at X."

    Brochures alone are not going to work well on true geeks. We have to see the details. We want to see the API's, code examples, time-limit demos, etc. Vague bragging will just make us click elsewhere because there are too many fluff artists already floating around. If we want fluff, then there are already places to get the fluffiest of fluff.
  • A) Make sure the toolset is really, really good. Developers I know only respect quality - it doesn't matter if a tool is free, if it's flawed in any way people won't like using it, even if mandated by management. This will cost you a lot future sales :) B) Charge a reasonable price, and make licenses as flexible as possible (i.e., floating licenses). C) Back to being good - quality support is a must! I was recently told by a support person "your code is wrong" and got a man-page quote as a reply for something that was clearly a bug in the tool. Needless to say, I will never recommend that product to anyone again - especially because it has a very high price!
  • A dorito-scented CD in a Pamela Anderson shaped box.
  • - Make it easy to find out about your toolset. If at all appropriate, make it easy to download and try out. Provide some good WORKING samples.

    - Answer the phone/email. Developers won't call unless there's no other way to solve the problem. We know that phone and email support often sucks, but some times there's no other choice. At least respond.

    - When we do need assistance, don't have support personnel treat us like complete idiots. Don't get me wrong, many of us are, but we all think we're geniuses and disabusing us of that notion is bad marketing.

  • Tried and true method of brainwashing developers (Score:5, Funny)

    by guttentag ( 313541 ) on Monday August 26, 2002 @05:04PM (#4143951) Journal
    1. Lock the developers in a large auditorium.
    2. Hire a fat, bald man to charge onto the stage and chant "DEVELOPERS, DEVELOPERS, DEVELOPERS" nonstop for 20 minutes, or until one of the following occurs:
      • he collapses from exhaustion
      • the pulsing vein in this temple bursts
    3. Introduce your product/service/ideology.

    • Dancing (Score:3, Funny)

      by GuyMannDude ( 574364 )

      Don't forget that he has to be able to dance in front of the crowd! [theregister.co.uk]

      GMD

      • Re:Dancing (Score:3, Funny)

        by guttentag ( 313541 )
        Don't forget that he has to be able to dance in front of the crowd!
        Ballmer wasn't "dancing," he was "having a heart attack with style."
    • 1. Lock the developers in a large auditorium.
      2. Hire a fat, bald man to charge onto the stage and chant "DEVELOPERS, DEVELOPERS, DEVELOPERS" nonstop for 20 minutes, or until one of the following occurs:
      * he collapses from exhaustion
      * the pulsing vein in this temple bursts
      3. Introduce your product/service/ideology.

      4. ???
      5. Profit!
  • All of these ideas come from your developers using the tools to do development themselves. If you dont like your tools, why will anyone else?

    so here are some things that bug me about current sites:
    1) REAL WORLD applications built by using your development tools (these should be done internally by your best engineers).
    2) The complete API which include:
    - the name
    - the input parameters (lists of all possible values (if reasonable))
    - the output
    - when to use this, when NOT to use this.
    - a link (or links) to where the api is used in the real application(s) from above.
    3) A forum where people can show off the programs they created using your tools.
    4) A regular set of columns describing solutions to challenges that the users of your tools are experiencing. (If you eat your own dog food, these should be pretty self-evident, but feedback from your users will go a long way as well)
  • A good product sells itself, unless ofcourse microsoft has a competing product ...
  • Whatever you publish, simply be honest about it. Unlike business folks, knowledgeable developers (who usually drive tech decisions) are good enough to dissern between hype and fact.

    Also be willing to listen to the community. Sometimes you will not like what you hear, and you have to put your "open mind" hat and listen for real to such comments and see if maybe you are wrong and what they suggest makes sense.

    Another very important issue is support. Who or how will the product/service/technology that you propose be supported? Be very clear about it. Are you in it for the long run or just until you can sell your stock. Will it be a community-supported project, and if yes, what are you doing to get support?

    I'd also recommend you publish as much data about the project as you can, but keep it simple and provide tons of examples. Remember that when a developer can easily understand what something is about, he/she is more likely to give it a try. And if upon giving it a try he/she finds out how easy it is to work with it, your chances of having one more developer on you side increase substantially.

    Finally, provide as many resources in the form of URLs, sample code, tutorials, white papers, newsgroups, email addresses, etc as you can provide. There's nothing more frustrating that working for several hours and then being dead stuck without any resources to help you out on your problem.

  • Honesty, integrity, reliability (Score:3, Insightful)

    by maggard ( 5579 ) <michael@michaelmaggard.com> on Monday August 26, 2002 @05:11PM (#4143997) Homepage Journal
    Be honest about what your product can do. Be honest about what it can't. Be honest about any bugs or misfeatures in your product.

    Keep customers informed about your product. Allow customers to inform each other. Give customers space and tools to work together. Give customers (indirect) access to developers and vice-versa.

    Document everything you can. What you don't explicitly document provide good search tools for (those user-forums quickly build up lots of valuable information.) Code samples, vendors, release notes, manual corrections - get it all out there.

    Let folks know your product development roadmap. If it changes let them know that too. Make it clear when & where you're willing to collaborate on development. Makes sure prices & licenses are fair and reasonable.

    Make technical support a priority. Hire good competent folks. Give them good tools. Make it possible for issues to move from tier to tier of support easily and efficiently. Never leave a customer stranded. Only collect customer information once in a call (we're in technology admit - how hard is it to hand off a customer record?!)

    Finally, watch out for "spin" or "expectations management". Don't treat customers like idiots but consider them as partners (and not like Microsoft considers it's "partners".) Teat folks well and they'll remember it; screw 'em and you'll pay, if not now eventually (look at CA.)

    Developer specific? Get lots of code samples out: Real ones, useful ones, ones that show off your product. Don't have ridiculous requirements. Give folks a really low-cost way of checking out your product before committing.

  • Sexist I know, but evey trade convention I go to for geeks, its the booths with the best bunnies that get the most bang for the buck. T-Shirts are also a great method of marketing.

    Those work well...if you have a good product.

  • promise the sky (Score:3, Insightful)

    by g4dget ( 579145 ) on Monday August 26, 2002 @05:12PM (#4144005)
    Just do what Microsoft and everybody else is doing: promise the sky, make it flashy, and make some simple programs really easy. By the time your customers figure out that they are hooked on another complex, proprietary library/system that really doesn't work any better than anything else, you have them already hooked.

    In different words, as a developer, I view "developer programs" with great suspicion. I don't want to be hooked to some company's product. If you deliver a good implementation of a public standard, I may recommend licensing it for our products. If it's some proprietary tool or non-standard API, forget it.

  • My Personal Rules (Score:2, Insightful)

    by johnbr ( 559529 )
    I got a lot of calls from a lot of vendors for tools and platforms. Here's where they caught my interest:


    1) I could see viable, useful products/applications/software built from them.

    I can't stress this too much. People are always trying to sell me a platform with nothing on it, and keep getting upset/annoyed that I don't "see the potential". Well, color me jade, but I've seen too many "next big things" turn out to fizzle, so I refuse to be first. *Except* when I know the company really well, and they're interesting in having me help them make the product better.


    2) Don't be "buzzword" laden
    As other people have referenced, I hate the fancy "new buzzword of the week" systems that try to make the product seem new and exciting. All they accomplish is to make me feel annoyed and uncomfortable.


    3) 'Is this for you'?
    It would be nice if you had a section on your website that asked a set of germane, intelligent questions about my problems and challenges. At the end it should spit out a rough estimate as to whether this platform/toolset will help me. DO NOT MAKE IT ALWAYS ANSWER YES. WE CAN SEE THROUGH THAT.


    4) Long trial period.
    I like to kick the tires, and I hate having 30 day evaluations. Given everything else in my day, how am I supposed to figure out if this product is useful or not (especially if you called me) in 30 days. Most especially with your first few potential customers, give them a lot of handholding and patience. Let them get used to having it before you ask them to pay for it.


    5) Put up open discussion forums
    I think the Cluetrain Manifesto hit it right on the head here - if I can see raw, unadulterated commentary from the rest of the world, I will feel better that if I like the product, I haven't been snookered.

  • Really - the only way to get my attention is to give me free product, then leave me alone. Assuming the product is a new piece of hardware, UNIX-like operating system (that runs on our environments), or relational database, if you give it to me free as a developer I'll add it to our supported platforms whether we have customers demanding it yet or not, just so I can learn about it. New products need application support to get customers.

    On the other hand, if you try to push it further than that, by continuing to stuff marketing material at me, or worse, spamming me (and a pre-existing relationship is not a license to spam - in fact its evidence that you had the opportunity to seek permission), I'll take it off the list.

    The difference is that the first (free product) shows you're willing do what it takes to ensure wide support for the product. The second (intrusive push-marketing without genuine consent) shows that you have no idea how to do it, and have no respect for the recipient's time.

    This is particularly true of email - while some people might think their time is worth the $0.00 it costs you to send them a spam, the people whose decisions matter value their time much more highly than that, and spamming them is an insult that will have the opposite effect to the one you hoped.

  • How to create a developer community? (Score:4, Insightful)

    by chris_mahan ( 256577 ) <chris.mahan@gmail.com> on Monday August 26, 2002 @05:18PM (#4144042) Homepage
    You have developers in-house.

    Let them connect with developers outside the company.
    (via blogs, mailing list, forums)

    Don't censor them.

    No email.

    A very good online help system (wiki maybe) with feedback.

    Good documentation. Document everything, including bugs, including stuff you're not sure about.

    Work with O'Reilly to have one of your devs write a book on your system.

    Involve outside developers in the design process, taking their feedback. Check out the gaming industry's record on that.

    Make a complete toolkit available for free for "training and development"

    Don't advertise in magazines. It's useless (see how far MS got with .NET advertising?), no amount of advertising can sway developers. We're not teenage girls and you're not selling shoes.

    Make your company web site HTML4 or XHTML compliant, with accessibility in mind. Make it easy to navigate. Make it fast (limit dynamic pages please). Keep links forever. Don't go rearranging subdirectories every five days. Developers like good links (http://www.company.com/support/article001.html) and developers use Bookmarks (or Favorites ATCMB).

    Oh, and no registration on your web site. There will be no teenage girls or corporate executives in the API Reference section in your site. I don't want to give you my name, email, address, phone and sexual preference just to download a zip file.

    If you want to mail something out, then rethink that. Developers live on the net. If it's not on the net, we don't want it. (Sun sent me cubicle stuff once. I now trash all mail from them immediately, without looking at it.)

    Oh, and the documentation should be in:

    HTML downloadable.
    HTML browsable.
    PDF for printing. (make sure the margins are wide enough to hole punch the paper)

  • Either free or free samples (Score:3, Insightful)

    by El ( 94934 ) on Monday August 26, 2002 @05:24PM (#4144077)
    Nobody wants to pay $500 just to find out whether or not something works. If you want the maximum number of developers developing for your platform: 1) Give the SDK away for free or at cost of media.IBM killed OS/2 by charging $2500 for the SDK. Developer relations is NOT a profit center. 2) Support the developers. Give them a forum for questions, emails with tips, etc. Don't charge $3000/year for developer support (MSDN) like Micro$soft does. And don't charge $200/hour to people trying to report a bug like Novell. 3) Make sure the product works before you ship it. If they find problems with the preview release, they're not even going to bother looking at the production release.
  • I tried the demonstration edition of the Blitz Basic 2D programming language, which allows you full access to all of the features except compile-to-executable, and now I'm hooked. Some of the things that hooked me: 1: Free download of operational software. I'm able to develop using the demo, if I want to distribute, I have to purchase. 2: Active support. The programmer behind BlitzBasic 2D is constantly at work on the project, making it better, and he listens to and replies to feature-requests. If there was a bug, he actually worked at fixing it, and sometimes patches or fixes were up within a week or two of reporting them. That is awesome. 3: If I want to buy Blitz Basic 2D, it is not too expensive (~50USD). 4: A great user forum. Of course, nothing makes a great user forum but users, but if you make an "official forum", they will come. Things not to do: 1: Break the software. Blitz Basic 3D is limited to 30 uses. I never even downloaded that program, for that reason only. 2: Give customers shoddy or no support. I develop in a language called Visual Dataflex that has the worst documentation of any development system I've worked with (a lot!). It really ticks me off. 3: Lock up the forums. Blitz 2Ds forums were open to developers who had not purchased the software for quite a while, but were limited to only registered users after about 8 months. That was *almost* enough to make me quit Blitz altogether (if weren't such a good product by itself, I would have).
  • IMVHO, if you're marketing to developers, i'd suggest approaching it with a B2B service mindset. in the eyes of your customers, you're there to help them make their job easier - and like a consultant, you should emphasize how your product can let them be successful in their job. which makes for peculiar constraints.

    - their business depends on the performance of your product. the more they know about it, and the more familiar they are with it, the more likely they will be to evaluate it fairly. also, trust is worth its weight in gold. :)

    - developers are likely to do a thorough comparison of your product with your competition. make sure to provide enough data points to convince then that your product is the best fit for their needs.

    - developers like to try before they buy, especially with something as idiosyncratically personal as development tools. give opportunity to test the product's performance in a real-world situation. (vmware's excellent 30-day license comes to mind).

    - pamper your developers. do all the things you (as a developer) like in a piece of infrastructure, and that rarely appear in low-quality (or open source) products. easy to use tools, clean and powerful APIs, great debugging and tuning facilities, extensive documentation with examples all go a long way towards convincing somebody to pay extra for a particular product.

    as i'm sure you recognize, customer relations are extremely important to anyone in a b2b situation. microsoft is especially good at this, and worth studying in great detail. they pamper but also respect their developers, teach them how to use their system, and go to great lengths to show them how they can make their lives easier by using their products. because in the end, your customers will look to you as someone who makes it possible for them to do their job. and that's the basis of a good business relationship.
  • I should be able to determine what your product is, and why I need it within 5 minutes of being on your website. Don't tell me what it's going to do -for- me, tell me what it really does, and I'd wager the person to best provide the verbage for something like that is going to be a tech that help develop it. Don't tell me it's going to increase my productivity by 50%, or provide a scalable architecture for me to build my applications on... tell me how it's built. I'll know whether or not it's right for me.
  • If you have just been appointed to lead this project, as you say, I would have thought the more important question would be: how should I design the toolkit so that it will be the most effective? (that is, easy to install, easy to get started, flexible, powerful, etc....) What are common problems other people have had with embedded system devkits?
  • - Be straightforward, don't over-promise, & most of all, don't lie

    - Show me sample code

    - Show me documentation

    - Allow me play with it, if I'm interested, for free & without hassle

    - Have solid tech support

    - After I've used it, ask for me feedback and possible enhancements, but give me realistic expections on what can be implemented

    - Make it easy for me to adapt your tool to my process. Don't make me adapt my process to your tool.

    Giving me freebies doesn't hurt either. ;-)

    -Bill

  • Marketing advice (Score:3, Informative)

    by zangdesign ( 462534 ) on Monday August 26, 2002 @06:20PM (#4144384) Journal
    1. Avoid strong ideological statements in your marketing ("We believe OSS is the wave of the future", "Free software forever"). I don't care about your politics, I want to know technical details about what your software does and how it will benefit me.
    2. Be realistic in your marketing jargon - if it will improve produtivity, don't beat me about the head and shoulders with it, just say so and provide concrete reasons why.
    3. Copious examples.
    4. Reasonable price - I'll pay for something if I don't feel like I'm getting ripped off for something that is only used occasionally.
    5. Multi-platform is nice (if possible), with equal levels of support.
    6. Good technical documentation - consider having a third-party writer for this. The third-party books are usually much better than the company documentation for real world use.
    7. Printed documentation. It's always a good idea to kill a few trees for our convenience. It shows you love us. (Seriously, a detailed reference manual is a good thing).
    8. Download on purchase, and ship a CD later.
    9. Good illustrations (if necessary). Sometimes a picture does say a thousand words, especially if it clears up a really wierd conceptual knot.

    There's probably more, but that's all for now. Thanks for asking.

  • nVidia (Score:3, Informative)

    by Screaming Lunatic ( 526975 ) on Monday August 26, 2002 @06:58PM (#4144601) Homepage
    Take a cue from nVidia [nvidia.com]. They have a great developer site. Great code samples, demos, papers. They are accesible to the public. You can catch them on a whole bunch of discussion boards and email lists around the net. They respond to problems if you send an email.

    Not to mention they provide great drivers for both Windows and Linux. There is a CVS repository you can download other great stuff from. They support open standards such as OpenGL (we won't mention the whole Cg fiasco...I mean nothing).

    Now compare that to the competition.

    Disclaimer: I do not work for nVidia, nor own any stock.

  • You pointed out developerWorks, but missed the project that really mattered: Eclispe.

    When IBM wanted to build a community around the Eclipse IDE, how did they do it? They Open Source'd it of course.

    Of course, if your trying to sell a developer environment, than you need to demonstrate to me (someone who listens to no marketing stuff at all) why I will be so much more productive using your environment than Emacs that makes me dump all the time I've invested in Emacs.

    You either need a super fast, super standards compliant compiler, or some AI in your editor that's so darn good that it thinks for me. Otherwise, I'm just fine with Emacs thank you.
  • Be truthful about your product. Explain its strong point. Explain its weak point. Explain why you desions for your trade off in your product. Be open and honists about any problems it has. Rember your selling a tool designed for particular jobs. Dont try to push it as a good for everything tool. Sell it for what it is attened to be.
    Trust in your product is the most important part in advertising. Assuming that your are not Microsoft you dont have the resources to Bully people into using your product out of fear. Developers are people even most of guys on slashdot. The generally want to feel good about using the product and they want to know that they are using a product that they can trust and they know what it can do.
  • Let me le tyou know about Espial's experience from a devloper who uses Espial tools..

    Espial wanted to get into the mobile dev market having develoeprs use their light gui toolkit, testing tools, and other tools..

    What they did is started a developers website knwon as devicetop.com with year coding contests fro prizes in cash, developer boards to echange ideas and code, an application showcase board, and etc.

    Whil ethe market is in a current slump Espial has managed to snare top honors with tis innovative java courses in mobile programming(some say better than Sun's own)..

    Not only that they have snared some pretty big CE clients using their tools like Sony by using this approach..

    By focussing on the developer they were able to sell their set box OS system which is where they make their money..

    The important points:

    -Make the tool set free
    -set up developer boards and contests
    -Make contest free to enter!
    -Listen to developers

  • Dont make the Sharp Zaurus mistake (Score:3, Informative)

    by angel'o'sphere ( 80593 ) <angelo,schneider&oomentor,de> on Monday August 26, 2002 @10:42PM (#4145713) Journal
    Well,

    above this thread is the thread about the new wireless option for the Zaurus.

    When the Zaurus came out I was keen to get one as fast and soon as possible.

    The price was not that high and they offred a developers discount and free training for the development environgment and/or OS.

    However: they put me imediatly on a "hey he is german, lets forward him to our german department contact list".

    Unfortunatly the german version of the Zaurus is about 30% more expensive, came at least 3 month later into the developers program and I lost intererst.

    Most disappointing: they did not even let me buy the american version.

    We do not deliver to europe ....

    Sorry folks, no one can get here why american products cost us more than we would pay if we buy them on our own and pay the taxes at customs.

    angel'o'sphere
  • This is an interesting discussion. I'm thinking about several sites that I've used in the past, and their products, and what I liked and didn't. My thoughts:

    Good technical manuals: WebLogic is expensive, and I wouldn't use it for personal use, but they have great respect IMO for the developer. Their APIs are fully documented in clear, technical language, they have samples for everything useful, and many many FAQs. Their docs are also updated for new releases. I think good docs will make or break a product, unless it's so easy to use that command-line help is enough or it's "intuitive" (like WinZip on Windows)

    Straightforward user interface:Even if you have the docs, the truth is I won't read them till I need them. I tend to install the thing and then browse around to see what I can do. If it's an editor, I start typing. If it's a drag and drop GUI builder, I start building. While there's something great about developing your own unique interface and way of looking at the world, at least allow for an "idiot's option" that gets me feeling productive; or, that the tool hasn't gotten in the way of what I'm doing. Kudos to tools like JEdit [jedit.org], for example, which I had up and running and compiling with in maybe an hour. Blahs to APIs like Xerces, which I can use, but which have an absolutely confusing API in some cases (how do you move an Element from one Document to another? where's the changeParent() call?)

    Let the FAQs lead the way:A number of others posted that your should publish your knowledge base, but I'd also add that a good FAQ system is a good lead-in for developer interest in your newsgroups. Basically, it will draw people there even if the newsgroups are new. I suspect you'll also spend the early rollout manning the newsgroups yourself. Roll your answers into the FAQs; searching newsgroups is tedious work. The worst thing to find are newsgroups with many, many unanswered threads (like Sun's Java site) and scanty FAQs. JGuru [jguru.com] has a very good set of FAQs.

    Good luck! Let us all know when it's released.

    p!yaya

  • As always, the product should sell itself. If you build it, they will come.

  • Cats Playing in the Sandbox: What not to do (Score:3, Interesting)

    by Rick Richardson ( 87058 ) on Tuesday August 27, 2002 @12:16AM (#4146155) Homepage

    Here's a message a friend of mine wrote a few years back, which I saved. Enjoy.
    -Rick

    From anonymous Wed Apr 26 00:27:55 1995
    Subject: MKS
    Date: Wed, 26 Apr 1995 00:36:08 -0500 (CDT)

    Postmaster@mks.com,

    I do not know the names of the people in your company to whom this note should be addressed, but I can describe them.

    * There are 1 or 2 first class, original UNIX programmers who created all the products you actually make money on.

    * They no longer are in the mainstream of the company. Perhaps they left. Perhaps they are now consultants. Certainly they can be described as UNIX bigots.

    * They are completely pissed off, arrogant, and upset about the current move to the "Source Integrity" product. They feel your current customer base will be disappointed by the Windows orientation, the terrible documentation presented in the "test drive", and the overall poor quality of the product.

    * They feel that you should have remained compatible with the GNU "cvs" product, offering a simple, fully functional, easy to use command line interface.

    Now I will describe the people who realize they are just foolish UNIX programmers who do not understand the movement to fully complaint MicroSoft technology.

    * They are slick, fast talking gentlemen, who have never worked for a small prosperous company.

    * They have never produced a product that made money, development, startup and market costs included.

    * They do not understand your current products, or the customers who buy them They feel you are serving an odd niche, one soon to disappear in the overwhelming rush of total Microsoft dominance in the market.

    * They have identified another, larger, more significant market of Microsoft programmers who will want to buy their products. They perceive these programmers care primarily that the look and feel of these products match Visual C++, and suit a more professional data processing image than the renagade programmer of the past.

    * They do not understand the real requirements of the product. They are assisted by a few slightly-better-than-mediocre Microsoft programmers who want to bear Bill Gates children.

    * They are proud of their shiny new offering. They don't fully understand why anyone would want it, but they think the term "sandbox" is one of its best features.

    * They wear nice clothes, they are charming, and they always go home by 6 pm. They work out in the gym. They use Microsoft email.

    Here is my message to the good guys (first category)

    I really need cvs for my project. I really do. I talked with your blithering salesperson on the phone, and he told me to try out the test drive. I was enthusiastic. I tried it. Within 15 minutes, I was so mad I could spit. It ruined my entire evening.

    I really need that product. I was depending on you guys to have it. And now I am screwed.

    My cats use the sandbox. I don't. It smells bad.

    Your company survives on its image. Your image is being destroyed.

    Your RCS product is destroyed.

    These fools destoy your entire company if you let them.

    They will claim you are in a declining market. They will cut back promoting the stuff that continues to sell, claiming it must finance new products. The new products will be ill conceived. Because they do not understand the customer, and they do not have your support, they will attempt to discredit you. They will bring in Microsoft lovers they claim are experts.

    Together, they and their experts, like the blind leading the blind will lead your company to the abyss. When their products fail, they will claim it was insufficient development funds or promotion funds that killed it, even though they spent far more money on this trash than you ever spent on the products that succeeded. They will cut back your products even further to finance the madness.

    In the end, when it is clear to them that the company is faltering, they will leave, shiny resumes in hand, claiming success for the products they tried to kill. They will never accept blame for the ill-conceived products they tried to create.

    They see only image. They cannot create value for it is not within them. They are made of hype, and hype is all they can create.

    And when your company is gone, they will move on to destroy another company. They will never accept responsiblity. They will never accept consequences. They will polish resumes instead. They will have lunch.

    I have been there. I have watched these idiots destroy my company, as they are destroying yours. If you still have the power to fire them, fire them. If you can't, its too late to fix the problem. Quit and never look back. Your company was destoryed by terrorists. Be grateful you survived. Tomorrow is another day.

  • Key items to do (Score:3, Insightful)

    by Animats ( 122034 ) on Tuesday August 27, 2002 @12:18AM (#4146166) Homepage
    • Be utterly honest about your product's weaknesses. It's better that developers hear it from you than find it out the hard way. It reduces the risk from a development manager point of view.
    • Provide a public bug report and tracking system. Reported bugs should be logged in and customers should be able to monitor their status.
    • Reported bugs must be fixed or fully documented as restrictions. No hidden bugs.
    • Import project files from competing products. This is a no-brainer.
    • Offer a full one-year warranty. Satisfaction guaranteed or your money back. A few percent of the customers will return the product. Ask them why. It's a cheap way to find out what you did wrong.
    • Offer reasonable feature combinations. Microsoft is notorious for offering development tools in price tiers, with the higher tiers having about 95% of stuff nobody wants, but 5% you have to have. Don't do that; you don't have a monopoly.
    • Study Metrowerks. Metrowerks made it as a tool vendor. Find out why.
    • Study Symantec. Symantec blew it as a tool vendor. Find out why.
  • Don't forget: You're selling Software to Software Developers.
    The customers you want are the ones you can't bullshit on about your product. So be honest and think of what these people want.
    Some simpple yet crucial rules you have to follow because of that:
    1.) Solid Documentation.

    2.) Works as Advertised and honesty about features and non-features. And don't just describe that something isn't supported, describe why and give them the opportunity to request little extensions that deal with the issue - you'll have a community in no time. (see www.gentleware.de as an example)

    3.) Close contact/friendship. You and your customers ARE IN THE SAME BUISNESS!!! Give them space to discuss current problems in the field with your developers and get a feeling for the needs of the market. (if only Macromedia would do that...)

    4.)Be good and tackle the difficult stuff that needs "Wow!" solutions - with a speciallized but modular aproach. In other words: Give me the tool I'm gonna bug my boss about! Nobody wants the zillionth IDE. Rather a rocksolid extension to existing OSS IDEs (example that I just had the other day : a Database binding administration tool that updates all the tedious error handling code and that kinda stuff automatically. Borlands proprietary stuff is cruddy and, well, proprietary and Netbeans lacks it)

    If you make these rules your vision you're in for a solid long-term deal with a supperb customer base.
    Good luck and welcome to the buisness.
  • Here's what matters to me :
    • The product should be available to try out with the least hassle possible - ideally as a free unlimited use download.
    • The product should come with excellent "read-me" instructions for installation and/or administration, and a really good "getting started" guide. I've downloaded a bazillion nifty looking tools which had no obvious "getting started" guide or "try this" intro.
    • The installer must be the best piece of software your organisation has ever crafted. It must be totally transparent what you're putting on my system, it must come with a working "uninstall" option, and it should take the effort to use words I already know when asking me questions - "should I fnurgle the foo, or sklarf the bar" is not helpful when confronted with a new piece of software. If your installer is professional, I am a lot more likely to believe the rest of the software is first-rate too.
    • Once the software is installed, give me lots of first-class examples to play with. I only read documentation when it hurts - I prefer working code.
    • Provide an interactive forum with knowledgeable people to help me when I run into trouble - usenet, mailing list or a messageboard are all great.
    • Provide great migration and/or integration tools for commonly used tools. For instance, if your product manages source code or something, help us out with sample "ant" build scripts, and integration options for the leading editors/ides.
    • Get a bunch of "boss-friendly" blurb ready so I can say to my boss I found a really cool pieve of software, and if you read this thing here you can see it's buzzword-compliant !
    • I don't mind the lock-in much - it's kinda inescapable for many serious products - but at least be honest and upfront. Provide a place where I can find out about your proprietary addtions and what to do to avoid them if I so choose.
    • Be upfront about the commercial impact of your products. Don't make me worry that I will end up having to pay through the nose to get your software working on an industrial scale - tell me upfront what the costs are.

    People who do this well (outside the big names) are perforce - they make it really easy to find out about their software, try it, and get comfortable with it.
    jcorporate.com (home of the expresso framework for java development) are also pretty good - they have a decent mailing list and provide as much documentation as they can (though it appears they need some help there...).
    Good luck
  • Here's what I look for when evaluating tools:

    - Factsheets of functionality, both abbreviated and full technical detail. Nothing bothers me more than marketing documentation that leaves out important technical information. If I have to call up a salesperson to find out if it will work on platform (x) I won't call.

    - Downloadable demo. Preferrably without requiring pages of personal information. Asking for personal info in exchange for demo software is a big turn off. If I like the product, I'll be in touch. I *always* fill out the registration/personal info pages with completely bogus information anyway. Please get rid of these things.

    - Online documentation with the following:
    Usage documentation w/ examples
    API documentation w/ examples

    - Case studies on how the product contributed to various solutions are helpful, so long as they are written in everyday english. I hate case studies that are full of buzzwords and glittering generalities that don't say a damn thing about what actually happened.

    - Online community support system/knowledgebase, either via newsgroup, mailing list, webpage, etc. This basic level of support should be free. Charging extra for access to upper-tier experts is fine.

    - For getting the word out, listings on freshmeat/sourceforge and other industry directories are a good start. Presence at trade shows helps. Trade magazine reviews help. Reputable third-party books help once you're that mature. Taking out ads on slashdot probably helps too :)

    The general rule of thumb is to treat me as an educated consumer and provide truthful information resources so *I* can make that decision. If I feel like the marketing department is trying to hide the product behind buzzword literature so that I have to talk to a salesperson in order to find out anything meaningful, I'll won't be calling. I don't mind calling to ask specific questions or clarify a specific point, but all the basic information describing the product should be readily available.

Slashdot Top Deals

"Everything should be made as simple as possible, but not simpler." -- Albert Einstein

Close