Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Clarification: I'm referring to companies that pay developers, professionally. I understand why a "hobby" or "for fun" developer wouldn't want to (or couldn't afford) a fully-features pay tool, and may prefer to tinker. I'm talking about situations where a deadline is bearing down on a developer/company and development time is diverted away from the goal in pursuit of a "Free" tool to accomplish what a pay one is available to do.
I've noticed a number of Stack Overflow questions recently (they're not new, I've just recently taken notice) where people are searching for free alternatives to popular development tools for things like ALM, database comparison, and other functions for which there's a trivially costly pay alternative. The "Free" tag on Stack Overflow has 350 questions, and it doesn't take long to see dozens of examples of "Is there a FREE tool to do X?" followed by discussions that must have taken the asker hours to research and participate in.
It's not just about paying less - I'm often amazed at the hoops that some developers (or, perhaps more accurately, their companies) will go through to avoid paying for something - in some cases, a pay solution will be avoided in favor of a poorly documented, buggy, feature-incomplete open-source solution that results in dozens of hours of work that could have been avoided.
I understand the most obvious reasons:
Company is short on cash
Don't pay for something when a (functionally-comparable) free alternative is available
"Hobby" developers don't have the cash to spare, and since they're just learning, it doesn't make sense to pay for a toolset they're only tinkering with
However, I think the "short on cash" reasoning is completely bogus - as a developer not long out of college, I made about $50K annually, or $200/day (meaning my company probably paid close to $300/day to have me in my chair, all considered). When you compare that price to a $300 tool, the obvious answer is "if it's going to waste more than a day of your time, you should buy it instead and get back to work". However, that's not what I observe - people seem willing to kill dozens of hours to avoid paying for something that only costs $50.
Help me understand - as a developer myself of tools I'd like to one day sell, I want to understand the mentality. Have I been spoiled by working at a company that's not afraid to spend? Is there an ingrained reason developers (or their companies) don't want to spend money? Can people not accurately estimate the costs of "Free" tools in terms of lost productivity?
I'm not referring to instances where a great free alternative is available. For example, any of these tools is a great example of something you shouldn't pay for. However, let's say one of those lacks a key feature you need, and which a pay version of the same library provides - people seem to lean towards hacking around with the free version to add the needed functionality (or scaffold in the needed functionality) instead of ditching the free tool in favor of the pay (and feature-complete) version. I'm not saying that's the wrong choice, but it's just a choice I want to understand the reasoning to. The important point is that I'd like to - my intent is not to be argumentative.
What you're not considering are Dependencies and Partnerships.
It's great when companies announce "Partnerships", their marketing and legal teams spend ages wording contracts and press briefings that basically announce "We're now joined at the hip!".
What you may not realise, is that every time you choose to use a 3rd party tool you are tying yourself to that company, unlike a partnership the dependancy only goes one way (like the Marketing and Legal blurb).
What happens if they decide to cancel the product?
Or they change how it works, and suddenly it's not compatible with how you are using it?
Or they double their yearly developer licence?
Here we use lots of open source tools, while there is only "community level support" and the ramp up time may be longer than for an off the shelf tool, we consider that worth the price we're paying.
We are part of that community. If a version is released that breaks our software, we have choices, we can continue with the version we're using, and choose to maintain that version our selves. Or we can participate in the project and patch the code so it will continue to work for us.
If the open source project falls by the way side, we're still left with access to the source code, so we can continue to build and maintain that too if we wish.
We believe going open source gives us far more freedom than tying ourselves to other companies, who can (and do) change their pricing policies.
Cost-per-developer next year could be twice what it is this year. Changing to a different product could equally cost as much or more.
My two cents.
Where I work I can download the free opensource tool the minute I find it. I don't even have to tell my boss that I'm using it.
If I find a non-free tool I might be able to download a free trial, without telling the boss, but if I want to buy the full version of the tool I'll definitely gonna have to talk to my boss and he's not just gonna give it to me. I'm gonna have to motivate why I need it. He is definitely gonna ask if there are any free alternatives and "I don't know." is not a good enough answer. So if I want the non-free tool I'm gonna have to evaluate all the free tools first.
If I convince my boss that I need the tool, he's gonna send a request to another department that's in charge of this kind of purchases and he's gonna have to convince that department that our department needs the tool. Usually not a problem, but sometimes it is.
Anyway, when we tell our boss that we need something it can take weeks before we get it. Therefore it's often much quicker to just use a free opensource tool and not bother going through that process.
I imagine that other work places might have a similar situation.
Two points to consider:
You're a professional software engineer. Not everyone interested in software development is. For some people, this is a hobby... and paying a few hundred bucks for a profiler (or whatever) just isn't worth it.
You're in the US, and assuming US-style income. That's far from universal.
First off, not everyone asking may be funded by a company.
Second, despite the time savings, ideally the salary for an employee is a sunk cost, it's already been budgeted and allocated. There very well may be "no more money".
When you look at licensing, that $300 thing is $300 for Tom, but then he can't let Joe, Frank, and Bob use it. All of a sudden, if the tool is popular, now it's even more costly. It's not like buying a stapler. And then you get back to what was ostensibly a petty cash purchase now becomes a capital purchase.
A free tool can be downloaded and used instantly (usually). Buying even a $50 tool can take a week getting the check from accounting, THEN it can be downloaded.
Finally, many times folks are looking for some little specific piece of a tool, not the entire suite. Yet they're forced to purchase the entire thing. The Whiz Bang Ka-Blammo Enterprise Tool Set when they're only interesting in the 17th bullet point off the feature list.
I'm never afraid to go to my boss at work and ask him to pay for some tools that will help to make me more productive. However, the work that I do for myself, and much of it is as complex as what I get paid for, has to be done with free or nearly-free tools. I have paid for some things where the cost-to-value ratio is really compelling, like Wing IDE for Python development. Visual Studio, on the other hand, is so expensive that I just can't rationalize the cash outlay no matter how great it is.
I certainly appreciate the rationale behind this question. If you are thinking about being a professional tools developer, you have to wonder if it is going to be possible to make any money at it. I would say that you have to very carefully consider what you charge for your products. While you can charge enterprise-class customers hundreds of dollars for a tool, and they won't blink at it, making the sale in the first place is an enormous challenge. With my startup company, we found that it took about a year to go from first handshake to getting a signature on a check. That's a long, long time when you are starving and living off of your savings.
On the other hand, if you can charge less and make it a compelling purchase for an individual developer who is reaching into his or her own wallet for a personal credit card, you can achieve the kind of decision-maker mind share that can greatly short circuit the year-long enterprise sales cycle.
A developer is paid, and generally motivated, to develop stuff.
Picking up a free library takes a bit of research, but then you can pull it in, try it, and keep doing that until you find one that fits. The process of selecting the appropriate free library/tool fits well into the developer's skill set.
In a business, you're right that it's possible to buy good tools. However, to do this you need to make a business case for the cost, and persuade your manager (and probably further up the chain too) that it's worth paying. This requires an entirely different skill set, and one which would take many developers outside their comfort zone. Most of the time, I think developers just can't motivate themselves to start down this route.
Even if "the company" might want to spend money on tools if it's cost-effective to do so, the average developer is not correctly motivated to support this company goal.
Going back to your original question, you were interested in how to sell development tools in this climate, when developers have this tendency to pick the free ones. Based on the above I see two options:
Make it compelling to the developer, so they think it's worth the politicking time to get their hands on it. Time-limited trial versions etc can help here: once the dev has learnt the tool and seen what it can do, they'll not only be happier to ask their boss to spend the money, they'll be better prepared to justify the spending in terms of time already saved.
Make it compelling to the manager, either so the developer knows they'll have an easy sell if they ask, or to skip the individual developer level altogether and sell directly to management. Anything with "enterprise" in the name is taking this approach.
I think there's a mental block against paying for something when you can develop it for "free". I think often developer time is seen as a base cost, something you're paying for anyway, so the additional time spent developing a tool isn't seen as an additional cost, it's something you're already paying for.
The complete opposite exists too. Some developers will blindly buy the first thing they bump into. But I think a lot of developers have various unhappy experiences with paid-for software. Community support can suck. Paid support can suck. Some people get disillusioned with the whole closed-source thing and prefer something open source just because it's open source.
As you're focussing on trying to eventually sell something, here are a few tips to convince people to stop hopping once they've found your wonder product:
State the features. I've too often found a site talking about a widget that just bombards me with latest news, changelogs, prices, yada yada... But doesn't tell me what it actually does! The first paragraph should concisely explain what it does.
Provide lots of example code, sample projects, documentation. Tons of it. The more use-cases the better. Now of course you also need to provide a navigation system so the user can find things but the more examples, samples and docs you provide, the quicker the user can test your whatsit.
Trials make the world go round. If you can, make sure I can test it before handing you any money. If I can't, I, personally, won't be buying it. Money back guarantees come in a close second but as I say, if I can't test it out, however good it looks, you're not getting my money.
Companies I've worked for look for free alternatives (and usually I mean really free, not just free of charge) because "pay ones" often have (or get over time) restrictive licenses on redistribution. I don't want to base my whole product around a for-pay library only to find out that I now have to pay them $1000 per copy I sell.
As a matter of fact, I earned a bunch of money last year porting a product that had been written using a third party web crawler/indexer over to use Nutch instead because the person who'd paid for the product to get written in the first place didn't realize that the third party web crawler/indexer was going to cost her more per license than she was planning to charge for the whole product, and because she also didn't realize that the third party product was built for intranet rather than internet crawling and so ignored robots.txt.
Some times the "management" does not want to buy anything for the "developer" thinking that the latter is getting paid to develop the software. I've been in situations like that and it was really hard to convince the mangement to buy a set of UI controls we needed for a web application.
I personally prefer free tools, because learning how to use a tool is not 5 minutes. to really master the tool you need to spend a lot of time using it. Id rather not waste time in learning something that is not universal and cant be used always. learn once, use anywhere.
Many of those payed software is not that amazing for me to fight with my boss for it. Total Commander is the only tool that is worth the fight, however from time to time I look for free alternatives and I even consider writing one myself.
When was the last time you read your GNU manifesto. Has the concept of copy left been forgotten? Maybe you've forgotten your roots. The world of software development started from the sweat of the "hobby" or "for fun" developer. Remember those two developers in their garage who later made and sold those operating systems? It is not only a part of our heritage to hack out our own solutions but it's in our blood as well.
Also, companies of the pay-to-use solutions are trying to make money. While a good business model will include helping the customer achieve their goals, making money is their first priority and has a good chance of getting in the way of development progress. The free to use community on the other hand, from what I understand, is purely altruistic and has only the utility of the software thing in mind. The community of free-to-use, copyleft, open-source is very strong.
Ideas/concepts were meant to be shared (freely) to advance us as a people.
Sometimes you need free tools if you are not sure will the result bring you enough money. For example you established startup that works on creating app (or site). They don't want to spend money on third-party tools because they can't be sure will it bring money or not.
Another case, i once worked for big company and their budget approval process took too long, i have to find free stuff at least on initial stage.
Have you noticed that most free tools come without warranty (see GNU Public License, v.2) or support? I use tons of 'free' software every day, because as a hobby, I like to develop too. And a good application always gets bought, but back to the why's.
The FOSS community is a large one, most applications are free. Hence, it wouldn't be a strange question to ask for a free or an open source alternative, because well, there are a lot.
A free ride is always better than a paid one. Depends on the attraction, though. Some paid ones are better or far worse. (Babes, Photoshop, Dreamweaver, Vim) comment: "Babes" is not a program.
Some commercial applications require you to pay by creditcard payment. I hate online payments, and I double hate creditcards. I triple hate how companies store my personal information.
Not everyone is a software engineer. Some of us, do this just for fun :D (Linus Torvalds, Matz, Guido, Larry...go on, go on....)
Another line of thought here is how well are those superior pay ones known to everyone? For example, how am I supposed to know every kind of add-in that Visual Studio has? While some may say, "Well, you aren't," then this is another reason for some to not find those great tools out there. Some may be easy to discover and others may require one to know some jargon phrase in order to use some Google Fu to find it.
Another point is what some companies may or may not realize about how they are spending their money. For example, some developers may have some pretty sizeable hoops to go through to get the company to buy licenses for some tools, especially if every developer would have to have a license and some aren't that cheap to get. How well the managers know what their developers are actually doing and what kinds of changes could be made for the better with a little money could shock some people while in other cases the learning curve on using the tool may also be seen as a barrier in some ways as well as another thing to keep track since some tools are available on a subscription-like model rather than an outright buy it once model.
Seemingly since that time when programming and development came into existence there has been an ebb and flow between the commercial and the non-commercial -- these days more accurately described as 'corporate America' and the 'open source community', respectively. I personally chalk all of that up the existence of middle men and profiteers.
On the subject of freeware, I feel as '01' above -- a free tool allows evaluation at my own pace, potentially preventing the waste of valuable funding, which is an important consideration in this current economy.
Shareware is a fine balance, but I personally find most software doesn't provide adequate time for evaluation. Most tools I download are 'once-a-month' endeavors at their highest frequency so plunking down $30-$60 (U.S.) seems unjustified until I know the tool lives up to my desires.
And regarding professional tools, we all know the goals of business. I find the terms and conditions of Scooter Software to be most logical and accommodating. I've used their Beyond Compare tool for years and years -- as a developer invaluable I've found it both valuable and unequaled.
As to your personal dilemma, make your tools good enough, offer good shareware evaluation terms, and charge a reasonable price for it. Choosing popular (and multiple) platforms also doesn't hurt... consider the number of folks who've made a mint selling iPhone applications, regardless of those applications actual utility.
I'm talking about situations where a deadline is bearing down on a developer/company and development time is diverted away from the goal in pursuit of a "Free" tool to accomplish what a pay one is available to do.
This is exactly the situation when you can't use a paid for tool because petty cash/expenses won't cover the cost and getting budgetary approval takes weeks to come through.
Number three from 9 Ways Marketing Weasels Will Try to Manipulate You. It's "Free"! People make irrational decisions about free stuff.
I think that it makes a lot of sence for companies to try to use free/open source products for the following reasons:
Reduce the price of the deliverable product. Why would you expect a customer to buy something that works with a proprietary database when the company can bundle MySQL for example for free? So the company can lower the price and be more competitive.
Usually when buying software/tools, there are proprietary issues.
Usually when buying software/tools, there are dependencies to other also non-free modules.
There are other reasons also, like that IMHO it is considered "trendy", but the most improntant is that the use of free software can cut down the final prices, helping the company gain customers.
It is also important to support the free tools by adding to the momentum of it, sometimes by the simple fact of starting to use it. By finding/reporting bugs, or more importantly, fixing them and giving patches back, you improve them in a symbiotic relationship that benefits both your company and the tools you decide to use (and hence everybody else who also use them).
One good reason to look for free tools is to get a complete overview of the available options. I'd say that's a reasonable thing to do before you buy a product. Commercial software vendors have advertisements, so you'll probably find those, but there might be a great free alternative that you never heard of. It makes perfect sense to check that, even if you are willing to spend money on software tools.
Plain and simple some companies like IQPC.com will not spend even $10 on software and it's even hard in places like this to find a pen or pad to take notes.
I shed a tear for those who have to live like this, it's not easy.
Related
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
So, after 6 months of hard work finally released my application. Today I found the first web site where people download it cracked, and I was wondering if any of you fellow programmers know how to react to such stuff?
Is there anything the software author can do to get the cracked version offline, or I'm just boned and shouldn't create anymore software, but just work on client's projects? What's your advice? Anybody with experience in that?
edit: programming is what I do- so no question about whether or not continuing, just is that clients pay per project in real money, and I still don't know if indie development would pay at least for the time invested, and now with the cracked download I'm trying to evaluate what to do, and if there's way to react
post discussion: As I see how much interest this question generated I'd say even if not purely programming topic the community needed to say what they think. And I'd say this page became a very good read for any programmer interested in the topic.
Ok, I've been selling software online for almost 10 years. I have had several products marketed to both individuals and businesses.
I am always shocked when I see developers are happy that someone thought their software was worth stealing. I mean, didn't you already know that? Why else would you spend time creating it if you didn't think it was worth anything?
I'd wager you would not say, "Wow, I had some great stuff and feel honored someone went to all the trouble of taking it." if someone broke into your house and stole your property. Stealing is stealing no matter if it is a Porsche 911 turbo, music, software or a pack of gum.
There is also another popular myth that pirated versions do not impact sales. I have done a few different experiments myself and also have friends in the industry that have seen significant revenue impacts due to piracy.
In fact, I had one product that I could always tell when it was keygen'd because sales would immediately dive as much as 70%. I was using partial key verification, and when I updated the verification to make the bogus codes stop working sales immediately went back to normal. I assume you would call thousands of dollars a month a significant impact on sales?
In one experiment I used the partial key verification to redirect customers who entered a pirated key to a special web page that explained they were stealing.
Guess what? Over 50% of people who went to that page bought the software. That almost brought sales back to pre-keygen levels.
Those people would have stolen the software if the code would have worked for them. This is a product with a fully functional 30 day trial, so they had already fully tested the software. Also, the product was under $20 USD, so it wasn't an expensive one.
Other people I know have tried the redirect bogus codes to a web page technique with similar (and sometimes significantly better) results.
I do agree that some people will never buy your software, and you have to balance protecting unauthorized use and inconveniencing honest customers.
But don't be fooled into thinking piracy isn't a big problem and not worth investing a reasonable amount of effort to prevent. People aren't as honest as most of us would like to think.
Update
First I want to say, as I stated in my comment below, I am not going to get into an argument or debate about this--especially one based on semantics. I have debated this for years in person, at conferences, and in private forums. I've heard all the arguments before.
Now I will try to answer some of the constructive questions.
I tried my own experiment on two different products.
One was an Outlook add-in to manage various hidden security settings. It was purchased by both individuals and companies. The numbers above are for that product.
I also did another experiment on a business targeted product that translated database schemas to various formats. This product had slightly less (around 10% less, so 40%) conversion from the page I redirected the bogus keys to.
I also am aware of several business owners that did the same experiment and discussed the results with me in private. These were a wide range of products. Some had a vertical market and some were very horizontal. Their conversion rate on the bogus key page was between 20% and 70%. Even at the low end that's a significant amount of extra revenue.
You may want to add something like this:
If someone thought your product was good enough to be worth their time to crack it, you must be doing something right. Remember that there are more honest people in the world than dishonest and you won't get the dishonest people to buy your product whatever you do. So concentrate on keeping your honest customers happy.
I saw this interesting response today:
Contact the site owner. They should remove the incriminated download. If they don't you'll have to sue them.
Anyway you should accept piracy as a natural part of your software lifecircle.
I have to admit that I haven't read all the answers and the slew of comments, but here my view on the topic:
Concentrate on making it as easy as possible to pay for the software. Think of Steam and iTunes. Dishonest people will always go to great lengths to avoid paying, but I think most people would gladly pay you if you make it easy enough.
Keep the price low. If the price is low enough (say $5), it falls below the threshold of "practically free", and people will start thinking "$5 is nothing, I might as well pay".
These two combined will prevent your honest customers from trying to get a hacked copy of your software.
The most elegant solution I've seen was putting text along the lines on "cracks, warez, keygens, torrent files, free downloads etc. harm the publisher of this software" in small text at the bottom of all your web pages. It games the PageRank and (hopefully) causes users searching to cheat you to be sent to your site.
I would keep updating the software. Sure there must be some bugs to fix and new features to add that your customers asked? When a user has a pirated version and is happy with it finds out that your current version has more features that might be an incentive for him to buy the latest version.
Adding new features doesn't only make your existing customers happy, they also attract new customers.
There's nothing you can do. Once the software is out there, it's out there. Sure, you could send all sorts of legal threats and takedown notices to the sites in question. And then those who acquired the software will post it to other sites.
If the software hadn't already been made available for free, you could cram it full of DRM and copy protection and so on.... which just get cracked. Microsoft must have spent billions trying to prevent people from pirating Windows. I still know a good handful of people who run pirated versions of Windows 7 with no problems.
You can't prevent people from pirating your software. What you can do is make people feel your software is worth paying for. Some developers have noticed some effect simply from posting a polite and personal message on torrent sites. On the torrent for your software, post a comment saying you're the developer of this software, and while you're glad to see that people like it, the money from software sales goes directly to you and your dog and no one else, and you can't afford to keep making software if you don't get paid. So please consider buying a license.
Some companies try to combat piracy simply by treating their customers well. Make it something that people want to use. Sell it at a price that people are willing to pay. Provide extras for paying customers. Provide good support to people with a valid license.
Some people are going to pirate your software. There's nothing you can do to prevent it. And it only takes one copy to appear on one warez site, before it spreads and becomes impossible to take down. On the other hand, those people who pirated it most likely weren't prepared to pay for it anyway. If they hadn't been able to pirate it, they simply wouldn't have used it. So in that sense, you haven't lost anything. Remember who your paying customers are. They are the ones you have to satisfy in order to run a successful business. The ones who don't pay aren't your customers, so they're a lot less important.
You might find this blog post an interesting read too.
And finally, because some people find it hard to accept that the world isn't black and white, and like to think that anyone who doesn't equate software pirates with some kind of evil zombie demon hitler are secretly pirates themselves, let me be absolutely clear:
I do not condone piracy. I am not saying you should love software pirates or treat them like your own children. I am merely saying that it is an unavoidable fact of life, and too many companies spend huge amounts on "piracy prevention" which doesn't prevent pirates from using their software, but does make the software less convenient to use for paying customers.
Make you software work as SaaS in some cloud, so you'll be able to sell it for some traffic/features value, and will prevent it from cracking as it is.
This is obvious a highly personal reaction. I don't expect anyone else to share it: Celebrate! Someone thinks your software's worth stealing!
(a) It's impossible to prevent people from stealing your software,
(b) trying to only irritates your honest customers and
(c) people stealing your software means that you have solved the single biggest problem: obscurity. If no one knows of your program, no one's buying it. At least if someone's taken the trouble to crack your software, people know about your product. Another answer here offered several interesting ways of getting people to pay for your product.
Change your business model. Selling something that can be duplicated at zero cost and no limitations, isn't a smart idea.
Copyright and patents are only fake restrictions that can hardly work in the digital age.
The good news is that if somebody bothered to crack your software that means it is popular/useful enough that people actually really want to use it... so you must be selling some!
Secondly, there is a school of thought that says that usage of the cracked version may actually boost awareness of your product and result in MORE SALES long term... Try to think of it as a free marketing campaign... :-)
This reminds me of the autodesk/kinetix response, tho they claimed that the response was a complete accident, a byproduct of the crack itself.
A cracked version of 3DSMax had a nasty side behavior - each time it opened a model file it corrupted the vertex coordinates just a little bit more- not enough to be noticable on any given run, but over time, a lot of damage could take place. The cost of the program might be thousands, but the cost in time and dollars to repair the damage dwarfed that.
The mfgr claimed this was a complete accident/side effect of the crack, and to their credit here, I believe repaired something in their software - that said, they certainly delivered a powerful message to their user base......
Don't get the wrong idea - I'm not recommending this, especially since IANAL - on the other hand, I've always found it's an interesting anecdote
Just take what money you have, and move into another business. I gave up coding after the last bubble burst, and now own a couple of gas stations.
My staff have shotguns to protect our product, it seems to work better than vague legal threats and keygens/drm do in the software world.
It's not possible to make your software crack-proof.
However, there are legal things you can do. You can send cease-and-desist letters to the owner of the website to remove the cracked version from their website. You can also sue. You can contact the ISP of the owner of the website to let them know of the illegal activity of that website owner.
But in short--there's not really a whole lot you can do otherwise.
About a decade ago I created some software for sale that was quickly hacked. Then I created a version with a rather complex anti-hacking scheme in it with a scary (but meaningless) warning that only popped up when partial hacking was attempted--the warning threatened to destroy all data on the C: drive. That seemed to work (it's never been hacked--though its now completely obsolete), but only introduced some ugly support nightmares.
Contact Google with a DMCA notice, and have the page removed from the search index. This will make it difficult for people to find the pirated version.
http://www.google.com/support/bin/static.py?page=ts.cs&ts=1114905
My friend wrote this article describing how he handles this situation.
You never told us if the cracked version is from a demo version or not - but you should identify this directly from your builds.
Is my practice to identify customers in the build's with a ID constant in several places. That way I can find the source of the leak just downloading the cracked one.
Demo versions are prone to be cracked (but you should identify them too - one ID for tucows, other for major, etc). I don't have a easy way for that, except if you can consider online usage all the time.
Regards
Rafael
I believe that widespread software piracy usually means you're charging way too much for the basic version of your product, and that you'll ultimately be able to make much more money by drastically lowering the price of this entry edition - the market may even want this edition priced free. The key is then to properly segment the market to figure out who is able to pay what.
As an example of this, look at Visual Studio vs Delphi/C++ Builder. The two used to be very competitive, with old Broderbund/Borland perhaps even ahead of Visual Studio at one time. And then Microsoft figured out they needed to give away a base version of Visual Studio that honestly has enough features for most of us to get by if we really needed to. The result? Delphi/C++ Builder completely lost the low end of the market where the students are that feed into the more-lucrative professional market. Now they're fading fast into irrelevance.
It's simple. In the old days, if you couldn't afford or didn't want the cops to protect your well, or if -- in fact -- the cops didn't care, know what you'd do?
You'd POISON THE WELL.
If I were you, I'd increase prices by 5%. Then I'd release a fully-functional demo that says "Registered to [crack]" that accidentally cracks up and malfunctions.
Publish this new version everywhere. Bitorrent, edonkey, usenet, all the pirate sites you find. Drown out the competition!
Then direct cracked users to customer support and offer them a 5% discount if they register now and give the site where they downloaded the crack.
Use the crack as a promo code to drive sells.
I'd like to add, not paying for your software is like not paying your taxes. You may be getting ahead, but you are doing so by screwing everyone around you.
Just accept it. most people that are pirating your software probably wouldn't have bought it anyway. But that's not a reason to stop making software, pretty much every major piece of software gets cracked and pirated, but Adobe, major game studios, etc. are all still in business.
open source your software, then you won't have this problem :-)
I was so infuriated with some of comments and answers that justify software piracy that I had to write long rant: Is Software Piracy Stealing? .
Consider piracy as a business expense that comes with the territory of having a product that can be sold to thousands at near zero product cost. We can't have it all our way.
Just use basic protection to stop customers passing it around. Anything more is not worth the time and expense.
Don't make your paying customers jump through licensing hoops. Often I'll pay for a product, get driven crazy by the licensing scheme and seek out a cracked version.
Make trials not by period but by hours used. It's easy to get diverted and not have a chance to evaluate the software. Most people won't consider to ask for an extension.
Consider if you've pirated music CDs, movies, software etc. yourself and rest in peace knowing it somewhat evens out.
Always have different levels of your product. People don't want to pay big bucks for a product they only use 10% of.
Make the product fantastic. Customers will eagerly await the latest version and not want to wait for a crack to appear. The users of poor products think, "I hate this product, it's full of bugs, but I haven't found anything better yet". That's inviting piracy.
I find it disappointing how much people accept defeat nowadays and ignore ethical trespasses and things like fairness.
Make sure you properly version every update and version of teh product. Then store the hash of your executable file on a server and on first launch check to see if the exe file is altered. then you can take action if it is, like closing the program or deleting some of the file You installed so that the program won't start
I don't know for sure what I would do in your position, but at least one developer who found his cracked software available as a torrent emailed the host to complain -- not about the crack, but about the quality of the crack. It seems that the cracker didn't do a very good job and made the software less desirable. The developer was apparently horrified that his product, with his name, was going out to people and would ruin his product's good reputation, and demanded that if someone was going to crack it, that they needed to do a better job!
This story showed up on Slashdot:
Developer Demands Pirate Bay Not Remove Torrent
Also consider price. I have no idea what your software is but there are multiple markets for every product. For example Photoshop has a normal version that is a little out of the cost range of anyone wanting to touchup their vacation shots. For this reason they make elements, it doesn't do as much but it does serve a market. If your software is expensive and of limited personal use try releasing a home version. A trial version, an ad supported version.
What every you don't attempt to detect hacked versions. This type of DRM only annoys real users
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a few software developers working for my projects and I would like to provide them a way to register time they spent on real development.
There is good will to register development hours, no force, but we try to avoid techniques like excel sheets register because this is so uncomfortable.
I can track svn commits, but this is unreliable. Developers also helps supporting different projects during the day, so assuming they work on one project by whole day is not true.
I've seen utilities that popups a message every hour to confirm the project you're working on but this is annoying.
Some kind of active-window-title-anaylzer might help (you can get solution name from there in the case of Visual Studio) but I have no experience with such idea.
If you have any experience with programmers/designers work hours registration, please share with me.
Thanks
Its a good question, and the very best way you can measure hours spent on a development project is not to measure hours spent at all.
You say there is good will to register hours, but I have my doubts. Realistically, from a developers point of view, excessive time management is a distraction for most (perhaps ALL developers on the planet).
I can understand why time is measured so excessively on ODesk. There is a good reason for this, because project time is paid up front by the client to ODesk, and the developer needs to prove to ODesk hours worked. Payment is also guaranteed, and its unlikely oDesk providers and developers ever meet in real life, so there is no trust.
Since its unlikely you're paying your developers upfront, and its more likely you have better trust established, you need to perhaps switch your attention from a management strategy that's cludgy and annoying, to something way more useful.
Yes ladies and gentleman I am talking about Scrum. Throw any notion of keeping hour per hour tabs of your developers out the window (they'll love you for it). And instead introduce Scrum Management into the scenario.
Create some sprints (milestones) for your product development, and in that have a list of iterations (batched deliverable s), try keep your iterations down to a weekly period.
Create a product backlog, and make sure you're aware who exactly is working on what. Find someone on the team to act as a scrum master on your behalf, or to take on this responsibility yourself. Make sure you have daily feedback meetings, keep them short and focused, to identify any risks that might get in the way of deliverable s. Let the developers more or less drive the timing process, and get realistic estimates for tasks.
Read a book or 2 on scrum, and get others and team members involved in the learning curve. Tweak the base scrum methodology to best suit your particular style of management, and I assure you, you will have a very happy team.
Measure your time in man days, and try avoid getting on the back of a developer for hour by hour progress...
There're various time tracking software tools as you have probably already seen from doing google searches. But in all honestly you are asking for the Holy Grail of time tracking. For example do you consider a developer staring at her code and thinking as development time? She might stare at the screen for 1 hour and only type for 10 minutes. In this case it looks like they don't work much when really they worked for 1 hour and 10 minutes. I don't mean to say what you asking for isn't a valid thing to want it just seems to be one of those problems that doesn't have a perfect solution.
Good luck.
I think you're asking the wrong question and are headed for a slippery slope. There's so much that goes into development that has nothing to do with actually coding.
I think a better solution if you're deadset on tracking something is to track the time spent on activities NOT related to development. Of course there's some grey area there too. For example, a meeting to discuss user requirements should probably be counted towards development even though no coding will get done.
you need something like this dashboard to measure time on task. The only way to know the real software developer time is to have then track it. That way when they switch tasks they stop the clock so to speak. I think the hardest thing would be getting the developers to use it as a measure of how long they work on a certain project or even code module, etc. If you can then use those metrics to reduce distractions and other time sucks, you might at least be able to get a decent swag about how much time they spend coding versus email versus talking to other developers, etc.
If you're trying to measure what the developer has as their active window, you have to assume goodwill, because any decent developer can sneak around that if you're trying to turn the screws on them. I spend about a third of my "development time" in Firefox looking at references, for example.
Maybe ask the developers just to keep a log, so you know where their time is going? Whereas that's not ideal, you're never going to do much better than that.
If you are trying to measure the time spent on distractions and disturbances and other task, would it not be in your developers interest to give you this information willingly?
You said somewhere that you are implementing scrum.
If you really have to either take it up at the daily scrum, making it a part of the ritual, or add a very short daily meeting at the end of the day. Let the developers guesstimate how much of the day was spent on distractions and disturbances and other tasks. To me that feels like it will be as close to "correct" as any other way of measuring, considering the difficulties involved.
So, instead of having the developers note down the time, make it the scrummaster's job to sum it up, and make this as painless as possible for the devs. Make sure that the developers gain something tangible from doing it as well, otherwise it is going to end up on the impediment list awfully quickly.
As Dean J implied, you have to trust the developers anyway.
it depends on your IDE - if you are using Eclipse then I recommend using Mylyn plugin. You can measure the time spent on each task. Tasks can be fetched from every famous task repositories i.e. Tuleap. details here
User only need to put the task in Active mode - and deactivate when task is finished to able to stop the timer. I think Mylyn will support such process - if a status of a task changes then this would trigger the active mode (if closed then deactivate the task)
Sometimes development involve using a browser, or a terminal. Eclipse can be used as a browser and as a terminal as well - so developer does not need to leave Eclipse - so almost every activity can be measured related to a task.
Try DotProject or XPlanner
An active window analyzer won't give you reliable results, because your developers will swap between programs (Outlook, File Explorer, version control, internet browser, etc.). Your proposed analyzer won't log that time, although it will very likely be part of the development time that the developer puts into the project (software development is not just coding in VS all the time).
Trying to measure a developer's work hours is the wrong notion. A proper question to ask is what is a programmer's effectiveness. That can't be measured by coding time, time spent sitting in front of a computer, or the like.
As Joel Spolsky put it well in a blog on software craftsmanship, software development "...is not a manufacturing process."
A related but somewhat different discussion appears in this SO article on an invasive programmer productivity measurement tool.
I definitely would not recommend you to use any time measuring software where the developer is forced. It is a massive distraction to developers' concentration.
Instead, the following simple techniques can be used:
Spreadsheet: For smaller projects or team of developers
There's probably nothing easier than to create and share a spreadsheet online, add project tasks to it, assign tasks to a developer, let the developers estimate hours for theirs tasks, let them update their task status(es) (very rough value between 0% and 100%) as they want, let them specify time (hours) it really took to complete the task.
So in the spreadsheet you may have columns:
task name, assigned to, estimated hours, real hours, done (%)
Google Drive spreadsheet may be the answer.
This is a very simple and fast method which distracts developer(s) minimally.
Scrum: For medium to large projects or team of developers
Tasks and the Scrum information are recorded and kept on a board in the office and/or a special Scrum application can be used. A good web Scrum application is Pivotal Tracker which I would recommend for any size of project or team.
More about Scrum:
http://en.wikipedia.org/wiki/Scrum_(development)
In both cases, the product owners (clients or those who deal with clients), project managers and all developers can better and faster:
communicate
estimate
see progress of the team and all individuals involved
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
I've seen a lot of questions and discussions about build vs. buy, but most stick with the simplistic approach that you can simply do one or the other. Most of the time you have to either buy and integrate or build yourself. Either way you're in for some work.
In the next 30-60 days I NEED to implement a couple managerial projects to keep everyone from ripping their hair out and killing each other. The largest of which is a ticketing system (emails, support requests, self service, etc.).
There is no shortage of options but at the end of the day we'll have to buy whatever we decide to use, add all our clients and their users and make sure we keep things in sync over time. We'll also have to provide a single sign-on and do some design work to make it all look like we built it from scratch.
If we build we get to skip the integration pain points, albeit with a limited (but focused) feature set.
What do you typically analyze while making a decision like this? If it better to have 4-5 systems that do a very specific job well, or one monolithic system that does everything?
You've identified a key issue - when you buy you still have work to do, and potentially lots of it. Having said that my overall leaning every time is towards buy. Writing code is hard, debugging code is much harder - when you buy, you're not just buying the code/application you're buying the fact that it works - the latter is 90% of the benefit.
However, as your needs are pretty common, why not go with open source. This has two stand out benefits.
1) As you have access to the source, you can bend it to your will - ie no need to lash single sign on over the top of an existing system. Tailor the login modules to use your already existing infrastructure, therefore no need to keep things in sync, time savings, clean approach etc etc. Much open source acknowledges the real world by componentising (?) those aspects which are environement specific anyway. They're often DB/Identity agnostic.
2) If you choose wisely you will have a ready band of top tech staff who already understand the system ready to help - the only problem is they don't work for you (yet!).
My advice would be pick one of your easy targets - the ticketing system seems like the one, analyse whats out there that in the open source world that meets most/all of your needs. Evaluate and put out a request on Rent A Coder for any changes that are required. Sit back and await the results, which are hopefully excellent. You've lost a little time, and gained a lot of experience.
Open source does not equal Linux/Unix - lots of good stuff for .Net out there too.
One system is better for the following:
One data repository(i.e. the Database)
Easy way to link each system together, do cross referencing. No need to build intermediate importer/exporters/sync-ers
Allows for single log in. This is very useful in businesses to make sure everyone know where to find the right information. So more "what was the site for the bug tracking again..." Not everyone will use all the tools the majority of the time, and they will forget how to access and even use.
Everything has the same look and feel
Saves on training
Maintenance is cheaper. Everything is the same to update. Admins dont have to specialize in hear separate system.
But... obviously you're stuck with what you buy. Make sure to get a system if you can that you can build your own addins for, to match it to your busienss' model.
Obviously "it depends." My general rule is that if it's internal we buy it and integrate if required. Our corporate sys admin has a support line to someone external to our organization if she has issues and it isn't a huge project burdening our developers.
If it's part of a product I'm shipping, I build it or take bits of source as needed from open source libraries. There's nothing worse than someone else's black box code breaking your product. The fewer the dependencies in a shipping product the better, IMHO.
I'd lean toward buy for a support product like you mention. The good ones offer great integration points to shared authentication systems, user facing theming, and probably a boatload of features your customer service team hasn't realized they want/need yet.
But, what to analyze. The biggest thing for me when it comes to 'managerial' projects like this is opportunity cost. What else could my team be working on that will make our company significantly more money, get us more customers, etc? Of course these projects have some positive impact on the bottom line, but nothing compared to new products, improved products, etc. How long over time, including maintenance, will developers/pm's/testers spend on this managerial project? If you buy, integration points don't change often, but if you build, your customers (in house people) will be asking for new features constantly and you'll be in the position to maintain this project for the rest of your tenure.
Buy? What is this buy of which you speak, stranger?
Seriously, I haven't had to buy a piece of software for my own projects for a long long time. All my development tools are free, all my third-party libraries are free (not GPL). Even my OS is free. I have to pay for Windows for testing purposes but the majority of work uses tools that are cross-platform.
Anything that requires code not immediately available from free tools or libraries, I either write from scratch (all the algorithms are available for free on the web) or use my (huge since I'm so old) snippet library which I've been adding source code to for many years.
It's almost always quicker to buy ("obtain") than build unless the bought stuff is so crappy that integration is a nightmare. This can be mitigated by avoiding the latest whizz-bang stuff from suppliers that have little track record.
The more 'standard' your requirements, the better buying fits (Or to put it another way, don't reinvent the wheel). Conversely, the more unique your requirements the more you might consider building.
You quite rightly point out that even when buying there tends to be some customisation. Bear in mind that any customisation will cost you at each upgrade/patching time. I suggest that if your requirements are close to the business model supported by one of the tools you might buy that you serious consider realigning the business process to the vendors standard. If this is not possible ask if you are buying the correct tool.
I would suggest that if someone suggests building it for cost reasons run screaming. In my experience the cost of buying is well known and the cost of build is well hidden. Remember that you will be making a decision to keep coding for the life of the App (average of 7 years for a business app) but may be considering only the initial development cost when deciding between buy and build.
I have a strong preference for a single monolithic database but sometimes this is not workable. More important is to have a 'single source of the truth'; if you have multiple databases holding like data, pick one as the authoritative source of a given piece of data and have a process to maintain all others in agreement with that source. Preferable this will be automatic.
The monolithic system that does everything is the the Raison d'être for so many Enterprise applications. What I've found, however, is that if you're not willing to pay a buttload of money, you're going to have integration issues.
The 'best' solution is quite subjective, and any answer is as right as it is wrong, but if I were king, I'd probably go with the entrenched open source solution where it fit, and wrap web services around the items that needed to talk to each other. If I were king.
As a tangential point, there are free ticketing systems like RT (et. al.) that you need not worry about buying.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What prompts my question is this post from Jeff Atwood, and this post from Dare Obasanjo. It seems to me that there might be at least a few areas where third-party functionality is a better idea than custom code.
For example, should logging always be third-party? How about encryption? Or search?
I'm looking forward to everyone's feedback on this.
Edit: This question assumes that logging, encryption, and/or search isn't your core business.
Encryption should be third party most of the times, ...unless you're in the business of selling encryption systems.
Which is pretty much Mr. Atwood his point as I understood it, your core busines shouldn't be third party, so there's probably nothing that should always be third party...
My rule of thumb is to use (or at least consider) third-party for anything that's outside the core purpose of your business.
Encryption's always been the prototypical example of this. But it extends to other areas as well.
Writing logging code for troubleshooting during development is entirely different than writing logging code used for monitoring production systems.
It's all about choosing which areas of development actually add value to your project. Using third-party stuff removes the risk that that component is incomplete/buggy/etc. but comes with the risk that it may not be as flexible as what you need.
Another example would be developing an entire web forum for a website, when you can buy a solution for much cheaper.
"What functionality should always be third-party?"
None. there is always an exception or special case to overrule the egregious use of "always" when discussing an essentially engineering decision.
Further, the decision to go third party should almost never be made on basis of a given "functionality." There is no such thing as such a perfect library that you never need go anywhere else for that type of functionality.
Going third party is a decision that should be made based on
Cost of going third party vs cost of doing it in house
Development time required placed against deadlines (ie, it might be cheaper inhouse, but your development timeline might not allow it regardless)
Ease of integration, debugging, maintenance, upgrade paths - it may be that you can develop something that will "do the job, but barely" inhouse vs not much more money for something that will take care of you for years to come
Ease/cost of testing and proving - security packages are notoriously difficult to test well
However. There are some things where it's really tough to believe that going in house is better. For instance, you can write a competitor to OpenGL and DirectX, and in certain applications (scientific computing, etc) there are good reasons for considering such a path. But in general you wouldn't dream of it. Even though it's "free" it's still a third party dependency, and you could end up on the skids because of a bug which only affects how you use these graphics languages.
In other words, some incredibly complex or hard to prove/test things exist which should almost always go to a third party. Security is another one. Don't write your own hashing algorithm unless you are 1) certifiably crazy and 2) have at least 3 excellent business reasons to do so.
But "What functionality should always be third-party?" None. There's always an exception.
-Adam
I fully agree that encryption should only be done by experts whenever possible. It should also be open source and have undergone a good deal of peer review.
It depends. Is there a 3rd party library available that suits your needs and most importantly, the language and/or API you work with. Then go for it.
If you have reasons to do your own version, make sure it's not just "not invented here". Also, if you haven't had an in depth look at the market's top five leading products for whatever you need, you haven't done your job thoroughly enough. There are good chances you will find what you are looking for, and even if you can't use it, you still learn something even from the library descriptions. At the minimum you will learn which features you would need and which you don't. If you also get the source code to one of the libraries, this should be your preferred choice over a competing library with no source code but possibly more features.
The area where I have consistently used third party controls was charting. It is a fairly common problem to have to chart some batch of data and the third party controls are mature and trustworthy.
I guess the answer depends upon the usage. If you are developing for profit, you would be likely to buy in components if the cost of using the component vs the cost of developing it results in more profit. This is particularly the case with large components when you do not have the in-house expertise to produce them.
A couple of good examples that I have used are the Infragistics controls and Dundas charts. Although we could have created these in-house, the costs in terms of time and lost opportunity would be huge compared to buying a couple of licenses.
Of course, sometimes we do this type of thing without even considering it as a component purchase. Streching the imagination a little, you could include the .NET framework, SQL Server, the Windows API, etc.
If you can buy it cheaper than you can build it, and the bought functionality meets your business requirements, then buy it.
There is not a definitive answer to this question because just like anything else in software development it depends on the situation. I would say that if the following 3 items are true than you shouldn't think about doing it yourself...
If it's not core to your business or expertise.
If someone else has written it for you and it is being used in widespread communities.
If it meets your needs and requirements or it can be extended to meet your requirements fairly easily.
This question is the inverse of the question: what software should you create?
Which is obviously silly.
For both there is no one answer, it depends on the needs of your business. Do you need to build a better search engine for the entire internet? Almost certainly not. But if you are Google in the late 90s, you do. 3rd vs. 1st party is just a matter of which office you work in, every 3rd party is a 1st party to themselves.
If all you need is good enough: use something off the shelf.
Either you'll create something lower quality or you'll waste money and effort on something that doesn't matter that much, or both.
If it's the foundation of your business: build it yourself.
If you can build something better, and you can build a business out of that better thing, then do!
Don't forget that the time is a big issue for writing all things by your hand, it is not that you cannot do that but the problem comes from your customers or company they always want to find the fastest way to build their system. But if you have a non-profit project you can try building things by yourself. For e.g you can use JQuery or Dojo as your ajax toolkit if you are writing web applications and you want to set some ajax functionality, it will take time to build those things by your hand :)
But you also must be careful when using a third-party libraries, you must trust them because they can contain malicious code, or they are very poorly written and can cause you headache.
Your own encryption function? dont even think about it but I think you probably meant some kind of wrapper for existing functions.
3rd party component advantages:
Alot of functionality
Fully tested (hopefully!)
Doesnt take time to develop so can be cheaper (but..)
Disadvantages
Is it really flexible enough for that next akward customer requirement
Distribution can be expensive
Ties you into 3rd party company which can be a pain when they make a new release to fix bugs
You dont learn to do the task yourself
Whether you use a third party component is going to depend on your application and the requirements. Something like graphing is going to take ages to get right so would be a good third party component to use.
Anything that is outside your core business is a good candidate for third party solutions. You want to spend your development time creating that core functionality that is unique(ish) and can not be purchased and used in a cost effective manor.
For example, lets look at web gridview control. Can you develop and extend a gridview yourself? Sure you can, but to develop, code, and test you grid view is going to take X amount of time and resources, which you can translate in to dollars. Now you have factor in reoccurring costs for support, maintenance, and bug fixes.
Now lets use the arbitrary amount I remember reading in some mag about the average US developer making $40 per hour including their benefits. There are whole web control suites available for around another approximated $800 per developer license. If your developer spends more than say 25 hours total on this one control, you could have purchased a whole suite and spent 5 hours integrating and testing.
Now hopefully I didn't get too confusing there, but the general gist is if you can buy it off the self it will probably save time and money, and instead focus on things you can't get off the self which are usually your money makers.
I'd say for writing boiler plate code, or redundant code which is copy and paste almost every time should be done through a library. For me, validation code almost always has me making stupid mistakes, because it's boring. Spring.NET is amazing for this. I'm so glad my boss encouraged me to try it.
seems you have all the answers you need, but i would just like to throw my opinion in here along with everyone else's. clients pay you to make applications that work specifically for them, and that's usually why they go to you; something they need isn't found in any other product on the market. thus, your focus should be on developing that specific part they need.
undoubtedly your application will need to do other things as well. maybe it will need to connect to a database, or encrypt certain lines. this is where third-party libraries come into play. you don't want to waste time writing a new driver for a database, or a new encryption scheme that might have holes you don't have time to test. you want to use the ones that already exist, and have been extensively tested and optimized.
remember, the faster you finish, the less they will have to pay. this makes them happy and want to come back to you. this also means you make more because even though they pay less, you can work on more projects, which means more money.
in conclusion, you should rely on third-party libraries in miscellaneous modules.
My dad always says "Responsibility without Authority is meaningless".
However, I find that as developers, we get stuck in situations all the time where we are:
Responsible for ensuring the software is "bug free", but don't have the authority to implement a bug tracking system
Responsible for hitting project deadlines, but can't influence requirements, quality, or team resources (the three parts of project management)
etc.
Of course there are tons of things you could say to get around this - find a new job, fight with boss, etc....
But what about a technical solution to this problem? That is, what kind of coding things can you do on your own without having to convince a team to correct some of these issues - or what kind of tools can you use to demonstrate why untracked bugs are hurting you, that deadlines are being missed because of quality problems, and how can you use these tools to gain more "authority" without having to be the boss?
***An example - the boss comes to you and says "Why are there so many bugs!!?!?" - most of us would say "We don't have a good system to track them!", but this is usually seen as an excuse in my experience. So what if you could point to some report (managers love reports) and say "See, this is why"?
All you can do is your best, don't feel as if the key to successful software is only in your hands, your part of a team and don't have to be responsible for all.
Obviously you are in a environment that affects negatively your software, but can't change all his behavior so I recommend you start with yours, start working as a team of one with your own bugs, deadlines, requirements, quality and resources don't bother for the rest of the mess, but try to be the best at your work.
Working as a self-directed team of one showing your boss your plans, and reports of your progress, asking for more resources when you need it and showing him how your plans get affected when he give them to you or not.
You can find more advise about this in the PSP and TSP articles of wikipedia
After showing your boss a good work and meeting your own deadlines, surely he will trust you more and let some of your ideas flow to the entire team.
You don't need a bug-tracking system, you need automated tests: unit tests or otherwise. You can set-up automated tests with a Makefile. You can always find paths that are blocked by management, but that doesn't mean there aren't things you can do within the constraints of your job. Of course, the answer could be "find another job". If you can't find another job now, learn some skills so that you can.
The simple answer is -- you can start using the tools yourself.
Improve your own work. If people want you to fix code, tell them to file a bug. Show them how. Make sure they can do it without installing anything. They want a status update? Tell them to check the bug. They ask abou a code change you made? show them how to make a source control history query. or just show them on your box. Start showing them this stuff works.
And when you need the same results from them, demand that they do the legwork. When you can't find the changes in your source control, ask them to start diffing their revisions manually from the backup tapes. Don't do their work, or the work of source control and bug tracking, for them.
And most importantly, when applying this peer pressure, be nice about it. Flies and honey and all.
If they don't get it, you can continue to be the only professional developer in your company or group. Or at least it will help pad your resume: 'experience setting up and instructing others in CVS and FogBugs to improve product quality' and the like.
As for specific tools for showing that untracked bugs are hurting the team's ability to produce quality code, you've got a catch-22 here since you need something to track bugs before you can show their effect. You can't measure what you can't track. So what to do?
As an analogous example, we recently had a guy join our team who felt the way we did code reviews via email was preposterous. So, he found an open source tool, installed it on his box, got a few of our open-minded team members to try it out for a while, then demoed it to our team-lead. Within a few weeks he had the opportunity to demo it to all our teams. The new guy was influencing the whole company. I've heard lots of stories of this guerrilla-style tool adoption.
The trick is identifying who has the authority to make the decision, finding out what they value, and gathering enough evidence that what you want to implement will give them what they value.
For a broader look at how to lead from the middle, or bottom, of an organization, check out John Maxwell's The 360 Degree Leader.
If you want a report about quality and it's impact on productivity - here's the best:
http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html
Caper Jones has a few books out and is still showing up at conferences. Outside of a good IDE a developer/IT group needs source code control (VSS, SubVersion, etc ) and issue tracking
If an accountant is asked to produce a set of account without using double entry and don’t balance, no one would expect the accountant to do so.
However double entry has been in standard usage by accountants since about the 13th century.
It will take a long time before we as a profession have standard practise that are so ingrained that on-one will work without them.
So, sorry I expect we will have to face this type of problem for many year to come.
Sorry for not answering your question directly, but...
I feel strongly that the failure you refer to is one of communication, and it's incumbent on us as professionals to develop our communication skills to the point where we are respected enough and trusted enough to leverage the authority we need to improve our working environments and processes the way you suggest.
In short, I don't think there is a technical solution that can solve all the problems created through poor communication in the workplace.
If anything, technology has caused the attrition of direct face-to-face communication.
Sorry, I'm off on a tangent again - feel free to downmod.
Coding only you can only keep your own source files tidy, well commented, keep the bug count low with tests. But you are going to need external tools for tracking progress and bugs (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, a blog, whatever). In these cases the people and the discipline and the good habits and the leadership are the overwhelming force, no software tools and no offert from the individual can win alone.