Encoded add-ons at a discounted price?

Would you be more likely to purchase an add-on if there was a lower priced, but encoded, version?


  • Total voters
    36
The modification above is only to show that how easy it is to modify something when it's not encoded.

That may be true, but it's also something that wouldn't realistically be encoded. IMO it's easier for someone who has no idea what they're doing to replace some HTML in a template than it is to dig through a bunch of PHP files and change things. Besides, if you don't know what you're doing you shouldn't modify source code anyways, it'll break when you update. Templates are an exception of course because of how they're built.
 
OH..

And I've looked at this several times and I've decided against it for two reasons..

1) Despite what some people think, Ioncube or other loaders are not installed on all hosts. And they aren't always kept up to date when they are.
2) There is no standard for encoders that everyone can follow. So it's a crap shoot as to which to use.
 
That may be true, but it's also something that wouldn't realistically be encoded. IMO it's easier for someone who has no idea what they're doing to replace some HTML in a template than it is to dig through a bunch of PHP files and change things.
Have you ever seen bugs reported here in this very forum?
"Yes, it's a bug, in the next update we'll fix it.
Until then you may replace THIS with THAT"
Simple.
 
Have you ever seen bugs reported here in this very forum?
"Yes, it's a bug, in the next update we'll fix it.
Until then you may replace THIS with THAT"
Simple.
Granted, that's how it currently can be done. And I've used it from time to time.

But if code was encoded, it would force more rapid deployment of fixes by the developers.
 
Unless it didn't :rolleyes:
LOL! Devil's advocate! :D

Seriously though, if an add-on was encoded and fixes weren't released quickly, I don't think the add-on would survive the criticism.

Don't get me wrong either. I voted NO in the poll. But, that's my stance now when encoding isn't common practice. If it were to become the norm and everyone used the same encoder/loader, then I might change my mind.

But I can guarantee there would be an uprising if it started to become common and we'd have a witch hunt where some rule would be imposed where add-ons can't be encoded to be listed here. ;)
 
But I can guarantee there would be an uprising if it started to become common and we'd have a witch hunt where some rule would be imposed where add-ons can't be encoded to be listed here

Which is how it is on vB. ;)

TBH though, I don't care if the mod was free, if it was encoded I would not use it.
 
Describe how that would be the case. Does encryption somehow give a developer magic glasses to see teh bugs more quickly?
LOL, no it doesn't.

But if a bug is reported, they would have to issue a fix almost immediately to keep their clients happy. Otherwise, their clients would be sitting with bugged software for an extended period of time.
 
I don't see it that way. Open source projects (readable code, not necessarily "free" software) normally would get fixed more quickly, because ANYBODY (if it's free or they have a license) can analyze the problem, and ANYBODY can contribute a fix. If it's the case of encrypted code, only the developer can provide a fix, when he has the time to anlyze it.

Encryption gives a developer more excuses to ignore bug fixing, because if nobody can see the code, nobody can find problems with it.
 
But if code was encoded, it would force more rapid deployment of fixes by the developers.
Would it?
They're charging less for it so have less income. They'll need to spend more time with fixes and releases.
More time + less income does not = quality add-ons and frequent releases. IMHO, quite the opposite.
 
I don't see it that way. Open source projects (readable code, not necessarily "free" software) normally would get fixed more quickly, because ANYBODY (if it's free or they have a license) can analyze the problem, and ANYBODY can contribute a fix. If it's the case of encrypted code, only the developer can provide a fix, when he has the time to anlyze it.

Encryption gives a developer more excuses to ignore bug fixing, because if nobody can see the code, nobody can find problems with it.
In the case of a paid add-on, technically the developer SHOULD be the only one providing fixes.

If the developer ignores bug fixes, then the add-on would simply die from lack of support.
Would it?
They're charging less for it so have less income. They'll need to spend more time with fixes and releases.
More time + less income does not = quality add-ons and frequent releases. IMHO, quite the opposite.
That's a business model thing. And I'm not sure what Liam meant.

But IMHO, say an add-on is normally priced at $20.00. The encoded version should be the $20.00 and the un-encoded version should be some astronomical price, say $100.00.

Please don't attack me for that. ;)
 
If the intent of encryption is to curb piracy, then it won't matter to the pirates if the code is $20 or $100, they'll get it if they want it. Once they have it, the "advantage" of encrypting your code is lost.
 
But IMHO, say an add-on is normally priced at $20.00. The encoded version should be the $20.00 and the un-encoded version should be some astronomical price, say $100.00.

Please don't attack me for that. ;)

Not at all for sure, if the whole point is to protect your source code and the rights to use the software is a flat 20 dollars by ratio $100 is way cheap because for the cost of only 5 licenses one person can undermine your whole protection scheme.

If you are going through the trouble of encoding your applications it can be assumed that it is pretty much completely for business reasons and to make the price of pillage only 5 times the fair cost of entry...you really wouldn't be doing yourself any favors unless you are a workaholic.

To make that encoded/non-encoded model work you actually need the astronomical difference and it would be WAY more than 5 times cost because that is kind of the whole point of encoding it in the first place.
 
To make that encoded/non-encoded model work you actually need the astronomical difference and it would be WAY more than 5 times cost because that is kind of the whole point of encoding it in the first place.
I'll agree with this 100%.

But if we're going to talk about encoding to prevent piracy, it might work for a short period of time and that's it. There are very good decoders out there that do work better than some might think.

The only thing that might last longer is to code in C and compile the add-on. But then, you have to jump through hoops and stand on your head for a server to serve compiled executable code. :D
 
I'll agree with this 100%.

But if we're going to talk about encoding to prevent piracy, it might work for a short period of time and that's it. There are very good decoders out there that do work better than some might think.

The only thing that might last longer is to code in C and compile the add-on. But then, you have to jump through hoops and stand on your head for a server to serve compiled executable code. :D

exercise the daemon :whistle:
 
Honestly, the only reason the thought occurred to me is because I've been looking at WHMCS (making an integration to XF), and WHMCS is IonCube protected (as are many of it's add-ons I believe).

Liam
The biggest downside to encoded php scripts is the nightmare they are for support, and for use when php gets upgraded. Have the wrong version of the encoder (or wrong php version) and you get all sorts of weird and wacky errors.

XF.com's resource section also doesn't handle multiple versions of the same resource well, unless you like releasing multiple updates per 'release'.
 
Top Bottom