As someone who has commissioned Web sites from agencies and usually sits on the client side, I'm going to make a few counterpoints:
> The worst part about it was that most of this software we were debating was free and open. There was no cost associated with the platform.
That last sentence. Arrgh. There may be no upfront cost, but there is certainly a cost involved in on-going maintenance, security, expandability and flexibility.
A lot of companies I've worked with on Web projects have come from proprietary or closed source CMSs and have suffered trauma when the only person who knows how it works disapears or the company that provides it has upped the license fees.
So they move to open source. Even so, the following question applies: "If this guy disappears, how maintainable will it be, what's the size of the community? how stable is it? how extensible? If is a complex nightmare of spaghetti for in-house staff to manage. How will I integrate it into existing systems
So yes. I love to hear your excellent plans for the business and your thoughts on how to improve customer engagement etc, but I also want to know that you are a technically competent firm which can articulate the reasons behind your choice of technology in terms better than "Oh, we know Drupal/Wordpress/Joomla and therefore that's what we use for everything.
Yes, my former work were very clear with our clients about this (usually Drupal as this was a couple of years ago): "we use open source because it means that if you decide you don't want to work with us any more, you're not locked in and can do whatever you want. It's also common enough that you can get your own in-house developer if you really want to add functionality to it."
Our strategy was that by informing the client, they a) knew we weren't backing them into a corner and b) were informed enough to have options in the future. (Most stayed with us anyway, but it was nice to say that they had a choice)
Absolutely true. However, I have a hard time disagreeing with the OA's general thesis. Maintainability is not something that fits in a client pitch unless the client already is aware of it as an issue. Especially getting into the nitty gritty of technology choice is a rabbit hole that is not going to help you win a project, because 99% of the time the client doesn't have the expertise to evaluate whatever claims you make about the relative maintainability of different solutions.
When it comes to winning bids, you need to speak the client's language and address the concerns they have. That's not to say you don't have an ethical obligation to consider long-term maintenance and other issues that are off the client's radar, but if you talk about it too much with a prospective client who isn't aware of it you will appear to be out of touch and not understanding their real needs.
Yeah yeah, we all know there's cost associated with running a site, open-source or not.
The good part (although not very relevant in the grand scheme of things) is that there's no licensing fees. Either way, you'll be depending on someone—in house, consultant, or automated something or other—to manage the system for you. You said it yourself—the "only guy who knows how it works" can disappear whether the project is proprietary/purchased or open-source. Personally, I think open-source apps with a large community have much less chance of disappearing overnight, and the ecosystem of available consultants is much larger.
Plus, sure, added benefit: no up-front license fees. Maintenance is likely to be similar to proprietary solutions, and everyone knows that already. No one is saying "open-source software is freeeeee" anymore, that common misconception was pretty much put to rest around 2001.
Plus, even discussing the cost of the solution up front reinforces the points the author was trying to make: that discussing the technology, its up-front cost, its maintenance cost, whether it's closed- or open-source—none of that matters. What matters is the solution. And one would hope that you'd use the right technology for the right solution, taking cost and technology into account.
The idea that you don't talk about trivial technology details until you've gathered all the requirements and found the true need is still extremely valid, and the fact that he was discussing trivial costs so soon—whether or not they were misconceptions—was a sign that he was doing it wrong.
The point is that cost of maintenance/etc.. could be different between different solutions: let's say the customer is a Microsoft shop, with some internal .Net/SQL Server skills (or just licenses or external maintenance contract): choosing i.e. DotNetNuke could be more cost-effective than opting for a Wordpress/Drupal/other LAMP solution.
The same is true comparing OSS solutions too: say you have to compare two proposed OSS web solutions, one is running on the typical LAMP, the other one is FreeBSD/Erlang/PostgreSQL. They're both free and open, right? But if the customer has already some linux and/or mysql and/or php skill inside, the choice could be driven (also) by technical aspects.
Comments
As someone who has commissioned Web sites from agencies and usually sits on the client side, I'm going to make a few counterpoints:
> The worst part about it was that most of this software we were debating was free and open. There was no cost associated with the platform.
That last sentence. Arrgh. There may be no upfront cost, but there is certainly a cost involved in on-going maintenance, security, expandability and flexibility.
A lot of companies I've worked with on Web projects have come from proprietary or closed source CMSs and have suffered trauma when the only person who knows how it works disapears or the company that provides it has upped the license fees.
So they move to open source. Even so, the following question applies: "If this guy disappears, how maintainable will it be, what's the size of the community? how stable is it? how extensible? If is a complex nightmare of spaghetti for in-house staff to manage. How will I integrate it into existing systems
So yes. I love to hear your excellent plans for the business and your thoughts on how to improve customer engagement etc, but I also want to know that you are a technically competent firm which can articulate the reasons behind your choice of technology in terms better than "Oh, we know Drupal/Wordpress/Joomla and therefore that's what we use for everything.
Yes, my former work were very clear with our clients about this (usually Drupal as this was a couple of years ago): "we use open source because it means that if you decide you don't want to work with us any more, you're not locked in and can do whatever you want. It's also common enough that you can get your own in-house developer if you really want to add functionality to it."
Our strategy was that by informing the client, they a) knew we weren't backing them into a corner and b) were informed enough to have options in the future. (Most stayed with us anyway, but it was nice to say that they had a choice)
Absolutely true. However, I have a hard time disagreeing with the OA's general thesis. Maintainability is not something that fits in a client pitch unless the client already is aware of it as an issue. Especially getting into the nitty gritty of technology choice is a rabbit hole that is not going to help you win a project, because 99% of the time the client doesn't have the expertise to evaluate whatever claims you make about the relative maintainability of different solutions.
When it comes to winning bids, you need to speak the client's language and address the concerns they have. That's not to say you don't have an ethical obligation to consider long-term maintenance and other issues that are off the client's radar, but if you talk about it too much with a prospective client who isn't aware of it you will appear to be out of touch and not understanding their real needs.
Yeah yeah, we all know there's cost associated with running a site, open-source or not.
The good part (although not very relevant in the grand scheme of things) is that there's no licensing fees. Either way, you'll be depending on someone—in house, consultant, or automated something or other—to manage the system for you. You said it yourself—the "only guy who knows how it works" can disappear whether the project is proprietary/purchased or open-source. Personally, I think open-source apps with a large community have much less chance of disappearing overnight, and the ecosystem of available consultants is much larger.
Plus, sure, added benefit: no up-front license fees. Maintenance is likely to be similar to proprietary solutions, and everyone knows that already. No one is saying "open-source software is freeeeee" anymore, that common misconception was pretty much put to rest around 2001.
Plus, even discussing the cost of the solution up front reinforces the points the author was trying to make: that discussing the technology, its up-front cost, its maintenance cost, whether it's closed- or open-source—none of that matters. What matters is the solution. And one would hope that you'd use the right technology for the right solution, taking cost and technology into account.
The idea that you don't talk about trivial technology details until you've gathered all the requirements and found the true need is still extremely valid, and the fact that he was discussing trivial costs so soon—whether or not they were misconceptions—was a sign that he was doing it wrong.
> there is certainly a cost involved in on-going maintenance, security, expandability and flexibility.
As there would be on a commercial platform (plus some extra), so what's your point?
The point is that cost of maintenance/etc.. could be different between different solutions: let's say the customer is a Microsoft shop, with some internal .Net/SQL Server skills (or just licenses or external maintenance contract): choosing i.e. DotNetNuke could be more cost-effective than opting for a Wordpress/Drupal/other LAMP solution. The same is true comparing OSS solutions too: say you have to compare two proposed OSS web solutions, one is running on the typical LAMP, the other one is FreeBSD/Erlang/PostgreSQL. They're both free and open, right? But if the customer has already some linux and/or mysql and/or php skill inside, the choice could be driven (also) by technical aspects.
I think that was the point.