Related
During the past weeks, I developed and published a small OS X utility app that sells for ~$3 in the Mac App Store. However, due do French export laws for apps that include encryption mechanisms, the app is not available in the French app store.
(It ships and uses libssh2 and implements SCP over SSH, and therefor does not use "encryption mechanisms that are provided by the operating system" - the registration process for that is all in French and neither Apple nor the French government seems to be able to help with that.)
As I got a bunch of emails asking why the app is not available in the French Mac App Store by now, I thought about offering a non-MAS version of the app. Coming to my initial question, I'm not sure if I want to spend time on implementing any kind of license key check etc., or just offer that version completely without DRM / license checks as it surely will be cracked either way. (The Mac App Store version is available as a torrent for quite some time now, so whoever wants to steal the app will do no matter what I finally do.)
So, I'd like to ask you guys how you handle this, or how you would handle this if you were in my situation? Spend time on implementing a license key check that will be cracked either way, or just offer a non-DRM version that'll sell in France to make everyone happy?
Thanks.
Disclaimer: Original thread from HN (https://news.ycombinator.com/item?id=7796397)
Update to finish this up:
I finally decided to implement a license validation for the Mac App Store version that is very hassle-free for the user. In the best case, he doesn't even notice this, in the worst case (where no receipt is found within the app bundle) the app will trigger the storeagent to download the receipt and then successfully relaunch. Pretty simple.
For the non-Mac App Store version (which I've introduced because of the French App Store issue explained above) I stick with a 3rd-party contractor who handles all the licensing for me.
I guess this way is a good tradeoff between security and positive user experience. Thanks for your input.
In my experience, if you are going to sell the software, you should consider a very lightweight license checker. As you pointed out, people will break your DRM if they are sufficiently motivated, so you can't hope to prevent intentional piracy. However, having a simple system that reminds users who download the software online that they should pay for it (and if it makes sense providing a basic trial system) is a reasonable approach.
However, don't spend too much time implementing the system, and make sure you thoroughly test the key system before every release, because trying to explain to users that you accidentally made it impossible for them to use the software that they have paid for is something you never want to do.
Bigger than the question of whether it's going to be hacked is whether the overhead of managing the licensing will overwhelm the profit. For example, I've seen people with very inexpensive apps basically have a checkbox for users who bought the app in order to turn off the reminders in trial versions. Very shareware-like, but considering the cost and potential review hassle of a problem with licensing, it might be worth considering that approach.
If you want to put in a bit more effort, there are a couple of open source libraries, including Aquatic Prime that provide more sophisticated protection , but require integration with whatever type of online store you are using. Since it's reasonably widely used in the community, store systems like FastSpring provide built-in integration with it. Also, it looks like the open-source Potion Store supports it out of the box. I've not used it personally.
Beyond that, my experience is that they are a large pain to create/debug/support and unless your app is expensive enough to require special features like partial-enabling, expiring licenses, region testing, real-time revocation, etc., it is likely not worth the effort to do anything custom.
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 needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We plan to sell a Windows portable application. By 'portable' I mean that it can be run from any Windows computer without installing it. For example from an USB stick etc. However the application while (theoretically) it can work anywhere, is targeted to LAN environments.
What solutions do you see that while keeping this advantage (in a more or a lesser degree) to still make money from it?
PS: The application is/will be written in Delphi.
If you are offering your product for sale and not for free, then you will most likely make money from it. If what you are asking is how to maximize the income and prevent piracy, then that is a more specific question.
The key to making money with software is to make the purchase route less painful then the piracy route. Usually the biggest hurdle to purchasing software is the price tag (but not always, some people just will never buy software and always pirate, but you can't do anything about that). And the biggest hurdle to piracy is some sort of DRM scheme, which is actually the second largest hurdle to purchasing software. Often times DRM only annoys the legitimate purchases, while the pirated version has all the DRM removed with less effort then you spend to put it in. Thanks to the wonder of electronic duplication, once the DRM is removed, then everyone can have a DRM free copy.
So you want a solution that only annoys illegitimate usage, but not legitimate purchases. This is much harder to do then expected.
Depending on the price tag for your software you might consider deploying it on a keyed USB drive (i.e. Dongle or USB stick with some special key). Then it is portable, but only on the hardware you provide. The user never has to worry about a secondary authentication scheme, and the DRM only becomes an issue when the hardware (which is harder to duplicate) is changed.
You say that it is only for a LAN environment, which doesn't necessarily mean that the computers will have internet access (and if they do, they probably have a proxy requirement) which means "phoning home" will be problematic. If you want the product to only be used on a specific LAN then you might require a license server to be installed on the LAN. Then the software could always check with the license server to make sure it is authorized. That won't work if you want it to run on multiple LAN's though.
Conversely if your price is low enough then most companies and people would rather buy the correct licenses and not risk the piracy. In actuality, depending on your clientele, most people will prefer legitimate licenses when they can, and DRM can actually discourage them from buying licenses.
Some alternatives:
Use a dongle, where the user of the software must plug in the dongle before your application can work.
At startup read a configuration file and if this is invalid or missing, halt the application or reduce its functionality. The configuration file should contain information about the user or company that licensed your software, and also a checksum to prevent users from changing the file. With such a file, serious companies are less likely to distribute this configuration files to others. Of course, you should then create one such configuration file per user that licenses your software.
Optionally, include specific computer information (type, memory, bios date, system guid, ...) that prevents the application from being run on other computers.
Make sure you make money from the service you can deliver, not only from the software you are selling. This service can include: providing upgrades, taking suggestions for improvements, assisting with problems, helping with domain-specific knowledge, ...
You can use some sort of license file and a "phone home" option that makes sure the same license is not used at more than one place concurrently.
If you have a large ordfer, you could try to get a memory stick with a special serial number and/or value in it that you can read out in the software (eg the exe must reside on a special memory stick)
Please note that a lot of users get quite annoyed by these things (we've used the first option)
Also please note that if commercially interesting, your app will be hacked. Make sure the effort someone has to take outweighs the profit the could make
One approach that also helps some is by custom branding. Each copy you sell would have compiled into it the name of the company it was sold too, which can be displayed as part of the splash screen as well as the about screen (along with a button to view the license terms). Most often this branding is done by using an external file which contains the information encrypted that when placed in the same directory as the executable is used to unlock the application as well as possibly provide additional functionality.
Unfortunately with todays software firewalls, most of the simple solutions to disallow running multiple copies on a network are not practical while still maintaining true portability, or requiring internet access to a server that you fully control.
Yes, piracy is a problem, but if you continue to offer great support and there is an additional "visible" benefit to purchasing, you can help offset this in your favor.
If you need trial protection, you can count uses/days if you have any sort of database where the user will have invested time and data, and won't want to lose it. Just encrypt the counter and place in the database somwhere. The user can then only reset the trial by wiping out the database. Depending on the type of app, this may be effective, or not.
Another approach is to not have a portable trial at all, but offer it as an incentive for purchase. i.e. conduct the trial on the desktop, and when they purchase a license, they get a license key that allows it to run on portable devices.
I recommend the PortableApps.Com framework for launching your app. It's free. You need to make your "launcher" open-source, but not your app itself. You can still run on a bare drive, if you follow their pattern.
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.
I find that most of microsoft's new programs are very hard to use.
Microsoft Office 2007 (word especially) I find to be hard to use.
Microsoft IIS 7.0 is a PAIN, I never remember which icon to click on, things are just to cluttered and hard to find.
As a programmer, we have to design according to what people are used too, what exactly is MS telling us to do?
we have to design according to what people are used too
Well that's a slight misconception. You're not wrong that people familiar with something will appreciate the interface remaining familiar, but not all change is bad. You have to weigh the power of the change up against the harm it does to veteran users.
Lets take Office 2007 as an example.
The ribbon interface is a huge departure from the interface Office has used for as long as I can remember but there is sound logic behind it.
User functions are grouped by activity and it's very easy to change which set of functions you're looking at.
They're also contextual so some thing only show up when you're on a table or an image (etc).
These both help keep the clutter down - something really quite useful as these apps grow in feature-sets. Rather than spending hours choosing and customising a set of toolbars, you have access to everything through the tabs.
And Microsoft did this all the right way. They tested the interface on lots and lots of real people. They listened to see what worked and what they should fix or drop. They also kept some legacy keyboard shortcuts for seasoned pros.
The redesign effort was targeted at making life easier on beginner and intermediate -level users. Mission accomplished. The problem you're having is overcoming your familiarity but I can't be more helpful than say: It'll happen in time, but you'll manage it in the end.
Look, I'm just a simple caveman, scared by your post-modern architectures and vroom vroom machines go honk. I'm used to the simple life of the paleolithic era; charcoal cave paintings and bone-based technology. I can't make heads or tails of your fancy ribbon UIs and pointy-clicky icons. That's why I'm never upgrading from DOS. The old ways were always the best, and learning new ones bad like fire.
Well, Microsoft has to balance this. On one side, users scream for new features and change-for-change's sake in a lot of MS software. On the other, lack of backwards compatibility (including subjective UI compatibility) is a deal breaker. Really no way to win there.
That said, I don't think we need to design according to what people are used to; neither does Microsoft. Change will never happen if we just do what has always been done before. IIS is not developed for programmers; it's developed for IT people. And the new interface serves them well. Likewise, Office is designed for office drones, not programmers, and the new Office is very discoverable for that particular group.
I think they take a while to get used to, but I do like them. (Althought I will fully admit I am a mac person and I like the mac UI a lot better).
The biggest thing I've seen about the UI that is difficult is the fact that it is so much different from previous versions (I'm talking about the current version of Office). That seems to be where most of the rub is.
The rule I was taught about UI design is that things need to be familiar to the user (that's really is what makes it "intuitive"). MS broke that rule ......but from a business perspective they are allowed a little leeway when doing this simply because they control so much of the market share. Ultimately, they know that a radical change won't cause a loss of much market share because for most people and businesses there isn't a real viable alternative. (I know there is open office, but migrating a mid to large office to it will cost as much money or more as it will to just continue using the same product).
Do we have to design according to what people are used to, yes we kinda do. Does this mean we have to make it look like what MS is doing now, not necessarily. What we have to do is create a design the users can relate to. They have to be able to make a jump of logic from what they know already to using the products we create. If not, they most likely won't use the application unless they are absolutely forced to.
User interface and user experience are totally separate concepts. (Simon Guest; User Interface Blog.)
Microsoft did quite a bit of research in the raw usability of Office 2007, and found that while there is a learning curve for people like yourself, or me, who are experts in the tool, newer users and non-experts experienced much greater discoverability of more advanced features, and wound up using more of the application's features and power. Yes, there is a learning curve if you knew Office 2003 inside-out (which, frankly, few of us really did).
Now I'm not making apologies -- Microsoft's UIs haven't always been easy to use, and sometimes they fail miserably. (Personally I think not standardizing all of their office products on the Ribbon is a classic example -- there's a large context switch in my brain when I open Project or Visio, compared to when I open Word.)
As for what developers are "supposed" to do: Bear in mind that the ribbon isn't ideal for every scenario. If you're using it as a glorified, prettified toolbar, it's being used incorrectly. It's designed to help you organize literally hundreds (if not thousands) of commands in a way that makes them discoverable to your end user. It's supposed to reinforce the traditional experience of discovering the abilities of your application in a safe way (see any edition of About Face), when the depth of your application is too great to function within menus.
Aside from that, bear in mind that we should generally be making the most appropriate UI for our own audience, as Microsoft is attempting to do for its own audience. Again, we may find these things more difficult to use, as we are used to doing things a set way -- but it's the right thing (typically) for Microsoft to do. Remember that we programmers are not the target users of most UI. (How many of us turn off visual themes, for example? Now how many normal end users? BTW, I don't fall in that camp; I'm one of the few who actually finds Vista moderately attractive.)
Again, at the end of the day, what Microsoft does matters only to the extent that it becomes what your users expect, and then only if you can't educate them that "your way" is better. In any event, if usability is truly critical for you and your users, it's time to invest in usability testing and ensure that your application really is as usable as you think it is. And start reading usability sites. (You don't have to agree with them all, but understand them.) Here are some samples:
AskTog (Bruce Tognazzini, inactive but the archives are a treasure trove)
UseIt (Jakob Nielsen)
jnd.org (Don Norman)
Office User Interface Blog (Jensen Harris)
Microsoft Windows User Experience Interaction Guidelines (The holy word on Windows)
It's interesting because there was a lot of talk about the usability testing that went into the design of the Ribbon controls, but along with almost everyone else I know I find them very difficult to use. I keep losing controls that I need and not being able to get them back until I've cycled through another three or four document views looking for them. I instinctively move my mouse to menus that no longer exist.
I wonder if they would be easier to someone not accustomed to the earlier office products- maybe this is who they did their usability testing with. I don't think the design of the new interfaces is bad as such, but it is different enough that for those of us who don't spend our whole time staring at Office but have been using the product for a long time it makes life difficult. I guess most real power-users would be doing most tasks from keystrokes anyway which presumably haven't changed too much.
The business problem is really that they need an incentive to upgrade and so they keep adding new features ( who do you know that uses all the features of Word ) and then they need to find ways to present those without making the application impossibly cluttered, which was certainly happening in the previous version of Office.
I'm not sure what we take from this as developers- maybe it's that we should design for usability from the start or find ways to make the transition between old and new functionality as easy as possible for our existing users.
Microsoft IIS 7.0 is a PAIN
I'm relieved to hear that others have found the new IIS UI a challenge. I stumbled into it without being forewarned, and was completely discombobulated. There is so much clicking around. You have to memorize where the feature is, or click and click. I don't know of a way to see all of the IIS settings at once (not that you could before, either, but at least you could stay in the single tabbed dialog).
I think it is really hard to adapt to an entirely new UI when you are so familiar with the old one. I am similarly disoriented by the ribbon menus. More clicking around to find the features. And not everything is in the ribbon. Some is in menus accessible from other entry points, such as file properties.
For new users who never saw the old UIs, it probably isn't so much of a problem.
I guess what I really dislike is having to spend the time learning the new UI, at the least convenient time. There is an immediate loss of productivity when you have to learn the new UI. You can't just drop into IIS, configure the website, and be on your way. The first few times, it's going to take a lot longer. Maybe with growing familiarity, we will come to like the new UIs better.
I wish they had given the option to show the menus for us old fuddy duddies.
I had a meeting with one of the Microsoft Office guys last year when I brought up the same points. His point was that the number of features had grown so much that a new method of displaying them was required. I was not entirely convinced and found it amusing that Microsoft are so touchy about the problem that he had a very nice, well-prepared PowerPoint presentation to give to try and explain it.
MS is trying to give users more power by being able to click this to do this or that and try to make what others may see as very advanced functions simpler to use and more powerful than the previous ones. I remember going from IIS 3.0 to 4.0 where suddenly, there are all these new buttons to click and things are different but it is kind of better. I also remember going from Windows 3.11 to 95 having its own shock of updating things.
Did you ever try watching a movie on VHS and on DVD or go from cassette to CD? Remember how the DVD suddenly had all these new features like chapters, no need to rewind, bonus features that you could just go to and not have to fast forward to find? Similarly how a CD organized things so much better than a cassette? Another point would be to look at TVs where it used to be very few options on a TV: There were 2 dials, the power and volume where combined into one place, and a few other knobs were all we had but now you have TVs where you can store favorites, closed captioning options, sound setting, and color style that could scare some people that remember the old days where you had to physically pull a knob to turn on the machine.
I find that most of microsoft's new
programs are very hard to use.
If you feel so, do yourself a favor and change to Mac. I did it and wont go back to windows. So much time wasted to achieve little things with Windows.
And Apple has Style Guides for GUIs. You dont have to stick to them, but as far as I can tell most developers do.
To prevent a Mac-Windows-Flamewar I would like to point out that this is totally my opinion. Please dear Windows user, do not feel attacked by my opinion.