The downside of using PHP as a language for such a product, is that PHP isn't compiled, but interpreted instead. That means that the code will somehow has to remain readable for the PHP binary, which in turn means it's readable for end-users. There are systems known (such as [Zend Guard and [URL="http://www.ioncube.com/sa_encoder.php"]IonCube](http://www.zend.com/en/products/guard/)) that will actually encode the code against prying eyes, but I am not sure how helpful that is, and I'm also not sure which PHP versions it supports.
Apart from the cost and support of PHP versions, the customers' web-server must have the decoder installed, which just might cause a problem as well, as that is not under your control either. To be honest, I don't really believe in encoding or hiding source code, because no matter how hard you try: it can always be reversed engineered: PHP is interpreted.
As Vali suggested, the easiest solution is to host it yourself. Probably the cleanest way to accomplish this, would be to have a (very strong) separation between the different layers and only run the presentational layers on the client. To do the saving of the data, and the actual business-processes, make the front-end call an API on the back-end and validate a license key in the API. That way, you can deactivate the license at any time.
EDIT: I must admit that I agree with the statement of SituationSoap just as well: if your customers are happy and they actually get a decent system that is updated, they won't try to steal it anyway.
@Vali Unfortunately our application is about the data you already have. So we cannot do that, but if you are talking about storing the classes on our server and open them to client by using reflection and xml-rpc, (which we considered) we think that it will be slow for client.
@SituationSoap Can you please open it up a bit ? Because I think what lies under your sentence is important Do you mean that we should provide the application open or do you have and other strategy about distribution ?
@webaddictz I really do not believe in hiding, that is why I asked this to you but we think that API style of working would be slow.
As I read the answers you wrote, I rethink the situation. Although it is a very brave thing to do, we can leave the source open and let the client use it and if the client is happy that they would buy it. But as it is a brave thing to do I have to justify it to our business development manager!
I see these two options as the only realistic implementations of your product if I'm understanding it correctly. I believe you are correct about the down sides in each case. Neither application performance or business managers are easy to cope with!
You might try running some tests to see if storing the classes on your server would run as slowly as you think, maybe they wouldn't. But like you, I suspect it would be a nightmare. On the upside, most businesses that I have worked with would not use unlicensed software because the penalties are so draconian if you get caught, but that may not be true for your entire audience of users.
I use IonCube Encoder when I don't trust the client, or rather, when I think they have an admin who will try to mess with the code rather than pay me to update it and he'll most likely mess with it (I can think of one such admin who is such a PHP expert that he thinks PHP stands for Perl Hypertext Processor. Close, but no cigar :D)
Obfuscating isn't perfect though and it can be reverse engineered if you want to spend the time. I don't think PHP 5.3 is supported yet either, otherwise it's not a bad system and reasonably priced. It comes with the loaders that can either be included in your PHP.INI or can be selected at runtime.
Essentially, my point is that you're going to take your code from a known good state (no obfuscation) and move it to an unknown state (obfuscated) for no gain other than you assume that your users are malicious.
Any misstep in implementation of the obfuscation is a bug waiting to happen, which degrades the value of your product. Use a solid license agreement and focus on producing good code instead of focusing on "beating" your customers -- who are, by definition, people who want to use your product.
Not long ago I saw a movie named "Ratatouille" which brighten my vision in some way. One of the famous slogan from the dead chef was "Everyone can cook", and it's true, even a rat can cook a delicious food, too delicious even for the food critics.
My point is, everyone can code and producing things like what we do. But not everyone can cook a good food. So, if you make a brilliant idea and satisfying service, you don't need to worry for them to screw you, they'll come back to you because you are the best they'll ever get.
There seems to be a lot of positioning and idealism on this thread. Does anyone have any data on the number of sign-ups and repeated income with an encode and without it? I suspect that take up rates are highly industry/audience specific. Much as I believe in not treating clients as malicious, they do sometimes "forget to pay".
I have no data on encoding versus not. I'd be fascinated to get some.
By counter example, the continuous rebilling mechanism (you get repeat billed until you sign out) usually does 5-10 times better than the subscription reminder system (we send you an e-mail asking you to resubscribe) even if you make the opt out option exceptionally clear and friendly. Sad, but I've seen this on three separate occasions. What company does not want to increase their income by a factor of 5?
Yes, it is idealism. I don't have any numbers to back me up, I only have the experience I've gathered throughout the years. I just don't believe in hiding the code so that people can run away with it. "Forgetting to pay" is a different issue altogether and one that can not be solved with a technical solution from my point of view. Just blocking access to people who accidentally didn't pay doesn't solve your direct problem, and it doesn't make your customer feel any better.
If they "forget to pay", pick up the phone and ask them what is wrong. Perhaps there's something you can do to help them, maybe they're in a slow season. They'll love you for that, and that love will be spread. I'd rather have a 100 customers that stick around for 10 years, than 300 customers that stick around for one or two years. The "no payment equals no service" philosophy will get you into conflicts, not into solutions. Or at least, this is my take and my way of doing business.
I do realise that this is situation-bound. I'm fortunate enough to have personal contact with most, if not all, of my customers. Admittedly, this might also be affected by the country you're operating in, the kind of businesses you're involved with and the type of software you sell. I just seem to be in the right situation to be able to afford this way of thinking, I guess.
Counter question: I believe the above statement, but do you have any numbers about the results in the long run? Increasing your income by a factor of five is incredibly interesting, no-one will deny that, but for how long? I have had a telephone provider that tells me I have to cancel my subscription three months before the (automatic) renewal of the subscription and I think it's retarded and their decision to do business that way has negatively impacted my opinion of the company. First change I had (and remembered ), I left to the slightly more expensive competition that allows me to stop the subscription every month, over the internet.
This was 2004. In 2010, most of the telephone-providers in the Netherlands now have the option to stop your subscription each month, and adjust the subscription over the internet, free of charge. Unless of course, you get a phone with it, in which case they'll want you to stick around for at least $x years, and then provide the strategy above. The "silently-renewing-for-a-year" strategy just didn't work out to be what they hoped in the long run.
I might have it wrong though, and I too, would like to see concrete numbers on this, although completely off-topic, as we were talking about obfuscating code
Excellent point. To be honest, I didn't even consider the possibility of using HipHop as a way to make sure your code doesn't get stolen. Probably because it's not marketed that way.
In the project I was involved longest with, we were incredibly nervous about long term satisfaction. In fact there was a lot of resistance to the whole idea of passive rebilling in the first place. We didn't want to "sting" our customers.
We didn't do an ideal job the first time around and definitely annoyed a few people. Eventually we got it sufficiently right that people would compliment us on our honesty. For customer services and marketing that was good enough (I defer to them).
Warning: You have to have very clear cancellation links, both on the site and in the pre-billing warning e-mails.
Don't forget that every business has a churn rate. If people leave eventually anyway after an average of 5 years, then you are still winning even if they bail out on the very next cancellation period. Extreme, but that kind of calculation is up to the business owners, not us.
Come on. Somebody out there must have built some obfuscated software. Anyone?