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.
We are wary of the issue of dependency as well. As you point out, there are ways of mitigating the risk, and we are making it a top priority:
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.
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.
I think there are important differences between libraries and platforms.
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.
That being said, open source libraries aren't always free when it comes to support and technical costs..
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.
That's a good point. We're trying to disrupt the existing API platform market by being leaner and faster. Putting some Windsoc code on Github hasn't been ruled out, either. I think that assuming that for-profit vendors would never consider supporting and leveraging the open source movement would be just as dangerous as an assumption about open source being unreliable.
Selling to developers strikes me as mostly a bad idea. If you deal with non-technical people, being able to code up a solution to their problems, to save them pain and time, may seem like 'magic', and they'll love you for it, if you do things right.
This kind of comes out in this post, but the way I always look at the "I'll do it myself" argument is in terms of time. If you have a product that people known is easy to use (more on that in a second), you just say, look a license costs $100/yr or you could do this yourself and spend 10+ hours working through all the issues I've already solved. So if your time is worth $10/hr, go for it, otherwise I'm saving you a lot of your valuable time.
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.
It's not just about time you can save right now, it is also about risk.
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.
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).
Do you mean that literally (re-packaging xampp) or metaphorically (I can get this for free, over there)?
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.
It sounds like your best market to pitch to would be startups. And if that's the case, it's a tough sell since they're usually very financially conservative, and they want things that will directly lead them to profit. Simple to use APIs is nice, but I don't know if it's a must-have for startup developers. Most of them want to quickly ship something to market.
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)
We are definitely looking at startups for now, expecting that finding success with startups will naturally lead to interest from larger enterprises.
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).
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.