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
Related
I am not sure if StackOverflow is the right forum to ask this question. If I am wrong, please point me to the right forum.
I am still junior android developer, and I always wondered about one question.
Do software developers sometimes use internet to check for code syntax or to check for some code for some action, that they never used before, or didn't use for a long time, and simply need to remind themselves about that code?
We use it for anything.
Don't know how to do something at all?
Ask the internet.
Know how, but forget what the function name is?
Ask the internet.
Remember the name, but forget the order of parameters?
Sing it with me: Ask the internet!
There are no rules about when it's OK and when it's not. Use it when it helps.
It depends on the personalty of the developer, I for one had a time in my life when i was code happy and all I try to do then is solve my own problem myself thereby impressing my fellow developers and peers, in return I wasted time doing one simple thing for days and time is money.
But as it is now, money must be made and more money to be made means more jobs to be done for clients.
If I have a whole lot of issues on my mind e.g the flow process of the application, the limited time frame to deliver, another job from a pestering client (who paid higher than the current client), personal problems, etc. The least thing I want to do is to disturb my head about some code I know but cant remember. I look it up in no time.
Yes, I look up a lot of codes i don't remember and wish not to remember and no one cares because at the end of the day it is the developer that get his/her job done at the specified time that is a good developer.
You will find out that as you grow in your career if you work as a freelance programmer, except in limited cases, NO CLIENT will tell you write a sample code to do bla bla bla.
What they care about is the manner in which you solve the problem they have. Your problem solving logic is what makes you a better programmer every single day.
It doesn't mean you should forget all your code but don't stress over it if you don't remember look it up, it doesn't cause a volcanic eruption in central park...lolz.
BUT you must also remember that if you make it an habit to always look up your code, in no time you will have issues reading codes and that is a crime as a computer programmer.
My advise for you as a
junior android developer
is that you learn to disconnect from the internet most times when you write your codes it will strengthen your brain to remember your codes better. Because what i have found out over time is that there are two types of programmers,
offline
online
The offline programmer would survive even in the desert but the Online programmer can only survive in the city.
Lastly if you were a client and you called two programmers to add extra page to an android application. Then you looked at their various systems and one of the was editing his code while the other was on google or other site like stack overflow with page title
How to add extra page to android application?
Be sincere with yourself who will you rather work with next time?
Don't get it wrong there is no crime in asking but sometimes asking is the last thing you want to do because its more shameful that stealing.
Wish you luck in your career path...trust me with consistency you will exceed your peers because you have chosen the extra ordinary careea path.
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.
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 3 years ago.
Improve this question
I'm the leader of a small web development team, and I have a feeling that we will have a couple telecommuters joining the team pretty soon (either new employees, or existing employees that will begin telecommuting). Any idea how to effectively manage and collaborate with developers working remotely?
Most of the work we do is client-driven. We're doing agile development (or our version of it, anyway), but since it's mostly client work, we can't really assign a feature to a developer and set them lose for a week or two like we might be able to with a desktop app or something like that. The biggest problem we have when people occasionally work from home is collaborating - it's tough to work together without the benefit of a whiteboard and hand-waving.
It seems like software development is perfect for telecommuting, but I haven't been able to find many good resources about the practical aspects of working remotely within a development team. Has anyone else had any experience with this?
I freelance a lot and in doing so work remotely a lot of the time. These are the things that make my life as easy as possible (so might be things you want to "suggest"). I think they're mostly common-sense, but you never know...
[Everyone] Communicate well. When you're having a conversation face-to-face, you can be verbose and explain things in a round-a-bout way. When you're limited to email, IM and phone, all parties need to explain themselves fully but succinctly. I find that summarising long emails into request/action points goes a long way towards getting things done well.
[Everyone] Have a online project tracking space. Most tend to use a ticket system or some description, where action points can be assigned to members. It wouldn't hurt to use this same space for tracking emails and sharing whiteboard ideas. Most online project apps allow for that by default.
[Management] Don't pester devs. If you need something urgently, set the status of the ticket, give them a call and chase them up later on in the day. Half-hourly emails asking "is it done yet?" does more harm than good!
[Management] Make sure messages get passed along. If a dev says "somebody needs to do something", it's your job to make sure the message is passed along to the right person. There are few things more annoying than passing a message to a project manager for them to accidentally sit on it. I don't want to have to chase up things like that because it's, frankly, not what I'm being paid for.
[Management] Make sure people have something to do. If you send them home with nothing on their task list that they can immediately action, they're not going to put in the effort. It's a damned sight harder to keep yourself productive at home than it is in the office when you've little or nothing that you can do. You might have to juggle tasks if there's a blocker.
I work at home full time. Here are things that help in my small (6 people) team.
Set up rules for using IM. For example, allow remote workers to block off time not to be interrupted by email or IM. Require workers to keep status up-to-date somewhere (IM, Yammer, etc) which helps keep them accountable to stay on task. Stay in touch without being a distraction.
Meet in person occasionally if possible. Nothing can replace a face-to-face meeting. Skype is ok for group meetings, but not if whiteboards are involved.
Use SharedView or another screen sharing program for collaborating. Screenshots/screen captures are helpful as well to make sure both parties are on the same page.
"Any idea how to effectively manage and collaborate with developers working remotely?"
What does "effectively" mean? I can be negative and assume it means "with me, the project leader in control of everything". I can be positive and assume you want people to be as effective as possible.
Sometimes, "effective" is management-speak for "under my control". Or it means "not screwing around."
The question, then is "effectively doing what?" Effectively "working" is rather vague. Hence my leap to the dark side of project management. [Which, I admit, is probably wrong. But without specific team productivity problems, the question has no answer.]
"it's tough to work together without the benefit of a whiteboard and hand-waving" This is only sometimes true, there are lots of replacements. The "hand-waving" over the internet happens more slowly and more thoroughly.
The group-think around the whiteboard is fun -- it's a kind of party. However, for some of us, it's not very productive. I need hours to digest and consider and work out alternatives; I'm actually not effective in the group whiteboard environment.
I find it more effective to use the alternative "slow-motion" whiteboard technologies. I like to see a draft pitch for an idea. Comment on it. Refine it. A lot like a Wiki or Stackoverflow. I really like the internet RFC model -- here's my idea; comment on it. When there are no more improvements, that's as good as it's going to get.
I work in Mississippi and my home office is in Michigan. I spend several hours a day pair programming with my team with ease. The tools I use are:
SharedView
Remote Deskop Assistance
Live Meeting
Oovoo
Skype
Depending on who and how many will depend on the tool I use.
"Use the right tool for the job and invest in a damn good headset." - Me.
I've generally used some time of community based software such as a wiki, blog, or forum to handle the documentation areas. We also have a Cisco phone system and use some capabilities of the system. I'd also recommend live meeting or webex to do frequent team meetings. Skype and IM clients such as Live Messenger are also good tools. For the short status updates, twitter does the trick.
Check out the Agile Scrum methodology with VSTS. Scrum forces us to have daily 15 minutes meeting and small mile stones , It makes sure the effective togetherness and tight communication. Make sure you use Task,Bug assignment etc through VSTS
I agree with John Sheehan's response. I am a consultant and manage other consultants - both on a project basis (as PM) and on a client basis across projects. I have worked with developers on a purely remote basis as well as telecommuting (meaning the majority of time we are co-located). Working remotely is a matter of trust and communication. Co-locating is best, but if you work remotely, simply create a culture of frequent communication. IM and phone are great for this, email less so. If you have a less than communicative co-worker, it is up to you as the manager to reach out. Ask for status. Force code-checkin on a frequent basis for review.
[EDIT] - Yes, don't pester and set expectations! Be clear and concise.
First of all use scrum (daily scrum calls, scrum board w/ burndown chart (wikis do a great job there), iteration in sprints etc). Next to that use tools that make it more easy to collaborate remotely like skype and VNC (maybe campfire?) and a wiki. I worked for 2 years on a project w/ people in 3 countries on 2 continents and various time zones and it worked quite well. The key is having tools and methodologies that make it more difficult for people to "hide", so that everything you and your team does is visible.
I find clear communication and staying on task are challenging with virtual teams. I try to use regular scheduled update meetings (over the phone or video conference) with a written agenda to help with these challenges.
At the front on the agenda list the major milestones and the near term milestones. The first item is always "check progress" each team member simply updates us on when they expect to finish the particular tasks involved. We try not to get involved in long stories here. It's simply "what are you going to do and when".
Once the progress check is done deal with any other issues raised in during the last week and any issues the team has that can be sorted out whilst you are in the meeting. Anything let over (such as new issues raised) needs to have the question asked "who is needs to sort this out and when".
Once you set a common format for the meeting you can do this weekly in 30-45 minutes with teams of 5-8 people. Keep it short and sweet so it isn't viewed as an imposition. Keep it focused on actions and schedule so it can be valuable.
I'm currently the PM of a smaller project that has two developers (myself and another developer that works out of the office). We are currently having daily SCRUM meetings, which last for about 15 minutes. We discuss what got done the previous day, what problems were encountered and what I can do to help with these problems, and what will be done tomorrow.
They're pretty quick and seemed to be very helpful.
Using a Time Tracking Software for your remote employees can greatly help you in managing the team.
While hiring a remote employee, you would be concerned about,
The amount of time spent in getting a task done.
The quality of the work done.
Collaboration based on the progress of the project.
The real time progress on a task.
Collaborating to solve bugs and logical errors.
I was in your situation a while ago and then I tried StaffTimerApp and it helped me in the following ways.
A Time Tracking Software gives crystal clear statistics about the time spent on getting a task done. StaffTimerApp captures screenshots and converts them into billable and non-billable hours. Hence, you would know if any time was wasted while getting the work done. You would also know the exact amount of time spent in getting the work done. If you pay your contractor by the hour, this application can help you tremendously.
If you use a time tracking software that captures screenshots, you can look at them to analyse the quality of work that is being delivered. I used this feature and was able to save some tasks from derailing.
A Time Tracking Software lets the employer know how far along the employee is with the task, hence the information extracted by Time Tracking will make collaboration easier. StaffTimerApp proved to be very helpful as I was able to collaborate with the other employees based on this information.
The screen sharing feature equipped me with the power of viewing my employee's laptop screen in real time. This way I would get to know about the progress on a task.
So you need a good Time Tracking Software with great productivity analytics and employee monitoring capabilities to feel comfortable with hiring a remote developer.
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.