Pushing PW in Web Design Agencies

[owzim]

I recently had an interview at a Web Design agency and I presented ProcessWire as a viable alternative to their most used CMSes like Typo3, Drupal, WordPress and Modx. They said that some of their devs have used PW before and liked it very much.

I promoted PWs ease of use, flexibility, less dev hassle, solid security and so on, but they said that it all comes down to what clients already know, and how established the CMS is: "Community size matters. How do I know that PW will be there in three years? It may be the hot thing now but might be gone tomorrow."

I think that from a business perspective those are valid points. I might be working with them in the near future and I definitely want to push PW more. What might be striking arguments against the mentioned points?

Greetings

Christian

[Craig]

I think one of the responses, is that the "here today, gone tomorrow" train of thought can apply to anything. But to provide some reassurance, one of the things you can look at is the community - a good size and decent amount of recent activity are a good indicator that the project is "alive".

Another is to read into the reasons why it came into existence in the first place, and how/why it still exists today - which I believe Ryan has covered both on the website, and quoted in several places on the forum (paraphrasing - "the project is funded by the paid-for modules and by people paying to have websites built using it").

The fact that it is open source is surely another winning point. The code is out there now - there is no way to retract what's already been published, it can always be forked and maintained by any interested party. And it's PHP and MySQL - there are no shortage of developers with those skills.

Several of the things mentioned above are also true of WordPress (and others!). I do believe that some people and organisations hear about these "wonderful" open source CMSs (WordPress, Drupal) and use those as the baseline to judge anything else against. But as we know, those tools aren't always necessarily up to what they promise.

Perhaps a collection of proper case studies of sites built with ProcessWire, involving the developers/clients, would be a great help in this area. Particularly if some were "high profile" to grab people's attention.

[pwired]

I promoted PWs ease of use, flexibility, less dev hassle, solid security and so on, but they said that it all comes down to what clients already know, and how established the CMS is: "Community size matters. How do I know that PW will be there in three years? It may be the hot thing now but might be gone tomorrow." I think that from a business perspective those are valid points. I might be working with them in the near future and I definitely want to push PW more. What might be striking arguments against the mentioned points?

Yes you do have a very important point there. Look what happened with modx, cotonti, wolf, etc. Trying to migrate a bunch of websites from one cms to another is a real nightmare. Is processwire immune for not falling apart or disappearing ? I asked Ryan the same question because he is the only lead developer of processwire what worries me. His answer was that there are more co-developers who can continue processwire in case he can't anymore. We'll who are his co-developers who can take over when necessary ? Others posted that software simply never stays for ever. Not very promising. It would at least be something to have some kind of php diagnose module so each one of us can debug and adapt the core and api of processwire to future php upgrades. This at least worked for modx evo which fell apart first, but later on was php 5.3 debugged and came back alive again.

[ryan]

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system.

We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. 

Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any)

Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients.

Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

[diogo]

But lets say that one of you showed up at my door and shot me

This would for sure be a Lennon/Chapman thing

[kongondo]

Well-said Ryan. Please, let no one show up at your door with anything other than pizza ....

The bit about prejudices (big 3) reminds me of a post I read today when voting for PW over at CMS Critic....someone was asking Mike why bother with such awards; that everyone should just adopt the big 3.....Battling attitudes is one of the most difficult things, I bet, known to man . Big doesn't mean they'll always be around..look at what happened to Nokia...

[apeisa]

owzim: one thing you might want to mention. We (www.avoine.fi) are company with around 2.5 - 3 million euros revenue for this year. Good part of that (all client websites and -services) comes from ProcessWire. We have also build lots of new software using ProcessWire. Fully dedicated to this platform in many ways: 5 developers working with ProcessWire, sponsoring the core development and also contributing to the core and releasing open source modules.

And I see "strong leader" model as a strength for ProcessWire development. Software development is not road building: you don't do it faster nor better by throwing more people to the mix. It of course requires that we have great leader, and that we certainly do have!

[diogo]

And I see "strong leader" model as a strength for ProcessWire development.

I completely agree with Antii that this is one of the strongest points of PW. Democracy in Open source projects can some times take to delayings and strange decisions. I think it's great that all final decisions are made by one person that knows very well in which direction the project should go.

[pwired]

Ryan just saved your post. Very usable as a good intro when teaching processwire cms to clients or to a class.

[kongondo]

I completely agree with Antii that this is one of the strongest points of PW. Democracy in Open source projects can some times take to delayings and strange decisions. I think it's great that all final decisions are made by one person that knows very well in which direction the project should go.

I totally understand what you mean but just to clarify for those who may not ....Diogo is not saying things are not democratic here at PW..just that final decisions are made by the lead dev... . I don't need to remind us all that Ryan is very quick to listen and thoughtfully respond to requests, criticisms, etc. Sometimes I feel he bends over backwards to accommodate our many requests.... That has been my experience. Anyway, I digress, again, sorry

[Pete]

Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

A million times this! Of course, you can't tell someone they're perhaps being lazy in real life if you want to work with them, but as I read the first post and before seeing ryan's my first thought was "I bet the design agency would prefer to play it safe" which is understandable to a degree and probably true of many.

I've only worked for a web development company once, and I had the good fortune that they listened to me when I said I could save them time with a CMS (this is back when I was using MODx). If I could take ProcessWire back in time with me I'd have saved them even more time and money!

Seriously though, it might not hurt to say to them some of the things that have been mentioned above in terms of security and stability. What I'd add to that is that ProcessWire is built for today's web technology - there are many other CMS' out there still supporting legacy versions of PHP and crippling themselves (by comparison) by not being able to leverage the advancements in PHP's core in recent versions. I would submit that ProcessWire is the forward-thinking person's CMS of choice^TM in this regard. It's not hampered by legacy code and the thing that I still love is that it's been so wonderfully abstracted that even if PHP6 was a total rewrite that turned every function on its head and renamed most of them it wouldn't change your API calls, because we access the data through the PW API then the API would still be the same (ryan would have quite the headache in that fantasy scenario, but the API is actually a safety net to a degree - nothing in the core would be deprecated in the future from what I can see as there's simply no need - it's that abstracted and has been built extremely sensibly in the way that it reads).

What I would suggest owzim, time-permitting, is that you put together all these points for this or other agencies and maybe even offer to build something for them to show how fast sites can be developed. Speed and ease of use are two of the biggest selling points for the people who are going to part with the cash, and for agencies ease of use also means other workers can easily learn the system. Then you're giving the agency the tantalisingly juicy apple of saving time and therefore making more profit.

Onto democracy, totally agree. Without leadership things can stagnate in a pool of good-natured suggestions and resultant inaction or, worse, people working in silos and doing their own things. I think on a project like this the thing is that as long as you don't get too despondent when an idea isn't included in the core then you'll get on juuust fine, but feel free to keep suggestions coming

[Pete]

Also, the developer showcase idea has come up a few times before, but I think it's one of those things that will happen when someone has enough time. Something like this maybe: http://director-ee.com/ - but with quality control checks (the skills matrix there is based of what people claim their skillsets are, rather than what they have proven). Maybe this is something that could tie into case studies, so that in proving their skills they're also contributing their experiences. It's not a foolproof idea by any means, ashow do you prove you made something on the internet when you might not be who you say you are? But I would wager it would be more accurate.

Anyway, I digress. But it feels good to have typed a lot on the forums for the first time in a while

[pwired]

it's been so wonderfully abstracted that even if PHP6 was a total rewrite that turned every function on its head and renamed most of them it wouldn't change your API calls, because we access the data through the PW API then the API would still be the same (ryan would have quite the headache in that fantasy scenario, but the API is actually a safety net to a degree - nothing in the core would be deprecated in the future from what I can see as there's simply no need - it's that abstracted and has been built extremely sensibly in the way that it reads).

Then why is this not mentioned on the homepage introduction of processwire or in the readme.txt of a pw download zip ? It would give a lot of people more ease of mind from the beginning when they start with processwire. This info is significantly just too important to know from the beginning when making a cms choice / investment for designers, coders and clients. Call it something like future ready.

[Pete]

Well I've maybe made a bit of a bold statement there saying "nothing would be deprecated", as ryan could rip out half of the functionality tomorrow if he was in a mind to cripple the product, but you're right.

It's more obvious to developers that because the code is abstracted and human-readable there's less chance of something becoming deprecated, and if there's a way for ryan to overhaul a complex 200-line API function to 40 lines and make it 10x faster as a result at a later date then it can be done without breaking people's websites which is the beauty of it.

But as you say, that doesn't help newcomers or a lot of decision-making managers who are checking a product out based on their developer's suggestion. Something could be done to address that - it's just a case of working out how to get it across easily. In fact it might sound silly, but something as simple as a couple of pages like ProcessWire for Agencies" and "ProcessWire for Developers" with the main points for each that are linked from prominent places on the homepage (perhaps even before the first paragraph) could really help - people want to know how it will benefit them specifically.

@ryan: feel free to correct me if I've made any bold claims in my previous posts, but I think I'm on the right track about the abstraction and I certainly can't think why you'd ever want to change any of the function names since they make sense.

[OrganizedFellow]

Also, the developer showcase idea has come up a few times before, but I think it's one of those things that will happen when someone has enough time. Something like this maybe: http://director-ee.com/  

EE has many sites that use *ee*.com/net/org in the domain name, mostly due to the long "e" pronunciation.

With that in mind, all I can think of for PW is pwetty, a play on the word pretty, but as spoken by Elmer Fudd maybe even pwettysites.com?!

[ryan]

Then why is this not mentioned on the homepage introduction of processwire or in the readme.txt of a pw download zip ?

I don't want to say anything that implies we aren't moving forward. The worst thing for software is to be stuck in time. But I do believe our API is a constant that will transcend versions. In fact, the term API implies a level of consistency and predictability that I take seriously. If for some reason we need to change parts of the API in order to move forward in the future, then we would version it. Meaning, you'd still get the old behavior if your $config->apiVersion was not up-to-date. Though I've not yet seen any reason for API changes, just additions. Believe me I don't want to create upgrade hassles for myself or anyone else, though I don't typically upgrade existing PW installs unless the client needs something from the newer version.

Libraries like jQuery can't afford to version their API because they have to be as tiny as possible. But we can afford to do that, because source code size is far less of an issue for a server side application than a client side one. But this is all theoretical, as I mentioned we have not yet come across any reason to change the API.

@ryan: feel free to correct me if I've made any bold claims in my previous posts, but I think I'm on the right track about the abstraction and I certainly can't think why you'd ever want to change any of the function names since they make sense.

I agree with Pete. 

[owzim]

First off, I love PW and I said that many times before. It's by far the best CMS option out there, that I know of anyway. That's why I want to push it in that agency =) The issues raised here are very interesting nonetheless and I hope I don't come off as a naysayer when provoking further thoughts on some of the posts in this thread.

... it can always be forked and maintained by any interested party.

While this being totally true, this is no guarantee that it's actually forked and maintained like before, if for some reason Ryan decides to quit.

There is far more security in that than any proprietary or commercial system.

Since all the other systems listed are Open Source too this is not actually an issue.

With ProcessWire, you do not need to upgrade your site every time a new version comes out.

Good point, but people barely know security issues before they pop up right? So there might be security issues in PW we don't know of yet. When the community gets bigger there are more people who are more likely to find bugs, which might be another point for that community size matters.

Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients.

Great points. Interestingly, that those CMSes (WP at least) are hacked quite often did not came off as a convincing point. It was only an interview after all and not primarily a discussion about CMSes =)

Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

Someone has to pay for that. It might be less expensive to use PW in the long run, but you need to convince clients that they need to use another system and the training costs money, OR even worse the clients think they invested so much time and money in training their employees that they feel the need to make it worth while.
And I don't think that clients are necessarily unhappy with let's say the WordPress admin interface, so they don't know that it's not so great under the hood.

owzim: one thing you might want to mention. We (www.avoine.fi) are company with around 2.5 - 3 million euros revenue for this year. Good part of that (all client websites and -services) comes from ProcessWire. We have also build lots of new software using ProcessWire. Fully dedicated to this platform in many ways: 5 developers working with ProcessWire, sponsoring the core development and also contributing to the core and releasing open source modules.

Great points, thanks.

It's not hampered by legacy code and the thing that I still love is that it's been so wonderfully abstracted that even if PHP6 was a total rewrite ...

So true, good point.

What I would suggest owzim, time-permitting, is that you put together all these points for this or other agencies and maybe even offer to build something for them to show how fast sites can be developed. Speed and ease of use are two of the biggest selling points for the people who are going to part with the cash, and for agencies ease of use also means other workers can easily learn the system. Then you're giving the agency the tantalisingly juicy apple of saving time and therefore making more profit.

That's a good idea, I might actually try and convert their company site in half a day =D ... okay, one day.

[Pete]

I think in terms of security Ryan is generally more careful, but also not relying on old code lowers the risks as well.

If you look at how often other systems release security updates it is actually quite worrying, and for me as a developer it has been a headache in the past. On the plus side I have used this very point to convert several sites.

Keep your points coming - the more we discuss the more answers there are to potentially help you.

There is still always the chance though that an agency you go to will simply be too invested in another system, so it's down to whether you take the job anyway and try to convince them later (might be in a better position to build it in their preferred system in a week then spend a weekend doing the same thing in PW to show them) or if you get the feeling that they don't want to try something new (which can raise some alarm bells in a fast-moving industry actually) then you might want to look elsewhere anyway.

With regards to the agency you mentioned at the beginning it might be worth asking them a few questions like what JS library they use, or a dozen other questions I can't think of right now to see if they're actually dragging their heels in other areas of web technology - if they're playing it safe stuck in the past in several areas then that would be worrying, but its worth asking all sorts of things that make you look like you're well-versed in current technology (something they should like) and also so you can see if they give any worrying answers

[pogidude]

What I'd add to that is that ProcessWire is built for today's web technology

+100 likes. I've been developing on WordPress for 3 years both doing plugins and custom theme development. I found ProcesssWire while looking for another CMS to learn. What converted me was this page http://processwire.com/api/selectors/, the fact that almost EVERYTHING was derived from WireArray and the EVERYTHING as a *page* concept. This was something that I never found in other CMSs I've looked at.