

Selling to Developers: Dealing with “I’ll do it myself” - wolfrom
http://blog.windsoc.co/2011/04/05/dealing-with-ill-do-it-myself/

======
bhousel
This article is somewhat blogospam.

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.

~~~
wolfrom
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.

~~~
bhousel
_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.

~~~
wolfrom
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.

------
_delirium
I like Yosef K's six criteria for deciding whether to adopt an external
dependency: [http://www.yosefk.com/blog/redundancy-vs-dependencies-
which-...](http://www.yosefk.com/blog/redundancy-vs-dependencies-which-is-
worse.html)

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.

~~~
wolfrom
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.

------
davidw
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.

------
bialecki
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.

~~~
HerraBRE
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.

------
powertower
I have the same exact issue here:

<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.

~~~
larrik
Have you seen xampp?

<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.

~~~
powertower
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.

------
Hisoka
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)

~~~
wolfrom
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).

