But it does raise a point that I wanted to mention. In many cases (and Windsoc is such a case) when you are trying to sell to developers, your competition isn't the developer's wish to "do it myself". Your actual competition is the plethora of open source tools that already do the thing that you're trying to sell.
Software development has changed, and those vendors trying to build a business selling libraries and toolkits are going to find it difficult to stay relevant.
Protip: If a search on http://ruby-toolbox.com/ turns up half a dozen gems that do the same thing that you're trying to sell, well, you're doing it wrong.
1. Libraries are static, with versioning and upgrades, whereas platforms are real-time.
2. Libraries are based on a one-time usage, whereas platforms depend on providing constant value to maintain users.
3. Libraries do not generally offload any work to other servers, whereas platforms can provide efficiencies.
4. Libraries are platform, language, and version specific, whereas platforms can be built through protocols like REST and JSON that are known to most stacks.
That being said, open source libraries aren't always free when it comes to support and technical costs, and not all platforms are closed-source.
While it's true that you can't always compare open source support with vendor support, I definitely feel the tide turning on this one. In the past 2 years or so (and this is just my experience, YMMV) I've found it much easier to get changes made from a project maintainer, than from most software vendors.
Github has changed this drastically. I can fork projects, fix things myself, send pull request back to the project maintainer all in less time than it usually takes for a traditional software vendor to even put my support request in the queue and acknowledge the problem.
I'm just saying, things are changing. Your business will have to change too if you want to sell to developers. You can't keep repeating the same aphorisms about support and technical costs.
The comment added to the discussion, and the "protip" in question was a good point.
Last I checked, karma is to be given/taken due to quality of content, not whether or not it hurts your precious feelings.
It's not only that developers are always confident they can do things themselves (though that's common), but that me using your thing actively introduces a dependency for me. If that saves me a huge amount of work and your dependency doesn't seem too scary, that's still a win. But dependencies have a whole host of issues of their own: is this thing unwieldy, do I actually understand what it does, is it well documented, is it going to be around and maintained, if it's for-pay is that pricing going to stay stable, is the API going to be stable? Etc.
1. Stability and security will be maintained by a gradual roll-out and a user-driven testing phase. We're still working out the details on this.
2. A standard documentation format is a key requirement for each documented API call; no call will be released for general usage until it has all included information (parameters, possible success and error results, example response).
3. Pricing / service contracts. We are looking at providing guarantees on pricing stability and uptime, and we're thinking of not charging in advance, but after service has been rendered.
4. Source release pledge. It's too early to know how to proceed with open sourcing, but we do expect that at a minimum our client libraries will be open source. And we will pledge to release all code if there were to be an impending service shutdown, with three months minimum for transition.
I think that's all we can do when starting out to show that we aim to be a reliable component. The real evidence probably can't come until we earn a reputation over the coming months.
The only wrinkle to this is that you have convince people that your product actually does make their life easier/save them time. If they think they'll end up spending a lot of time understanding how to use it and integrating it, that's when people say, not worth it. For instance, you could be selling an awesome jQuery table plugin, but if it doesn't support some feature I need (say, a find as you type search box), I'm probably not going to use it because the time to build that feature onto your plugin might be longer than building my own.
Depending on a 3rd party, proprietary solution may be considered a form of technical debt. If (or when) the 3rd party raises their prices, goes out of business or does something else unhelpful to your business, you'll have to replace them.
Depending on what it is, that kind of work can be far more costly late in the game than it is at the beginning.
http://www.devside.net/server/webdeveloper
How to convince the developer that the solution provided is ahead of what he/she can just put together...
It really is, but conveying that is difficult.
I imagine the questions are "Why would I buy what I can get for free?" and "I can probably do better myself?"
Both of the questions are false (other solutions are free only if your time is worthless + the solution is a product of 7+ years of improvements/iterations) but try to tell that to someone (who right at that moment thinks they know better).
Perhaps I should look into other market segments.
http://www.apachefriends.org/en/xampp.html
The page you linked to says to me "we're selling xampp!" If that isn't what you are doing, then you should look at your sell page.
If you are indeed just a paid version of xampp, then good luck with that.
WampDeveloper has nothing to do with xampp. The only similarities are: WampDeveloper uses Apache, PHP, and MySQL on Windows.
That's another problem: that some visitors think "xampp"?
Even though WampDeveloper is a completely different system/framework, switches between all versions of Apache, PHP, and MySQL with a click, creates and manages all websites/VirtualHosts, has a full user interface, has a web application installer for Wordpress, Joomla, MediaWiki, Drupal, Magento, controls "local DNS" ... etc. All the things xampp does not do.
Or are you coming back to the "Why would I buy what I can get for free?" question.
Thanks for the feedback, I'll look into it some more.
If you're targeting the enterprise, keep in mind that developers who code for big companies aren't the ones making the buying decisions. If it's not free or open source, most will not have the initiative to pitch to upper management (they just want to get the least done in the least amt of time so they can go home to their families, and watch TV)
What I'm hoping to emphasize (and maybe I haven't done that enough) is that startups who are heavily integrated into social services and will see high usage would have a monthly charge, but startups just using Twitter once per user to grab a list of followers wouldn't have to pay more than the $50 license fee unless they had a very large number of users (I like to say a million, but it all depends on the specific API calls).
