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.
+3  A: 

Check this out:

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.

although the link is relevant, and also makes good points, i do not feel posting a link with no comments adds to the value of this question.
levi rosol
Agree with @levi, I'd +1 this if you quoted and/or summarized the article in your answer.
+5  A: 

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

JP Alioto
+52  A: 

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.

+1 because this answer seems to make the most sense, at least for me.
And money doesn't compile on trees, y'know...
Gabriel Hurley
...neither does time.
+9  A: 

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.


So you're not willing to pay for food either because you *could* do it yourself? Breed your cows and farm your corn?
Don't talk badly about Bessie! :-) I never said that it had to make sense... That's just how I feel. And if I could get away with not paying for food, I'd be all over it! :-P
There's two thoughts in this answer. The first, that you feel you shouldn't have to pay for something you, theoretically, could build yourself. I oppose that because with time, anything can be be built by nearly anyone (I disregard anything that requires genetic markers, either exceptional strength, endurance, intelligence, etc.). Money buys you time. Time to either build it, or simply to learn how to build it. Now, looking for free alternatives is just common sense, but not looking at commercial alternatives, that's just stupid.
Lasse V. Karlsen
I'm not following your comment. You didn't infer my question to be stating that developers should look for commercial alternatives when FOSS solutions are there did you?I simplly am looking for feedback on why developers will spend 10 hours googling for something and/or trying to get some poorly written application to work, vs spending $50 to buy it in the first 10 minutes of searching.
levi rosol
Developers under-estimate the time they spend doing things (both developing software and how much time they would have to spend in order to find a free alternative), and as such will happily wile away hours in order to find a "better" alternative simply on the basis that "it will only take me 5 minutes to find that free program that does what I want".
Lasse V. Karlsen
@IlDan: Tool carry intregration cost, food doesn't. If I don't like a food place, I don't go there anymore. If I figure out the tool I've integrated into my build process corrupts my database, I may have to tear apart my build system and start over.
Strangely enough in my first comment on this topic I describing a hypothetical developer with this exact same sentiment and sure enough I move to my second message only to find the exact same developer that I described ;)I'm sorry I just had to laugh. For a moment there I felt like a prophet or a psychic. I was so blow away I you my upvote ;)But back on topic, as a long time software developer I just don't understand how other software developers somehow think software is easy to write and hence effectively worhtless? I mean given enough time anyone can write software.
@peterchen yeah, but if you write it yourself will corrupt your database more likely. Because you'll never have the time and intelligence of doing decently both your work and that of conceiving, inventing and writing lots of different tools. We have 50+ years of software history and 5000 of human culture behind our backs!
that's exactly the point, you are paying for the time that someone else spent developing something... It has nothing to do with your are able or not to do it by yourself...
+2  A: 

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.

Grant Heaslip
Time is also a resource.
Lasse V. Karlsen
+18  A: 

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.

i must be missing something cause you're the second person to suggest that JFV was saying he'd use open source tools. :) I took his response to suggest he'd build it himeself(given enough time) instead of paying for it. and because he doesn't have time, the next best is free, so he looks extensively for free tools. open source not playing a part in the decision.i do agree with you though. any time you can find a open src tool it must be considered for a number of reasons. however, open source options don't really play into the scenario i'm trying to describe.
levi rosol
I also took JFV response as saying he build the tools himself.I just expanded on his response to say that in addition to that, and as an alternative, developers would favor open source, because they could both take an existing tool and then expand on it to fit better the needs, without all the heavy lifting up front.I will edit the punctuation to make this clearer. Thanks
thanks for the clarification.
levi rosol
+29  A: 

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.

Lance Roberts
I think the points you make here are great and play a big role is why developers choose to search and/or build for hours instead of purchasing a product.
levi rosol
I look at open source software and think the same thing.
Tom Hawtin - tackline
Tom, with the source code available, you can much easier create an improved UI, and the documentation can be written precisely based on what happens. You simply don't get that with closed software.
Peter Boughton
Yes, but there's a time factor there. I'll write a few of my own libraries so I can get those benefits, but where am I going to find time to write useful software tools.
Lance Roberts
@Peter, you are ignoring the pain of the different coding styles for each open source project. Every time you open one up it's like a new pile of crap that you have to wade though (I used to be a huge OS fan... I learned my lesson.)
Matthew Whited
Huh? Different coding styles is entirely unrelated to code being Open Source or not. If anything, OS projects are *more* likely to have up-to-date Coding Guidelines, and these can be more strictly applied (since they suffer less from a push by management/marketing to just get it released).
Peter Boughton
I've seen *plenty* of sloppy badly-structured Open Source codebases over the years; but I've *never* seen a good well-structured closed source codebase.
Peter Boughton
+64  A: 

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.

John Gietzen
I think this is stop on. A developer getting paid $30-$100 per hour would rather spend a few hours trying to find a free solution (because they understand software) and come up with nothing than spend $300 dollars on a working software solution. I mean they are there to save the company money.
I don't think this is fair to the open-source world. To me, the barrier to using commercial tools is that you're just as likely to "come up with nothing" as you would have been if you'd gotten it for free. Why not see if there's a free solution available, before finding a paid one? There are some pretty bad commercial tools out there, too. Also, an initial learning curve might be cheaper than vendor lock-in and a long-term licensing agreement. The total ROI really depends on the individual tool in question.
@RMorrisey: Well, the question was targeted at **developers** specifically. **Everybody** should be looking at Open Source software, but developers *tend to devalue* software because they know how easy it is to create.
John Gietzen
@John Gietzen: I am a developer. I was trying to make the point that commercial tools can "cost" just as much in terms of development time as OSS tools, or sometimes more. Your answer and jussij's comment seem to suggest that if there's a commercial tool, it's better or easier than an equivalent open source solution. (The tool provider already invested the time, so the developer doesn't have to spend their own time, just the cost of the tool.) I can think of a few examples where this was not the case.
Addendum: the answer makes sense in the context of the question, assuming there's no equivalent OSS solution. I guess my objection was mostly to jussij's comment.
@John Gietzen Ironic, because developers of all people should know software is not easy to create. Er... Good software, that is.
+2  A: 

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.

Tom Hawtin - tackline
really? so in ten years you've never wanted to zip/rar a file or two?I do sincerely apologize in advance for my sarcastic response to your statement. I just find it hard to believe that in the span of 10 years or more you've never wanted a piece of software other than games.
levi rosol
Actually I had a rar file the other month. But only one. The occasional zips I've done on the command line (sometimes with jar). I need to know how to use those tools, so learning and installing a GUI front end would just be extra work (I purchased David Pilling(?) archiver at University and have used WinZIP over a decade ago). I obviously use browsers, and a OSs with applications. I looked at Intellij IDEA but didn't see the point (like a bad version of NetBeans). What else do I want?
Tom Hawtin - tackline
There are a lot of programs that aren't the terrible winrar that are able to open .rar files. Also, I think the answerer was saying "I can't think of any applications I have wanted [to buy] in the last decade", but I could be wrong
+22  A: 

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.

Wim Coenen
+3  A: 

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.

Jeff Leonard
unfortunately this is, in some instances, the case. I like to believe that some of these cases are overcome by developers being more lazy that evil. Meaning, not wanting to spend 10 hours on a 30 minute task wins compared to the carrot of being able to bill 10 hours.I say this taking full account that I have been both lazy, and evil, regarding software purchases, at some point in my career. With that said, I can sleep at night knowing that I tend toward the lazy side rather than evil nearly all the time.
levi rosol

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.

hasen j
+43  A: 

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.
Michael Borgwardt
Depending on the work situation, your second point could indeed be a major hurdle for purchasing a ready made solution, yes. I've seen it happen. In general, I think developers both tend to underestimate the work that would be needed and "just want it themselves".
And your company may have a policy about installing unauthorised software. If they discover your productivity tools they may decide to fire you.
Colin Mackay
I pay for my tools out-of-pocket. That way I get to take them with me. Oh, and I can write 'em off on my taxes. ;)
+1  A: 

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€¢

Giulio Vian
+3  A: 

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.

A vendor who is not interested in improving his tool (assuming a significant number of users wish it) will not get far.
In this case it's not their core product so they don't seem to care about it.
"A vendor who is not interested in improving his tool will not get far."lol ... ever heard of Microsoft?
+1  A: 

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.
Cosmic Flame
+1  A: 

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.

Workshop Alex
+10  A: 

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.

For Payment Costs you might be better off telling your boss that "it'll cost you more money if I need to explain why we need the product than the initial price of the product".
Jasper Bekkers
@Jasper: Isn't that frustrating! However, most bosses think they need to keep control. The best in that situation would be to give the head dev a budget for the small things.
+2  A: 

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.

+1 for the second. Many omit that (maybe that's also a vanity problem).

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!

+2  A: 

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.

I've purchased plenty of tools where only a license key (in addition to the *'testing a free tool'* time line you document) was required. An extra 5 minutes.
Stu Thompson
It's not the actual payment process that takes long, it's getting the purchase approved by our purchase department. (Yes, even a 20$ purchase has to be cleared by them...)

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.

Gregory Mostizky
+2  A: 

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.

This is the biggest issue - license entropy! Even without ISO9001 one has to do a similar dance to buy software at home: consider funds, consider license (one time, upgrades included, annual fee, free trial), purchase, deal with license key nonsense (seriously, I spend about a week to a month each year dealing with license keys etc.).
Suddenly you need to reformat? Opps, time for the license entropy dance! Isn't this fun?
+1  A: 

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.

+1  A: 

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

Bob Moore

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.

Black Cat
+1  A: 

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.

hah! i was going to say this should be a comment. good feedback though.
levi rosol
+1  A: 

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

Nick Lewis

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.
+3  A: 

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.

Ron Ruble
+2  A: 

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


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.


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.

Calling "Source UnSafe" a tool is stretching it... ;-)

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.

Dana Holt

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.

+2  A: 

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".
Great feedback. I asked the question because the topic came up amongst a group of fellow developers / managers / business owners. There really are a number of different answers that could be given all depending on the situation. However, it seems that in my experience, people often spend more time than necessary trying to save $50. By no means is the question intended to satisfy a frustration. It's just purely to collect others thoughts on the topic. Hopefully someone who is building a product, or researching a product sees this, and makes a better choice because of it.
levi rosol
+1  A: 

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.

Umesh Aawte

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


(How do you delete an answer?)

You should have a "delete" link below the post.