Why are developers generally opposed to purchasing software tools?

Question

As I wrote the title to this question, I reworded it a handful of times because I'm hoping to get good, well thought out feedback from the community. Not just "off the cuff" answers of emotion.

Over the span of my career, I've been witness to, and a part of, many situations where there was a need for a particular software tool. However, the people involved were only looking for "free" solutions. Even though there were well know, well respected, and highly polished tools right in front of them (metaphorically speaking). The single con that these solutions had was that they had a price tag. Maybe $9. Maybe $9000. (usually on the low end of that scale)

So, "Why are developers generally opposed to purchasing software tools?".

Assume that:

• The tool that is needed does not have any FOSS solution available.
• We're talking about products that sell for less than $100, as these are the tools that seem to encounter the most resistance. The decision to purchase more expensive software, like Visual Studio, tends to be easier because a business is usually making the purchase. For the sub $100 tools, it's usually an individual developer.

Answer 1

Check this out:

http://www.codinghorror.com/blog/archives/001097.html

The link describes some of the difficulties Jeff Atwood has had when he recommended non-free software tools to developers, even though he believes the tools where much better than the free alternative.

Answer 2

Personally, I've not experienced that at all. I like to be able to test things for free, but I almost always buy them if I like them and/or need them. ReSharper, LINQPad, .NET Memory Profiler, ANTS, XMLSpy, WinRar I have licenses for them all (and lots more stuff too, that's just off the top of my head). I feel like as a professional developer, I can afford to invest in my profession.

But, I suppose most companies don't see the value in buying these things for their developers and I guess people want their companies to pay for things if they use them for their job (which makes sense).

Answer 3

I wouldn't say we're opposed, it's just a matter of economics. We use so many that if we had to pay for them all, we'd be broke.

Answer 4

As a developer myself, I don't like purchasing tools because I feel that (given the right amount of time) I could write the tool myself. Therefore, I shouldn't have to pay for a tool I could write. That is why I will look extensively for free software.

-JFV

Answer 5

I think, to an extent, it might be the developer mentality of "do as much as possible with the least amount of resources". The same drive that leads developers to push down CPU and memory usage might also drive them to lower costs.

It may also have something to do with the free solutions usually being open source. If the purchase in question is something that might be integrated into the final product, developers might be more inclined to choose one that has more eyes on it, particularly with respect to security. It also gives them more flexibility down the road. This doesn't really apply to "tools" in the sense of editors and testing tools though.

Answer 6

As a developer I do not see it as generally opposed, as much as "leveraging" the learning investment.

If you are in a job, and you use an expensive tool, the likelihood you'll be able to use the same tool in another job will be less than if the tool is free.

It all boils down to cost-benefit analysis IMO.

If you have a free tool which gets you 95% of the requirements and you can leverage the learning of that tool, you will prefer that over a tool which costs money, gets you 99% of the requirements and you may not use it again.

That is why, for instance, once a developer sets up with his editing environment (Emacs, vi, Eclipse, Visual Studio, whatever) you will have a lot of resistance to changing it. The productivity will suffer immediately due to all that "finger memory" lost.

Another typical examples of tools that free solutions are preferred by developers are expensive source control tools like ClearCase.

On the other hand, I have seen developers advising and like to use some well established and expensive tools like Purify, and know that sooner or later knowing how to use them well will benefit them. In the particular space of purify, developers will also advise using free tools, because their use is not mutually exclusive from the commercial ones.

Update (due to clarified scope of question): With tools in the sub US$100 category, even though it is a small enough amount they could pay themselves or expense the resistance comes from:

1. Who will own the license ? Me or the company?
2. If the company owns the license to software, if I go to another job, what amount of trouble will I have to get the buy of a license approved ?
3. If I own the license, will a new company allow me to install the software on their machine ?

For all these reasons, the "free" route offers a slightly better return, as the money obstacle of 2 and 3 will be more easily overcome :-)

I also agree with JFV, that sometimes the existing tools do not offer all the capability you'd want, and you think you would develop something better, and that takes away a lot of the perceived value of those tools.

Expanding on that thought, the possibility of developing your own tool, also increases the value of existing open source tools, because the developer can always dive into the source and coerce it to do the additional thing he needs. This may be more work than the developer anticipates, but still possible, whereas a commercial, close-source you'd have to wait for it to be developed or develop the tool from scratch yourself.

Answer 7

I've bought a few software tool programs, but am always wary of buying them, because most of them don't have a good UI or documentation, so it's take a huge investment of time to make them work.

There is also the problem, that it's hard to determine up front if a tool will actually solve the problem I'm dealing with. I was just looking at buying an upgraded Solver for Excel, and downloaded a trial version, and found that not only couldn't it do what they advertised, but to figure that out took quite a few calls to tech support, since the documentation was horribly sparse.

Answer 8

Developers tend to think that their time is worth less that it perhaps is. A developer will look at a tool and say ...

I'm a developer! I could write that in my spare time! There is no way I would charge that much for such a small piece of work!

... all without realizing the complexity of the product.

Developers suffer from the DIY (Do-it-Yourself) syndrome.

Which, itself, is very close to the NIH (Not-Invented-Here) syndrome.

Answer 9

Other than games (which are more arty than code), I can't think of any applications I have wanted in the last decade. IIRC, my employer of the time bought the "professional" copy of Borland JBuilder 2, but that was because you might as well (the one time I tried to use support, it sucked). The only useful commercial software has been libraries and databases. Looking back on it, the libraries have been interfacing to some kind of proprietary interface (SQL Server driver, Oracle driver, MITAI, OLE, Windows installation). YMMV.

Answer 10

For any software project it is desirable to have a very simple build process:

1. checkout project from version control repository
2. run build script

Software licenses complicate this. The machines of each developer (and the build server) need to be carefully prepared with licensed copies of the required software.

In our case software licenses have led to an akward development process: only certain developers can do a full build of our main product because of license limitations, and many developers need to share a single "installshield PC". It's hard to do automated builds in such an environment.

Answer 11

At work, many programmers aren't in a position to realize the economic benefit of buying a product that will allow them to spend less time on a task. However, they are in a position to make more money by expending more effort to solve a problem. Lawyers have this in spades, to maximize billable hours, they would write everything longhand (at $300/billable hr) and have an administrative assistant type it up if they could get away with it.

Answer 12

I tend to install quite a lot of tools, many of them I don't use very much, many of them I un-install after a while.

I may try something for a while, then throw it away.

Having to "buy" a tool doesn't fit very well into this workflow of freely trying things and throwing them away and/or keeping them in the drawer for later use.

Even when I look for a specific tool to do a specific job, I may download 4 or 5 alternatives and play with each one of them. I may stick to one or more, or I may not stick to any at all. I may use one as my primary tool, and I might keep some of the other alternatives for occasional use; meaning I don't use them all the time, but I don't delete them either. Maybe I use them once a month or so.

Again, having to buy a tool disturbs this workflow.

Trials are not good because they usually have a nag screen, and you can't keep them on the side for once-a-month use; after the first month, it will stop working.

Answer 13

Two factors that have not been mentioned yet:

• When working on hobby or learning projects, dev time costs nothing and no monetary payoff is expected, therefore expensive tools are extremely unattractive. People get used to thinking like this.
• In many companies (especially larger ones), you cannot just ask your manager to buy a tool, quickly explain how it would save more money than it costs, and have the purchase approved and done in an hour. No, there is a huge beaurocratic process that can easily take weeks. And you need that tool right now, not next month. So you download something free.

Answer 14

Three other scenarios not mentioned could be: 1. hired programmers or consultant who can't turn their license to the customer so they have to be careful in selecting tools that the customer will have to buy or take in charge 2. plain ignorance -- there are so many tools and time is very limited to explore and evaluate them; 3. rent by the hours -- I mean that sometimes programmed have no gain in being more productive, because their manager wants to get as much money as possible from the customer after bidding a very very low price

My 2€¢

Answer 15

Because while the paid-for tool may look in the 'first 10 minutes of searching' like a good solution, after it has been paid for and then used for a while the limitations and weaknesses become apparent. There is then no way forward apart from asking the vendor for improvements, hoping they think they are worth doing, waiting, paying for upgrades, finding there are more limitations and repeat... I am in this exact situation with a PDF editing tool I paid for. It's quite good, but after using it for several months I keep finding things I wish it did better. The vendor doesn't seem interested in improving it.

If a tool is open source it is possible to improve it in the exact way required. If it is free (but closed source) the tool can be evaluated until limitations are found, then move on to the next tool and repeat.

Answer 16

These are the reasons why I would rather use an open source tool of some kind, whether it's a library or an IDE, than a paid-for one:

• If I'm going to learn a tool at work then I'd like to be able to use it at home as well. I don't really want to spend my pay on expensive software that I won't use that often.
• Having the ability to read the source code often more than makes up for poor documentation and/or support.
• I tell myself that I can contribute back to the project. Even if I never do, the knowledge that I could is... seductive.

Answer 17

Maybe I'm a bit funny, but I do buy the development tools that clearly make my developing work easier. However, I value quality of the product above all else, and high-quality utilities are a bit difficult to find. Furthermore, I am a software engineer so I will always check if the tool I need is something I can build quickly myself. And of course I will use Free/FOSS products if their quality is as good as a competing commercial product.

Byt when you think about it, do we really need that many tools? I use Altova's MissionKit because it provides an easy way to build XML schema's, to quickly write mappings from XML to XML, XML to DB, DB to XML and even DB to DB. And it includes DataBaseSpy which is very useful to create new databases. I even use UModel for UML modelling of my hobby projects, no matter how ridiculous this might seem to use, for simple projects. Of course, I also use the SysInternal tools but those are free. Still, very good tools. In the past, I used Enterprise Architect but it's pure overkill for the simple projects I'm creating. Filezilla is useful to FTP stuff to my website but again, Filezilla is free and easily competes with commercial products. I use Paint Shop Pro 8 to manipulate artwork for my applications and use Poser Pro to create simple animations and images to use within my application. (Often simple images of a person performing a certain task or holding a sign to brighten up the GUI. And no, those are "neat" images, so no nudity.) And recently purchased Adobe's Lightroom for photo manipulations, since I also use digital photo's in some of my hobby-projects. (Especially pictures of clouds to get a nice, blue/white background.) Of course, I also use development tools. Visual Studio 2008 and Delphi/Developer Studio 2007. Didn't want to upgrade to D2009 simply because it has no added value to me anymore, although I've purchased every Delphi version up to 2007. But those are just for my personal hobby projects and personal education...

---

My employer has a strict budget for these things, though. And every expense must fall within the budget. Because of the many expenses a commercial company has, it often means that we first check if we really need to have this product X which will eat some of the cash from the budget. It gets worse, because we're working with teams of developers and we would need a license for every developer for most tools. A single license of $50 is cheap, but when you need to purchase 20 licenses then it becomes a bit expensive again. Of course, many products allow bulk licenses and shared licenses but still, it all adds up. Also, we're dealing with 20+ developers who all like to use their preferred product and it's a bit difficult to get them all agree on the same product. Such decisions often take a lot of time before a product is purchased and in most cases a new product just doesn't get enough support. It took my employer about 5 years to upgrade from XmlSpy 4 to the latest MissionKit version and even longer to upgrade from Delphi 6 to Delphi 2007. (Yes, we were using a compiler that's now about 10 years old.) The problem for commercial businesses isn't in the price, it's in the time and effort it takes to decide which product you need and to get everyone to agree to use the new product.

Answer 18

I don't think we are particulary opposed to purchasing software. But there are some factors that make it harder to sell software tools.

Market Size - Most software tools are dedicated to one environment, say "the best charting tool for MFC". How many shops do something with charts in MFC?

Payment Fixed Cost Every purchase holds a fixed cost. So whether it's $9 or $900, slap on it another $100 for figuring out the right licence, convincing your boss that it's cheaper to buy, whip out the company credit card, filling in the order form, having someone check the credit card statements, keep track of the licence key somewhere, etc.

Together, these two points pretty much forbid cheap software tools that recover implementation and maintenance cost.

Technology Lock-In Rarely a software tool runs standalone, rather it gets integrated with other tools sooner or later. Only then you find out if the tool is right for you indeed. When you find out it isn't exactly what you need, you have already invested development time and modified workflows to use this tool. Also, you often can't easily go back, sicne you are now relying on that functionality.

Of course, this problem exists for beer-free tools as well, but there's not much reason for buyers remorse if you didn't pay anything.

I could do better: Every tool I used is lacking in a certain regard. That's especially frustratign for a developer, because he could do better! Then he might see the code base, shriek, and say "I could do better". Thus, another homegrown, incomplete tool is born. The final cost is much higher than bearing the kludges of the commercial one, but the cost is spread out and we have the feeling we achieved something.

The OpenSource Dilemma: If I am going to build on top of a commercial tool, I better get source code. After all, even with the best support the vendor may go down. After all, I've seen glaring bugs go unfixed for years. Yet, there is no universally functional business model that combines making money of my code and giving away my code.

Thinking in code: Many developers think of cool things they could do with X, rather than thinking about why that would be cool and what other X'es you'd need, too. Many of the smaller products are API-Centered rather than task centered: there are many tools based on VirtualQuery, and many tools based on HeapWalk, yet there are few that combne these.

---

Why I do buy Software Tools

I know that deceptively simple problems, such as writing some lines to a log file, aren#t, in fact, simple.

It's not my job. Joel is right when he says outsource everything except your core business.

I get support. Because, you know, fixing that bug is not my job.

I get source code.

I get solutions, not just tools.

Answer 19

This is one of those questions with many answers, really. The ones that come to mind for me:

1. Developers know the things that can go wrong with software. Very few developers I know actually care to buy software because in their experience, the thing they get is not what is advertised, or does not do what they want in the way they want it.

2. Ego / pride / inquisitiveness - developers are naturally drawn to solving their own problems rather than relying on somebody else to do it. This is why we have a whole hacker sub-culture. In my experience, the decision to buy a tool usually comes AFTER everyone has had a go at working out the problem themselves.

3. Licensing problems - development environments can change fairly rapidly and drastically depending on the nature of the project, the customer, the requirements etc. If the license of a software does not cater for this kind of versatile environment, then licensing becomes a very sticky issue. Free tools (particularly FOSS tools) or in-house developed tools do not generally have this kind of problem.

4. Developers hate justifying decisions ('RTFM!'). It's easier to do without something new in terms of personal workload / time spent doing anything other than coding than it is to go through all the rubbish that involves introducing a new tool to the dev-kit or requesting the tool in the first place.

Answer 20

For the trials, maybe.

Often I have to try the software for more than 1 month, and in many different situations..

For example, I've bought navicat for mysql after stressing very much the lite'n'free version, and in the end I bought it for the 'backup' functionality that was not available in the lite version.

Now, I'm switching from mysql to postgresql.. should I pay again to have navicat work with postgresql?

Sure I have.. I mean, I dont regret my purchase, it was money well-spent, but..

I'm sure that I'm not explaining what I mean, but, the software market evolves itself so quickly that is hard for me to say 'ok, this is exactly what i need now and in the future, Ii'll use it so much that it worth the price!'

I dont consider the 'I can do it by myself' answers.. if you can do it by yourself, well, do it.

But if you want to save time and pain (building it, testing it, fixing it's bugs, keeping it updated, and whatever else a self-built software component takes), buy it fool!

Answer 21

I think it is mostly the DIY/NIH syndrome. But there is a second reason: A purchase takes time.

Googling for, downloading, installing an testing a free tool takes maybe one hour. Where I work, purchasing a software takes between 3 days and 1 week.

In that sense, using free tools is a big speed boost.

Answer 22

I tend to go with best tool for the job, be it commercial or open source.

That said there are number of factors that do not favor commercial tools & libraries, so given two similar products one open source and other commercial I would usually go with open source:

• Availability - open source is click (or maven dependency) away from getting included in your project. Commercial usually takes some time to purchase.
• Limited Evaluation - too often commercial tools give you evaluation that is limited to short time - 2 weeks or month. Getting this extended until formalities are finished can be complicated (and who likes begging, right?)
• Restrictive Licensing models - depends on product but usually any kind of royalties are a big no no as well requiring a much bigger amount of people involved to get the deal done
• No Source Code - for some products it doesn't matter much but no matter how good your support is sometimes it is just much easier to open up the code in debugger. This is especially important for libraries that are linked to project and not just external tools.
• Skill Relevance - if a product is used in very small amount of places it means anything you learn using it won't help you in the next job.
• Support - with open source solutions to most of common problems are just google search away. Good support is important but it's hard to beat the quickness of google search.

I guess my point is that for commercial product to succeed it needs to be way better than an open source alternative, it's not enough to be "good enough" to be able to charge money. A good example of that is IntelliJ which manages to give good fight to Eclipse for a long time despite Eclipse being free, open source and pushed by heavy weights such as IBM.

Answer 23

In my company, in order to buy anything you need to

• put up a purchase requirement paper for the boss to sign
• put up a formal request for quotation and get 3 quotations
• raise a purchase request so that the contracts department can isue a PO to the vendor

After the product arrives, you need to

• perform goods acceptance
• track the item under your name*

*This means that someone from store, will put a sticker on the box that the software came in, and come around every year to check that the item is still around.

If there is a need for annual maintenance, then we need to do the purchasing cycle all over again.

This goes on until you decide to write off the item...which takes a lot of paper work all over again.

I am told this is all necessary to conform to ISO9001. I try my best to avoid buying anything except the bare essentials.

Answer 24

Similarly to sep, I don't have to get any sort of approval to use free software--and I'm certainly not going to purchase the tools out of my own pocket.

Answer 25

Because in most organisations, developers don't have to power to sign buying requisitions. It's as simple as that.

Answer 26

It's not that developers are opposed to purchasing software tools.

They are however opposed to paying for it out of their own pocket for the company to use - which is what most companies expect.

Answer 27

I disagree with "Developers tend to think that their time is worth less that it perhaps is" - for normal developer you will get pay the same - no matter how you work or what you do(the sad truth, job change do help). so its more fun to write some tool or find free one(Learn Once - Use Everywhere) than to use commercial product with all it paper trail. If you pay for tool yourself - you are just losing money. its not much, but when the last time the company gave you something for free? i remember only bad food that i dont care for.

P.S. This should be a comment, but i cant comment yet.

Answer 28

What if I buy this product, and it turns out not to have been worth my money? Whereas if I download a piece of free software and it doesn't do what I want it to do, I can just uninstall it with no loss besides a bit of my time. That's generally what goes through my mind. Even a $5 program is a monetary investment, whereas a free one isn't. For me, the jump from free to not-free is very large, compared even to the jump from $5 to $20. Given the choice between a $5 piece of software and a better $20 piece of software, I will choose the more expensive, better program. But given the choice between a free piece of software and a better $5 piece of software, I will probably choose the free version.

This is probably why I tend not to make many purchases (software or otherwise), but to spend lots of money when I do..

Answer 29

Many developers get themselves set up for development at first with a favorite text editor. It takes time for them just to move from that to an IDE, even though many good ones are free. Buying software is similar.
A couple points to identify the attitude:

1. Dont mess with my environment, I am comfortable with it, it works. Dont force me to change.
2. If it is inexpensive, I could probably do what it does in [my text editor], and do it better, with more control.

Answer 30

I don't think it's precisely an unwillingness to buy tools.

I'm old enough to remember the days when coders demanded specific tools: Visual SlickEdit, or CodeWarrior, wouldn't work in an editor without Brief emulation or WordStar keyboard capabilities, and laughed at tools that didn't allow you to completely change the behavior with macros.

Then MS started coupling the languages very tightly to the tools. I would say about 95% of the Windows coders I work with these days have never used anything but Microsoft Developer Studio. And they don't even use most of the better features. I doubt anyone in my current team has ever used the refactoring support; the only other guy who used Nunit or Nant left over a year ago.

MS had some serious competition once; not so much anymore. And when managers demand that all the coders work together in the identical (MS) tool, no matter HOW inappropriate it is, most of the guys who are looking for work use the same tool.

They guys that care about the tools (me) are older guys who can use Visual Studio but see nothing wrong with Vim or Emacs, can write Nant or MSBuild build scripts, but have no problem tossing together a makefile.

We don't need a whizzy-whig PowerShell! code generation tool because we can dash off the code in Vim in a PowerShell/bash/perl/python/ruby/etc, etc, script.

We know the cool features of Team Foundation Server, but when management insists on VSS because TFS is too expensive, we're perfectly fine with Subversion or Git (nobody's fine with VSS ;>).

We know the advantages of the improvements in SQL Server 2008, but when we have the joy of fighting with the infrastructure team over licenses and authorizations, we're cool with MySql when we need to toss a database on a system.

FWIW, I've been spending the last few years coding in SSIS, ASP.Net, T-SQL and C#. And I spent most of today training new developers and managing longer term team members, creating, updating and testing for verifying database deployment procedures (makefiles in Vim, naturally), and working on EDI code in C#.

Why Vim and makefiles? Vim's faster than DevStudio and makefiles are less verbose than Nant or MSBuild scripts, especially when you need to run tools like osql instead of the C# compiler.

These makefiles are really just for me; people implementing the deployment will follow a checklist and use the GUI tools to change the table structures and stored procedures directly in QA and production systems.

If anyone else would use Nant or MSBuild or anything decent, I'd use those tools instead.

I'll buy tools for a decent bang. But for the most part, it seems tool vendors are trying to be "integrated and easy" rather than good (except open source). And the people I've worked with over the years who want better tools and results are using my preferred tools more every day.

Answer 31

My pet peeve? Environment replication. In that rare happy instance where you have a completely free stack running your app, you can easily replicate your environment for setting up multiple development branches, or user acceptance test environments, and so on.

Having editors, browsers or other dev tools that had to be paid for is one thing, but ironically enough, having to pay run time licensing fees, such as for a database, is a real pain. Having to deal with the constant "license shortage" and constant sharing of the oh-too-precious resources is a real pain.

I only know this because I have to deal with draconian database license fees at work. Oh well, at least the java stack is free...

Answer 32

I used to be a unix system administrator back in the early '90s. I had a file cabinet filled with software licenses, license keys, blah, blah. Not having any of that any more is worth a LOT OF MONEY, more money than you, or anyone, has.

Answer 33

The reason why at my job we try to buy as little tools as possible is to drop our dependencies to zero. Now that doesn't mean that we don't use tools like source safe. We just don't like to buy tools that is so tighly intregretaed into our code.

Answer 34

Personally if it is a tool of some complexity I will stay away from the free ones. I think developers should be paid for their work.

My feeling is that by supporting free tools, especially ones that took significant effort to produce I am devaluing software and software developers in general.

Answer 35

I'd much rather purchase a tool that make my own. My bosses and corporate policy forbid me from using software that the company hasn't paid for, and my boss won't approve expense/reimbursements of purchased software.

In the past, at companies with less restrictive policies on software, I'd buy it myself if the cost was under $100. At my current place, it takes about 6 months to get approval of any software over about $500 in price, and the mismanagers don't realize how much we wasted in meetings trying to get approval to buy it.

Answer 36

I have avoided asking for tools since I know there will be a process involved in getting it, and I will have to convince people the tool is worth buying. The whole process will cost more in man-hour-salary than the price for the tool. That has put me off to even begin and instead reach for the free alternatives.

The opposite are the management-initiated tool purchases. Tools with pie-in-the-sky promises (this code will generate 80% and you will just have to fill in the remaining 20%, imagine the time savings!). Tools with non-standard protocols, such as crm/issue-report system requiring a windows-only client thus impossible to link to data in it from a wiki or emails.

I dont know from what angle the question is asked, if it is a developer with team colleagues that arent interested in arguing for some tool purchase, if it is a manager that cant get his team of developers enthusiastic about a tool or if it is as a software vendor that is having a hard time selling their excellent tool.

• If you are one in a team, then try to get a trial of the tool and use it. Show-off with it. Eventually someone will ask you if it can help them.
• If you are a manager and your developers dont seem interested in the tool you tell them about, maybe you dont understand their work well enough and they see through the marketing in a way you do not.
• If you are trying to sell a tool, then perhaps you should offer trial period? If you already are, perhaps make it an eternal trial period, but with increasingly frequent license updates. Something that eventually leads to playing hang-man and win N times to prolong the trial period. For extra bonus, show how much time has been spent "playing".

Answer 37

If I am developer then why should I use program or application developed by other and pay for that.

Let me give a try for that.

Answer 38

Big software company, "Here is our new OS - pay us. Here is productivity software for our new OS - pay us. Hmm... not enough market share... we need 3rd party developers to write more software for our OS so that we can have increased sales... let's put out an SDK... PAY US."

Developer, "Umm... what do we get for 1) buying your new, buggy OS and setting up three isolated environments to develop, test and release on (except the 'benefit' of having to buy 3 licenses because of your VM licensing rules and 'call home' verification), 2) learning how to develop for it, 3) compensating for all your closed-source bugs, 4) knowing we'll have to re-write anything we ship when you make unannounced, under-the-hood changes that crash our programs, 5) paying a whole lot for your bloated SDK that, yet again, forces us to learn an IDE 6) take a risk writing software that you'll eventually copy and make part of your core OS, leaving us with nothing and 7) possibly eliminate the languages we've spent years getting familiar with in order to give us a new language we'll have to learn?"

Big software company, "Well...if you pay for our Enterprise SDK Subscription, you'll get access to shoddy documentation, access to a, 'user-maintained support forum,' and one, 'incident call,' to a call center in India, per quarter... does that help?"

Developer, "No... not really. Is there enough public information available so that I can at least use Yahoo, ClickOnMy, Bing or Google to help me debug?"

Big software company, "Oooo - excellent point! We have this NDA you'll have to agree to..."

Developer, "You know... your competitor offers their SDK for free - full version. And... they also have a market place where I can sell what I write, directly to their customers... the slightly higher price I'd have to pay for their hardware+OS and access to their store is more than made up for in savings over your JUST Enterprise SDK Subscription... maybe I should..."

Answer 39

(How do you delete an answer?)