Fog Creek Software
Discussion Board




Should we maintain multiply product binaries?

Hi,

For our first product we plan on having two versions, standard and professional, which will differ in features offered.  We are currently trying to decide whether to build two separate binaries for each one or enable/disable features based on a license key.  I would like to hear from others what they are doing.  Also, what are potential advantages/disadvantages of either approach?

We are leaning towards the latter approach of enabling features based on a license key, because maintaining multiple code bases/binaries may be quite an arduous task.

--Garett

Garett Chang
Thursday, August 28, 2003

We maintain ours using the licence key method, this allows us to put a little reminder when they click a feature that is disabled and they can ring up and buy it and get it activated over the phone right away instead of waiting for a CD.

For us the Licence Key has worked well because our product is the kind of product that nobody really wants to take the time to figure out and decode a 50 digit licence key. But if your app is for the consumer market and it becomes popular then it will be cracked in fairly short time.

We also change our code each version (in the past 3 versions (12 months) it has gone from been 15 characters to 6 blocks of 7-10 characters) and our code is only valid once ever so it can't be given to anybody else by the customer.

Chris
Thursday, August 28, 2003

Our solution to the problem was an hardware dongle: different  version of the dongle enable different function in the software. We have choosen this way because we operate in a very vertical market, so we have to absolutely protect ourself from piracy as we don't sell millions of copies per year :).
Ciao.

Andrea
Friday, August 29, 2003

I think that if you use a single binary, you risk having someone figure out how to crack your selective enabler.

It's pretty hard for dishonest customers to enable a feature if the code for that feature is not physically present.

Steven Den Beste
Friday, August 29, 2003

If after using a product for a while they'd like to use other features then having a single deliverable means they just need a new key to unlock them.

On the whole I'm against having separate deliverables just because of the unknown quantity of screwing up, a single deliverable is simple, straightforward to QA and makes marketing sense.

Simon Lucy
Friday, August 29, 2003

Should you decide to use two seperate binaries, look into Preprocessor directives, you can work from the same code for both versions, but compile them out seperatly.

Don Vince
Friday, August 29, 2003

Preprocessor directives are fine for some small stuff.  But over time can easily destroy the simplicity and readability of the code.

With either method, seperate source code for each or two binary's from one source base, you will require strict maintenance and careful organization.

Currently we are using the dual source code method.  But our product is still small and young, and only time will tell how well this works.  We are very careful.

sedwo
Friday, August 29, 2003

Here are a few things to consider in making your decision:

Any licensing scheme you come up will be cracked, if there's sufficient interest in your program. On the other hand, it's also safe to assume that anybody that wants a copy of your program will be able to  get it.

So, neither producing two binaries, nor having a solid license verification scheme will prevent dishonest users from using features they haven't paid for. So that's not a consideration in your decision.

Having a single binary will make things easier for everybody in the organization, from development, to testing, to packaging. That's the solution I'd recommend.

You might want to consider having your license scheme set up to be able to enable or disable as many individual features as possible, rather than just having a single switch for "pro" or "home" versions.

That way, you can adjust the feature set to create a new product without having to overhaul the whole product.

-Mark

Mark Bessey
Friday, August 29, 2003

I don't know why people are so worried about being cracked. Someone who will use a cracked piece of software is not a customer. Customers are people who have a need for your product/service and the ability to pay for it. Just because someone has a need doesn't make them a customer.

You will be cracked - don't make the situation worse for you our your customers by jumping through a bunch of hoops.

Now, I don't mean to say that you shouldn't use any sort of copy protection, only the protection of the protection needs to be balanced by the cost and hassle on both you and your customer.

By the way, there is one way to not be cracked - don't produce something that's worth anything.

pdq
Friday, August 29, 2003

>I don't know why people are so worried about being
>cracked. Someone who will use a cracked piece of
>software is not a customer.

maybe in the U.S. In other counries people are perfectly happy with a cracked copy. If you want to export you stuff, and it is some sort of specialized software (like medical stuff), then a _good_ dongle is a reasonable choice.

Michael Moser
Saturday, August 30, 2003

"By the way, there is one way to not be cracked - don't produce something that's worth anything."

There's another way not to get cracked: don't give them the code.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, August 30, 2003

*  Recent Topics

*  Fog Creek Home