views:

549

answers:

7

Hello everyone,

There are a ton of PHP frameworks out there (i.e. Zend, Seagull, Symfony, CodeIgniter, CakePHP, Yii, Prado) that do a great job of implementing important pieces of a scalable/maintainable website, and I almost always pick one to start building client websites.

As of recently, I've started getting tired of providing constant development services to clients, and I'm looking at the possibility of writing more full-featured commercial scripts that can be resold over and over again in the hopes of finding that magical "recurring revenue stream" that you always hear about in fairy tales. Please note that I'm not talking about building extensions/plugins to CMS systems like Drupal or Joomla, but full blown website scripts.

So here's my multi-part question:

  1. Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?
  2. If not, why aren't others doing the same thing?
  3. Have you ever seen a commercial PHP script that is based on a well-known open source framework?

I've wondered this for years, and no one I ask has ever really come up with a good explanation. It just seems like it is taboo to do so, and no one really knows why? I've seen commercial scripts that use third party libraries (i.e. jQuery, PHPmailer, etc), but never have I seen one built entirely on an application framework.

A: 

i think, these are the key reasons, why it is not done:

  1. the point of PHP was never building commercial applications (the original acronym means "Personal HomePage") ... it is an insecure, inconsistent language ... there are quite some good PHP frameworks ... nevertheless, the language is ... poor ... other server languages are cleaner, stricter, more secure, more powerfull, give access to a larger codebase and to better developement tools (notably java and the whole .NET stuff) ... i'd never use PHP if i had to built something really reliable ... (my favourite is this "overflow vulnerability fix" of chunk_split (line 1966)) ...
  2. PHP is always open source ... ok, there are obfuscators, or even ways to distribute PHP in a binary form ... but the first is likely to break the code, if you do a lot of reflection/introspection, and the second usually requires some PHP extensions to be run, which is not really sexy ...
  3. there are too many open source PHP projects around for any commercial software to succeed ... this was different before, but nowadays, you can simply get ANYTHING in PHP ... Typo3, Joomla, Mambo, osCommerce, PHPBB etc. ... frameworks as Flow3, symfony, CakePHP ... etc. ...

there are commercial sites running on PHP, but there is no good PHP software/framework i heard about, that i would pay for ... there's always a free alternative, and usually it is better ...

you will be having a hard time creating something, that is really worth buying ... and if you succeed, you will be having a huge community that will copy it, if it is worth buying ... either for personal commercial profit, or simply to provide a free solution ...

well, that's what i think ... :)

edit: let me clarify my points

  1. seems, i upset some PHP folks here ... that was not my intention (however i am quite disappointed, how biased you seem to be, given the fact that everyone contradicting me is a PHP developer and i seriously ask myself, what other languages you ever used) ... i myself started out with PHP on server side too and after moving through other languages, i came to see PHP in a different light ... explanation is provided ... whoever just does not want to read it, move on to point 2 ...i am not saying, PHP prohibits you from implementing a specific solution ... but it is being used to implement solutions it was never designed for ... it started out as >this< ... and it was constantly extended by many people, which produced:

    • an inconsistent API ... or does anyone else know a language, having a naming convention, where array_search, count and implode are all array routines? look at ruby, ecmascript or haXe if you wanna see how beautiful core language APIs can be ... i'd say it's awfully designed ... but it's not designed at all ... it has simply been thrown together by numerous PHP contributors ... that's cool in the sense that you have a function for everything ... the point is, you probably won't find it ... ok, after a while, you will know it all ... probably ... but in other languages, for example, where arrays are objects, it does not take you long to know all core array routines ...
    • no real philosophy ... look at the languages mentioned above, look at Objective-C or functional languages, if you want, to see how consistent a languages semantics and philosophy can be, compared to PHP's "oh well, we'll just throw in another function, that'll solve the problem" ... also PHP arrays are the strangest data structure, i have ever seen ... something like a hyperpotent hash with internal order for keys and values ... and yet, it's not even an object ...
    • a lot of unsafe code (a lot of functions exposing overflow vulnerability or not being binary safe, or not escaping is documented, which could be used for XSS attacks) ... when i read an API reference, and it tells me what a function does, but the truth is, i have to take in account a lot of possibilities (long strings could crash my complete system or even inject ANY code, nullbytes could make escaping routines not work, but when printing out the string again, they disappear (this was a strip_tags vulnerability until not too long ago)), then that is what i call unreliable and dangerous ...
    • slow execution ... eaccelerator and similar extensions can reduce booting time signifficantly, but execution it self will still be slow ... the actual problem is, the language is far to permissive, which causes a lot of overhead ...

    PHP was designed as a scripting language tying together a bunch of C functions ... it is often extended with further C functions, due to the fact that it is not the fastest language around ... this gives a nice speed up ... but how the hell do i know, whether a function is safe? who can tell me? i don't want to read through lines and lines of C to know ... so my two main points:

    • the API is a mess
    • what is behind that API can be a serious vulnerability for your application!!

    in consequence, PHP is hard to trust ... i mean, i personally dislike both Java and ASP.NET, but i have to admit, they are trusted plattforms and trusted for a reason ... now problems arousing from the messy API are being solved by some frameworks ... but if a language requires a framework to wrap the core API in order to have something usable, that is a base for good, maintainable code, then something is wrong ...

  2. how exactly do i use zend guard or ioncube on an arbitrary shared webspace?

  3. really, best thing you can do, is write commmercial plugins for widely spread PHP software, but it seems this is exactly the opposite of what Lusid wants to do ... but hoping to find a niche, that is big enough that you don't need signifficant marketing efforts to reach you customers, that is small enough that you don't get crushed by copycats, simple enough to build as a standalone app and fits a number of other criteria that are prequisites for a commercial success, seems a little naive to me ...
back2dos
1. PHP isn't inherently flawed if you know what you're doing with it. 2. Look at ioncube. 3. Lots of people sell software written in PHP successfully. It won't sell to pirates, granted, but people that want or need to have legal, licensed software will pay. You're unlikely to sell a framework, but decent commercial applications often beat open software because the niche is too small for the OS projects to succeed without money.
David Caunt
Wow, that fix is, well, wonderful! I can't understand why I've never thought of such a straightforward way to check for overflow... it's brilliant (just joking, of course; thank you for making me laugh for 5 minutes now)
Utaal
PHP has come leaps and bounds since php3 in terms of enterprisey-ness. Latecomers including namespaces, true objects, unit testing, etc., have gotten a lot of traditional space folks (Fortune 500, Government, etc.) excited.
Travis Leleu
I can somewhat agree, but PHP is a necessary evil, just like Javascript. These two things together dominate the web, whether we like it or not. I am open minded and develop in a LOT of languages. For web apps, I use Ruby/Python when I can, PHP when I can't, and .NET (MVC, not WebForms crap) when I am fortunate to be building a Windows site. I'm still waiting for Ruby and Mono to become commonplace AND easy to use for the average web admin, but until then, I'm going to focus my attention on selling apps written in languages that are widely supported. C or Perl is out of the question. :)
Lusid
the point of writing an app in PHP is, that it can run on an awful lot of servers. i know, PHP now even supports closures (since this year, or so?). but how many PHP installations are of that version? i guess less, than there are still PHP4 installations.plus, i don't see how unit testing is a language feature. it's just that serious devs also use PHP and therefore employ best practices. i don't know, whether you ever had the pleasure to refactor some PHP apps. until today, ANY time i had to upgrade a customers app, the code they had been sold was awful. PHP is good for cowboy coders.
back2dos
personally, i see nothing bad about JavaScript. the DOM API and behaviour are inconsistent throughout browsers, but the language as such is elegant, flexible, sexy and powerful. javascript allows functional style programming AOP and many other things. i never said "don't ever use PHP". i said PHP is quite awful, which is why anyone who can afford, will not use it. anyone who can afford spending money on software licences, is willing to get the best for his money. if this means they need a vhost to install the right software, the will do. servers are cheap, but good software is worth money.
back2dos
A: 

I can think of one reason against it: piracy. If your script is something a bunch of framework guys want, it will be pirated. If it is only for a rich niche, you can avoid this, but then you aint going to get any fairy-tale income.

It's not in the open source spirit of PHP. The trend is to give it away and then bill for the service. You might be better at marketing your script as such, and just charge people after they consult you and you hand them a script download and a manual.

tkotitan
I think your reason is flawed. Generally, places that are going to purchase software are legitimate businesses, and they will be less likely to pirate your software. I think it doesn't exist because the better and more successful model is to sell services rather than giving away the source code.
Travis Leleu
+1  A: 

I think your most important question is point 2, why aren't others doing the same thing?

Well some people are. Vbulletin have been quite successful selling forum software, even though there's no end of free forum software available. I think their success can be attributed to a paid product, in part. As they're earning money, it's easy to fund further development. Open source, free projects usually require a dedicated team to keep development moving, as there's no money for motivation.

There's no shortage of turnkey solutions available on the web. eBay will have no end of $5 scripts available - they're usually rubbish and unsupported.

Where I work, we develop bespoke 'one-off' applications for our clients, but we're looking at selling the same applications to other clients as an opportunity to scale our business. In this case we're talking about large projects worth tens of thousands, but they're only sold to a handful of customers.

There's no reason why you can't sell a product for 50 or 100 dollars and make money - you'd just need to sell to 10, 100 or 1000 customers to start making a living from it.

And to succeed over the free open software? Produce something that isn't already available, or do something much better than what's available for free.

Finally, another model you may want to consider is software as a service. Take a look at Basecamp (37 signals) for example. Their product is not open source, you can't download it, but you register online and pay something like $10 for their lowest end offering per month.

They don't have to give out source code, and they have a solid recurring revenue stream. They have tens of thousands of accounts.

David Caunt
I agree with you 100%. You didn't exactly answer the question I was posing (maybe I wasn't as clear as I should've been), but I have to up vote you for being dead on. SAAS is great, but then you end up spending more time building and maintaining your network infrastructure than selling software (yes, this is actually what I'm doing now, and it is starting to get old... lol). I would much rather sell it and support it than worry about how many drives failed today or whether I need to have a mirrored database server to decrease load. :)
Lusid
We run our SaaS app on amazon EC2. Just one instance at the moment, but it'll be easier to expand when we need to. This also means I don't worry about hardware, I just worry about how machines work together. Hopefully as your customer base increases you can afford to invest in research and improving your infrastructure :) Regarding your question, I'd emphasise that usually turnkey software doesn't sell very successfully and that SaaS is easier and safer if you can cope with the infrastructure.
David Caunt
+3  A: 

I have to heartily disagree with back2dos..

  1. PHP's a solid, incredibly well used programming language for developing web apps. It can, of course, be used for commercial development and millions of people (me included) do just that. I'm not sure PHP bashing is really relevant here.

  2. True, PHP is not compiled but if you really care about this you can use Zend Guard which can encrypt code. Personally I've always found open source code a plus point. Clients like to know they can get at the code if they really need to, it offers some reassurance.

  3. There are lots of OS PHP apps, some great, some awful. Find a niche (like any business), something that has real demand, and develop for that.

So I think you're fine to develop commercial apps/scripts. Just make sure you give them decent support and documentation. You'll find people appreciate that and are willing to pay for it.

Finally on the point of your question, I agree they stand a much better chance of being used if they are based on an open source framework since you'll be opening yourself up to wider market. Zend Framework, as you may know, has a pretty open license which says you can sell anything you develop with it.

simonrjones
I am living most of the time from developing php, but 1. make me cry, you are kidding, are you? But I agree with the rest!
Hippo
As Mike quite rightly states this question isn't really about language debates. But if people like the BBC, Yahoo and IBM use PHP I think it's pretty safe to accept it as a good language for building web apps. As ever, it depends on how much the programmer understands about software design. Hopefully sites like stackoverflow will help them!
simonrjones
A: 

Yes of course you can sell it.

Most people don't just sell the scripts as normal people and businesses don't know what to do with them and so require a developer to install and configure the script. Developers won't then buy the script if there is an open source/free alternative. If the script performs a valuable task that is often done, then somebody is likely to copy it and create an open source version.

Your key to selling PHP code is to sell it as a service. This could either be the installation and configuration of it (like most web design/development agencies) or an on-demand version of it (think of any online business app).

My company writes and builds a lot of PHP software for businesses and as we get new clients and solve new problems we write our code in re-usable classes which we can then package up and sell to other clients without any further coding - which I assume is what you are trying to do. It's all possible, it just takes time and planning to write the software to make it re-usable for other projects.

Jacob Wyke
+1  A: 

It really seems that a lot of people have missed the true nature of the question and even taken it as far as language debates (those never end well).

Is there any reason why I couldn't resell a script built on one of these frameworks as a full-blown turn-key solution (especially if the framework's licensing is something very flexible, like the BSD license)?

Assuming the framework license permits it then there's no reason you couldn't do this. You had mentioned Zend Framework so you may be interested in looking at Magento. While they offer a free community edition they also have a paid edition that works with the Zend Framework as well.

I recently worked with a file upload script that was offered commercially and it happened to be built on codeigniter (name escapes me at the moment).

If not, why aren't others doing the same thing?

My personal opinion is that it's a mix of quite a few factors really. The web based market for on premise applications (as apposed to SaaS) is already flooded with options and is starting to shrink in size. This makes less demand for an application that you would actually see the framework behind (with SaaS you most likely will never know what framework if any is being used).

A lot of the existing large players in the PHP market have been around for a while and already have their own code base that they have created and are familiar with. When you've spent years building your own libraries it's hard to justify moving to another framework.

A lot of the smaller players rarely educate themselves in proper application design and usually stick to procedural code. The big OOP features that exist in PHP today didn't come along until the 5.0 release. Mind you that was around 5 years ago but a lot of your programmers had started on their PHP tutorials and learning adventures before PHP5 was widely available and accepted on standard hosting accounts. As such most of our modern frameworks were not available CakePHP as an example didn't start until 2005. Zend framework wasn't around until 2007. These are all relatively new dates and I wouldn't expect to see a lot of commercial applications moving to them until the current generation of programmers that can write quality commercial applications age a bit (again just my opinion).

Mike
Wow, I didn't realize Magento was built on Zend! I've used the community edition to build 3 different e-commerce sites for customers, and I never even realized it. That's exactly the kind of example I was looking for. Thank you for the very well thought out answer. I think I'm going to stick with SaaS, and where possible, maybe provide a self-hosting option. The one place where SaaS still fails is when customers want to modify the code to fit their own needs (unless you go the Salesforce route and make every option in the world configurable via the browser). :)
Lusid
A: 

Hi,

Well in this case I think that codeigniter will be the best option because:

  • Don't need console access to configure
  • You just have to configure Database Connections
  • Fast, MVC, Cache, Logs, Good Documentation
  • Runs in PHP4, must of the people that buy this scripts have server restrictions to Upgrade PHP

Best Regards, Pedro

Pedro