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 9 years ago.
Improve this question
A while back I worked with a software company that sold a specialized software product. Ever so often they would release a patch for free and a new version that would require an upgrade fee. This is typically how the software industry works.
After some time the company decided on a new strategy, Subscription based software. This turns out to be a way for the software company to charge a small, incremental fee for each "transaction" that is performed on their software. Under this model the patches and upgrades were included in the per/transaction fee and there was a 'true up' in the number of transactions every so often in order to collect their fees.
To me this seems like a better way to develop and sell software. The software company gets continual income stream, the customer doesn't have to worry about upgrade costs and such, and if the customer gets really big then your income stream grows with their growth.
The problem (and reason for this question) is that I don't see anyone doing that anymore. Is it because this model doesn't work? Have I taken an overly simplistic view of developing and selling software without seeing some of the negative sides of this model?
[EDIT] I am interested in the developers opinion on whether writing Subscription based software is a good way to develop software.
So this question is directed towards the professional developers who have worked on commercial applications: Can anyone speak with experience on this model and why it does/doesn't work?
I used to work for a company which moved from product license to subscription based model. Here are some observations about that:
Offer both product license and subscription models
In product license: user buys 'n' number of seats for their use.
In subscription models, customer buys your software for 'x' months time and 'y' people.
It will help you a lot if your company also develops 'consultants' who will work with your customers to get the software implementation etc at client site (any required installation, training etc)
In fact if you see services like GMail enterprise, Fogbuz etc they give different pricing options:
where you want the app hosted: your servers or their servers
you will be charged $x per number of people using the software
I think a subscription model (time based) will definitely work in the current times and in fact the cloud model helps towards such freedom in revenue models: for example, you can choose to 'subscribe' to a cloud database rather than purchasing a database server.
Yes it does. See salesforce.com for an example.
Red Hat seems to think it works. Buy a year of support get all the upgrades/etc/etc. Except they let you keep the product when the year is up (so.. I guess customers like that too =).
It's not exactly the same but basecamp from 37Signals is very succesful with a monthly fee basis, and FogBugz also uses the same model. The approach you're talking about here seems similar to the MircoPayment idea that was seen as a revenue earner in the early days on the web. I'm not sure if anyone succesfully made money from that model, I'm sure a lot of VC was spent trying.
[Edit] I think this an exellent way for small ISVs to run their businesses. The combination of SAAS and subscription is a great way of getting revenue quickly. There are a number of advantages
1) Continuous revenue
2) Small or zero initial payment, brings customers in, beats that credit card price point issue (it's easier to charge $10/month than $100 one off)
3) Builds a solid relationship between ISV and vendor
4) Chance to upsell, assuming the offering is good
And the only way you're going to be a big software vendor is by being a small one first.
Due to the nature of software development a subscription based model is really the way to go, but how do make sure that you have continues updates that actually make software worth subscription fees.
If you're providing a service it's a lot easier to motivate subscription frees but if you're planning on having people pay monthly for monthly releases, well than that's a thin line between success and utter failure. I don't see how this would work with most software.
Update: #Dscoduc
I would call that a service then. Make a clear distinction between software release schedule and support. If you want to charge for a premium support deal well that service gonna have to be pristine. But I do see how it could work. People might end up buying subscription based software on the premises that they will be able to tailor it to fit their needs without programming experience and at a low cost.
Your challenge lies in being able to listen to your customers and really find a way of taking their feedback and making that the foundation for your software life-cycle and that's not going to be an easy thing to do.
Maybe we should petition stackoverflow for a way of marking content not related to programming but interesting to programmers.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a commercial plug-in on top of Visual Studio.
My product is licensed per individual developer, so the developer may make copies on more than one computer, as long as the use of the product is by the same developer.
After a period of time I discovered that many of my customers purchase one developer license and distribute the product over all the team members (and it is not rare case).
I spent many hours (here in StackOverFlow and outside) searching on how to prevent this issue, but I found most of people talk about protecting per-machine license.
My question is how can I prevent my legitimate customers from illegally distribute my product over more machines if I can not restrict them to any number of machines?
Throw my search I get one solution, but I want to ask you if it is acceptable or not?
I can restrict the license per Windows user name, while the customer activate the product for the first time I record the windows username with the product serial number, so he can not run (or even reactivate) the product on any machine with another Window username.
If you purchase any product that licensed per-developer, is this approach is acceptable for you?? (or in the other side this policy may be reduce my sales?).
Best Regards,
You can use many forms of DRM to protect your product. Consider though that you will be hurting and annoying legal owners on occasion. If someone changed computers or reinstalled windows then he will not be able to install your product again. DRMs can also be broken and are usually never worth the time invested in them.
My advice is that you don't try to prevent piracy of your software, since you can't stop it. If you are aware of a specific client that abuses your license, send them a friendly but firm Email requesting they acquire legal licenses for all their copies. Failing that, you might want to pursue legal actions.
All in all, trying to fight software piracy is a lost cause. You might consider other types of licenses that make it easier for a company with multiple developers to acquire your plugin. If you give group discounts they are more likely to pay.
I guess it depends on how the plugin is used. If it's primarily used in an office environment where having computers set up in a windows domain is the de facto standard, then yes, it could be acceptable.
It could become a problem if the developers are used to being able to use the plugin at home on their home computer as well, since the username will probably not match.
Edit: You could perhaps set a limit of 2 usernames per user. That could solve the use-at-home problem.
I'd say trying to bind the license to the windows user name would be sufficient, and somewhat acceptable. In your case you likely don't have any protection against several machines/users/etc. using many copies of your license - making it trivial for several people to use it. Most legitimate people will buy the additional licenses if it becomes non-trivial to do otherwise, binding it to the login name provides easy incentive to get additional licenses.
Just keep in mind:
You can't protect against every way to circumvent licensing.
You don't need fancy license protection, you just need it to be easier
to get an additional license than it is to circumvent the licensing.
Don't make it hard to use a licensed product.
One caveat I have as a sole developer on some projects though, is stuff bound to just 1 machine (or perhaps user account) - I always need 1 additional license for my build server and/or my machine-at-home.
it is very annoying to have to pay for a license for that machine even if it's just me using it - so think about that. For your product, it'd mean I'd have to have at least 2 licenses - one for my work computer, one for my home cumputer (different users/domains).
Invent some kind of setting which everyone will want to have set their own way, and keep that setting value on your server, for a license. If it's the same programmer using the app from three different PCs, he'll have no complaints on that the setting is the same everywhere. (In fact, he'll like it). But different people have different tastes, and people will soon be tired of re-setting the option the way they like it only to later find it reset back to someone else's preference again. They'll think that maybe buying a cheap personal copy instead of going through all this crap is not a bad idea after all.
The more of user preferences you automatically move around, the better it is for a single user and the worse it is for cheaters.
Goerge, what you describe is pretty common in your industry. The battle is lost already. Small companies will not purchase as much license as they should, but bigger ones will eventually respect your licensing terms.
You must adapt your pricing strategy and take in consideration this fact.
Adding more protection will do the inverse, preventing you from getting new customers or keeping the existing ones.
Don't make it hard to use. I have seen bad results, like Blu-ray which almost failed because of so much DRM on them. Some people had to resort to Slysoft Any HD-DVD to play blu-ray because software player that was supposed to play Blu-ray wouldn't play the disc they bought.
Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
I'm part of a software development company where we do custom developed applications for our clients.
Our software uses MS SQL Server and we have encountered some customers which do not have a DBA on staff to manage the databases or if they do, they lack the necessary knowledge to perform their job adequately.
We are in the process of drafting a contract with one of those customers to provide development services for new functionality on our software during the next year, where they have an amount of hours available for customization of our software.
Now they want us to include also a quote for database administration services and the problem is that they are including a clause that says that those services will be provided only when they request it.
My first reaction is that db administration is an ongoing process and not something that they can call us once a month to come for a day or two. I'm talking about a central 1TB+ MSSql Cluster and 100 branch offices with MSSql Workgroup edition.
My question is for any suggestions on how I could argue that there must be a fixed amount of hours every month for dba work and not only when their management thinks they need it (which I’m guessing would only be when they have a problem).
PS: Maybe this will be closed as not programming related. But I'm a programmer and I have this problem. My work is software development but i don't want to lose this client and the only solution I can think of is to find a way for the client to understand the scope so we can hire a qualified DBA to provide them with the service they require.
Edit: We are in a Latin American country with clients in the Spanish speaking region. My guess is that in more developed countries there is a culture that knows how delicate the situation is.
This is definitely one of those 'you can lead a horse to water, but you can't make them drink' situations.
My recommendation here would be to quote the DBA services as hourly, and make the rate high enough that you can outsource the work if you decide you want to. When (not if) the SQL servers start to have problems, the firm is on the hook.
I would also recommend that you include in your quote a non-optional 2 hour database technology review once per year. This is your opportunity to say 'You spent XXX on database maintenance this year, most of which was spent fighting fires that could have been easily avoided if you had just spent XXXX/4 and hired a DBA. We care about you as a customer, and we want you to save money, so we really recommend that you commit to using a DBA to perform periodic preventative maintenance'.
I would also recommend that you categorize any support requests as having root cause b/c of database maintenance vs other causes. This will let you put a nice pie chart in front of the customer during their annual review (which they are going to pay you to perform). It is critical to manage the perception so they don't think your code is causing the problems. You might even go so far as to share these metrics (db related issue vs non-db related issue) with them on a quarterly basis.
Sometimes people need to experience pain before they change. The key is to not be in between the hammer and their thumb as they learn the lesson, and hourly quoted work is one way of doing this.
As a side note, this sort of question is of great interest to a large number of developers. I'd say that this sort of thing could impact a programmer's quality of life more than any algorithm or library question ever could. Thanks for asking it!
No DBA on a system that size is a disaster waiting to happen. If they don't understand that, they are not qualified to run a database that size. I'd recommend that they talk to other companies with similar sized databases and have them ask them about their DBAs and what they do for them, and if they think they could survive without them.
Perhaps the link below from MS SQL Tips could give you some good talking points. But people who aren't technical wont respond to a technical explanation of the necessity of good DBA you are likley going to have to work toward proving the cost of bad DBA. Work out the worst case scenarios and see how they feel about them. If you can make it seem like a good financial move (and I think we all know it is) it will be an easy sell.
http://www.mssqltips.com/tip.asp?tip=1278
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
In my company we often value the software to be almost the same as concurrent software on the market. While this is one way I'm interested of other (maybe more academic) ways of value and put a price on software.
Any ideas or methods that have been succesful for you?
While I'm not always a fan of Joel, this crusty old article from 2004 answers your question very well. You charge based on how many units you think you will sell at that price, with the goal of maximizing profit.
I've done some contract work in the past, and I based my estimate on:
The cost of the man hours to produce the software, from start to finish
Potential money the client saves by using the software
Cost of any planned support for the software
Any other related costs such as installation fees, documentation, training, etc.
Then I compared that to the industry standard. In my case it was usually cheaper, and I still made money. Thus both the client and myself were happy.
Edit:
Mind you the above method is for a single client, with a custom software solution, and a simple unlimited-use license.
If you want to know academic methods for pricing a product, I have an MBA I would like to sell you.
Seriously, it depends on a lot of things. Are you selling a service, subscription, or a "box"? Where is your desired position in the market? What do your customers have to spend?
Listen to your customers and be prepared to change your pricing strategy. If you ever hear a customer say, "Wow, I was expecting to pay more!", it may be time to raise your prices significantly.
Magsto, my bet is that this question will be closed pretty quickly as being "not programming related."
However, I will tell you that your question is quite a bit more complex than can be answered here. There are lots of factors including time in market, market size, ROI you can offer, competitive advantages or disadvantages, the structure of payments (credit card, purchase order, cash), and even time of year. I only have experience here because I run my own company.
Do you really want to ask programmers this question? I think not...
I value my product as a fraction of it's value for the client. My venture sells web apps so it's slightly different, but if a web app would streamline 75K worth of overhead out of an office's budget, I charge 25K for it.
If it's a one time sale you have the option to examine the client and what value it will deliver to them. If it's a publicly sold product, the options are very different.
The basic formula is to sell it for around 30% of what it's worth to clients/end users. If you can deliver better quality than the next company, pricing in step with them is a big mistake because you can make more and take a better market share by promoting the features that justify the cost.
Customers often perceive cost as equal to quality. If you want to position your product as the highest quality option, you might consider pricing at 20% more than other competitors.
The price of a product is just as much about market strategy as maximizing profit.
You might want to read this:
Securing a .NET Application
It's a bit long, but I do get into some pricing at the end.
I am a IT enterprenuer and I my venture is into web and application development domain. When we deliver any product to our clients we ask them that
-how much time they are able to save with our application in place.
-Then we ask them to value their own time. Ex how much do they make in an Hour
-Then we do
time saved * value of time (as per the client)
these is the value that turns out for one day. We do the similar computations and demonstrate them how much they save in month and in a year
Thereafter depending on the client and the result for monthly and annual saving we give them the final price quote.
We think that these is the best way to give a software pricing as in these process we are pricing the software as per the money that software is helping our client to save
I have looked around on net and these book was suggested on almost all the forums though I have not personally been through these book but here is the download link
Dont just roll the dice
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
My employer was recently acquired by a much larger company. In the process of sorting out all the legal details around our licenses for our development software, we have learned that the vendor of our IDE charges a "nominal" fee of 25% of the cost of a new license to transfer our existing licenses to the new corporate name.
This struck me as absurd. I have not seen such a customer-unfriendly policy from any other vendor. Has anyone else seen this type of policy? Am I way off base in considering this unfriendly and abnormal?
Unfriendly? Yes. Abnormal? No. Its actually very common for tools with a hefty per-seat license fee to charge for a transfer after acquisition. I believe they do it because they can: the cost of transferring license is either overlooked during the M&A due diligence or is considered inconsequential compared to the rest.
The tool vendor justifies the fee because they now have one less potential customer, and the combined company will be paying a lower price per seat due to volume discounts.
I've heard of it before in regards to some high-end graphics software, but this was also back in the 1990's and only applied if you sold your license to someone else.
However, it does seem to be a bit odd to change 25% of a new license to just change the name on it. I'm not a lawyer, but isn't there some way that you could get around having to change the name on the software?
Things like this are quite common. It all depends on the agreement between the vendor and leasor. It's not limited to software either. Think about buying music, images etc. I have heard of some agreements where you can't transfer the license at all. You just have to buy a new copy. The thing that has to be remembered is that techinically when we buy a copy of a program, we don't "own" the copy, we just lease the use of it. It sucks at times, but that is the way it works.
I would say you are not, i have never seen a practice like that before.
edit : well i must be very lucky, seems that it is common. Very glad i have not run across this before :)
There have been cases where the tools (capital) a company has purchased is worth more than the company, and the company is purchased and gutted just to obtain those tools at a discount.
This is bad for the company, of course, but the tool vender especially doesn't want this to happen - they lose a potential full-price customer for software where there is no real competitor. Further, the company that originally purchased the tool doesn't mind the contract because it helps prevent acquisitions based only on getting the capital. (Corollary: If your company is negotiating out of such a contract, get ready to be purchased...)
For tools that are very, very expensive, this is not unheard of. Think 10's of thousands of dollars per seat, and you can see why this economy becomes reality. Further, sometimes tools are purchased for the company by a client (DoD) and they are actually a small company ( a few developers that won a nice contract) - if the client does not retain the license, then the company might go bust and the license sold for pennies on the dollar at an auction to pay creditors.
Etc, etc, etc. In short, very, very expensive licenses change the economic playground enough that very strange rules apply. Note that "expensive" may also mean scarce, as in the case of liquor licenses for restaurants, or otherwise difficult to get (Qualcomm might not want to sell a given company a license for their CDMA patents, but they may not be able to legally prevent that company from acquiring such a license through legal methods).
-Adam
I would have expected your new overlords to have been made aware of this as part of their takeover plans. Part of the process involves checking for exactly this kind of gotcha.
Sounds like they chose to ignore the information or did not check it out.
That sounds pretty harsh to me, but if you think about the amount of money that changes hands during acquisitions, it's probably one of those cases where your IDE vendor just gets paid without complaint most of the time, so they keep with the policy.
I can see why it shouldn't be completely free to transfer the license -- there is some (probably 'nominal') administrative work to do on the vendor's side, and they need to discourage people from transferring licenses all over the place when they really shouldn't be. But 25% seems awfully high for the amount of work and verification they need to do -- it seems like they could put some sort of cap on the license transfer fee, or have a fixed price.
It does seem like the kind of policy that would drive customers to a competitor, particularly one that does not have the same kind of draconian license transfer policy.
It seems that something like this could be negotiable. We have never though of "fees" as a hard nonnegotiable item. If they value your business I would bet they could discount the transfer fee. It certainly seems that some kind of fee is reasonable for administrative changes that are required. To me that should be a flat fee per license. The work required to change their database is the same no matter how much the license costs.
This is quite common. Unless you address this issue up front when you enter into a license you are at the mercy of the licensor when a transaction like you describe happens. The licensor may or may not have a policy to come along and charge a fee, but unless the matter is addressed in your license, they will have the legal ability to do so.
The reason is this: a license is a legal contract with a specific legal entity (your employer in this case) and grants no rights in the software to anyone else (they buyer company in your example). Now your employer could have insisted on a clause in the original agreement saying that the license could be freely transferred to a possible future buyer without fee, but without such a clause, the licensor can do what they wish. Including charging the 25% fee.
This is one reason that many companies have their licenses routinely reviewed by legal counsel who are knowledgeable about software licensing.