IT Employment

Making money on free software

How can anyone make money from software development if nobody pays for software? Chip Camden thinks the answer is to stop treating software as a product.

I've spent almost all of my 20-year consulting career working with software vendors: companies that write software in order to be able to sell it to users. These clients find their markets somewhat threatened by the rise of free software.

Back in the 80s and early 90s, few people took free software seriously. Some shareware was okay, but if you really wanted a reliable product you bought something commercially packaged and supported. That perception began to change when web browsers became available for no charge. Of course, back in those days businesses didn't need web access -- it was considered mostly recreational.

Linux presented the first credible threat to the "software for sale" model, because it demonstrated that a voluntary collaborative effort could produce something capable of replacing an important and costly piece of business functionality: the operating system. From the late 1990s until the present, more and more free alternatives have become available in diverse areas of business functionality -- from office automation (Google Docs and Mail, OpenOffice, LibreOffice) to software development (numerous languages, frameworks, version control, etc.).

Even in some vertical markets where free alternatives haven't yet flourished, the general trend towards free software has lowered the price point. Back in the 80s a decent order entry system for a company of less than 100 employees might run $80,000 just for the software (I'm quoting from memory of a real transaction I witnessed), plus more for support. I'd be surprised to learn of any SMB spending more than a tenth of that on a single accounting application these days.

I don't see any signs that this trend will abate, and I don't think it's necessarily a bad thing. Software never has fit very well into the manufactured product for sale model. Sure, the cost of creating software can be huge, but the incremental cost of producing one more copy approaches zero. Thus, the model of paying a per copy price doesn't accurately reflect the value obtained, and leads to efforts to subvert the pricing model that would never occur to someone who needed, for example, another car.

The software industry needs to find alternatives. A number of vendors have expanded the capabilities of their free/Express/trial versions so that they only exclude features that are relatively uncommon, advanced, or supporting a high volume of transactions. Users would willingly pay good money to

obtain those features if they needed them. While this approach lets a large number of users go free of charge, it provides the best form of marketing money can buy: existing users. Not only will those users buy the upgrade if they need its capabilities, but the product's larger market share will drive sales to those who don't use it yet.

That's a good approach for now, but I think it's a band-aid on a wound that runs much deeper. Eventually, nobody outside the most specialized, esoteric markets will be willing to pay for software licenses. Software companies can fight this tooth and nail, but in the long run they will lose.

So how will anyone make money from software development, if nobody pays for software? Surely, voluntary efforts can't supply all the software that businesses need. Software developers gotta eat!

The answer, I think, is to stop treating software as a product, and use it instead as part of a service offering. Don't pay me for what I've made, pay me for what I can do for you. As a consultant, I've been operating on that model for the last 20 years. I routinely (and contractually) grant my clients full ownership of the code that I write for them; they can do what they want with it. Furthermore, I don't bill them for the code -- I bill them for my time. Even though "time" does not perfectly equate to "service," it's a lot closer to it than a software license is, because it naturally includes any time I spend setting it up for them, providing support, and making further modifications.

I don't mean to say that all software providers should charge by the hour. Rather, consider that what you're providing to the user is a service rather than a product. Perhaps instead of charging for the XYZ package, you should charge for supporting it, configuring it, customizing it, and educating the users.

That still leaves a lot of unanswered questions, like "How do major new enhancements that existing users don't urgently need ever get funded?" The answers to those kinds of problems vary with the availability of working capital and the community of users and developers involved.

This may not seem like a topic specific to IT consultants. I've always said, though, that as consultants we have a duty to our clients to keep an eye on their business success. Their success supports our own, after all. That's especially true in the case of software vendor clients, where our efforts go right to the heart of their business.

Thanks to Chad Perrin, who shares my enthusiasm for free software, for suggesting this topic.

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

87 comments
cetiang05
cetiang05

this is a great piece of work. have a question. where can i find source code for most erp system? kindly assist. i am new to software business

tbmay
tbmay

In any event though, even if it is, as it pertains to copyrights, that is not an entirely separate issue from what Chip was saying. I'm afraid the devaluation of knowledge workers in the digital age is very simply exactly what Chip said. Their work can be copied over and over and over. You might tie up a year on a project, and someone snags it from you and profits from it if you let him. This is an economic challenge for the knowledge worker, because he very often is not rewarded for his own ideas and work. I know I don't have to tell you and Chip you have to protect yourself from people who are trying to steal your work and ideas. I mean, you gotta have agreements that make you the profit you need before you hand them files that amount to hours, days, weeks, years of your time and effort. Am I wrong about that? And that's true for those of us who even do general small business consulting. You solve a problem, on paper, technical feasibility, and you just deploy and hope, you're very likely to be undervalued because, well, they have it now. Can a content provider honestly expect to come up with so many brilliant ideas that that model will support him/her? Regulations or not, people are people and they honestly don't care that you got screwed. Might better read my last sentence a second time. All in all, our overall observations pretty much match. Large organizations and governments are bureaucratic, which almost by definition, makes them the antithesis of effectiveness, efficiency, and excellence. And fighting that is about as useful as arguing with God about the laws of physics. The old model of content valuation won't work. We completely agree. Chip also somewhat rhetorically asked, "What will?" And I honestly don't know.

MikeGall
MikeGall

I think a problem with your model is that there are a lot of developers out there that don't want to deal with customer specific problems and "IT" stuff. They want to make beautiful code, build features, etc. The problem with your proposal is if I want to work 40+ hrs a week coding since that is what interests me but I only get paid for doing things like installing the software on a server and configuring it at the customers site there isn't a lot I can do but become an IT monkey. I've been an IT monkey. It can be fun, it can suck. In my experience, and it goes both ways, a large percentage of developers suck as administrators and vis versa. Developers I used to running things as admin, usually as a local user, usually test using the same creditials they used to compile the code etc. Heck even if they do full testing, have a test harness, user simulation etc. they still are dealing with their environment all day. So you program works great with OpenLDAP that you have in your office that's great, how does it work with AD? Who knows. Developers don't usually go out and by a HP-UX system to see how well it plays with that flavor. They let the installers try it and if they can't get it to work they look for the incompatiblities. Similarly with IT people they can figure out how to get things working in their environment but will their code be any good? Who knows. Good developer ! => good IT and good I => good developer. I'd like to think I'm good at both but I think I'm a minority and it shouldn't be necessary to be a sysadmin/configuration monkey to make a living if you are a brilliant developer. It is an inefficient use of your time.

realvarezm
realvarezm

Now in this time, we are looking at the new face of IT service, consulting, outsorcing and Saas are the tendencies and probably will be for the next 10 years. The knowledge and experience that you bring to a customers is priceless compared to the world of trouble that you avoid in his day to day businnes, at least in the IT area. im not a cheap guy in my country the fees that i charged are expensive compared to guys from india, china or rusia. I;ve seen renegotiations where a client came to me with a quote from lets say gismo.com and the service and price they offer is 60% less, but when my work is put on the table, he begs not to raise the cost we already agree. More and more we see corporations like IBM, Oracle and John smtih from the corner; with the knowledge and experience to run up a good system and deliver a satisifed customer, plus the fee for support is good plus. Java, oracle DB, ubuntu and PHP are a great example of free software that can be applied to small and mid size bussines with great succes and get some cash in the process. So the final frontier for consultants and freelance agent has been open for a while, you just have to be alert and catch the oportunity for bussines with the field of knowledge that you own, forget the sales skills and show an entrepenaur that with your help he will save money and time, plus continuos and steady support and you are ready to become an entrepenaur yourself with nothing more to invest that your time and some dayli resources depending on how big you are planning to grow. Good luck and Cheers!

cwarner7_11
cwarner7_11

One factor missing from this discussion, the one that finally drove me to the Open Source world, is that most software developers/vendors seem to operate with the assumption that "more is better". Result- one winds up paying a whole lot of money for features one does not need or want, often rendering the desired or required features nearly impossible to access (compare, for example, Microsoft Excel 2000 to Microsoft Excel 2010- the earlier version still meets all my needs, including some obscure functions such as FFT). One of the things that I find with a lot of Open Source software that I use is that it is pretty much designed to provide basic core capabilities, while offering the more esoteric features as external plug-ins. (I am beginning to see a sort of similar apprach in the CAD/CAE market these days- but I can no longer afford "professional" CAD packages, even if I needed some of their more esoteric features). When I use my computer, the less time I spend trying to navigate my way through eye candy, the more time I have to work.

MrEddie
MrEddie

So you are saying that because reproducing software is cheap, you shouldn't be able to charge for it? Can't the same be said for drugs, music or movies? In reality, the only reason most people steal software, music or movies is because it is easy. My sense is that the main reason so many companies are rushing to the cloud is that it can finally protect them from the plague of pirates. If the software sits on a distant server and people have to use it from there, it can't be pirated.

gechurch
gechurch

It's difficult to make money selling your services when the product itself is cheap or free. I used to work as a desktop computer techie and saw this a lot. If it took 3 or so hours to fix a problem that might cost $300. When entry level new computers are $500, people look at that and feel ripped off... "I could have had a brand new one for not much more!". (This, of course, doesn't take into account that it would take 2-3 hours labour to transfer all their documents and programs across to the new machine, because end users don't think of that). Software is no different. My old boss was convinced there was money to be made selling support for Linux (for the desktop). It never worked, and the reason is simple: who would be attracted to an operating system that costs nothing? People who don't want to spend money. Sure, there are plenty of people who hate Microsoft or whatever, but they're sitting in their parents cellar figuring it out themselves, not taking their PC to a computer shop asking for help. I agree with the author that the sale model for software doesn't align with the cost of developing it. I don't think it's a case of software developers wanting to charge this way though - I'm sure most software companies would love to be able to bill more directly for developer time. No, I think software is sold that way because that's what the buyers want. And as long as the buyers want to buy software like it's any other commodity, it will continue to be sold that way.

apotheon
apotheon

I'm not sure where anyone referred to "regulation alone" here, before your comment. > I'm afraid the devaluation of knowledge workers in the digital age is very simply exactly what Chip said. Their work can be copied over and over and over. That's not what he said. What he said was that productized output of such work can be copied freely. The work itself is extremely valuable, but that gets lost in the focus so many people have on the notion of "products" that they create. Given an alteration in the way one views the market for software, one can abandon the absurd notion that each individual copy of it is worth X dollars when, in fact, the copies are worth roughly zero by all the laws of economics. That does not mean that there is no value that goes along with software, though, and this realization becomes obvious with such a change in one's perspective, leading one to recognize that the actual market value is the innovative development effort of knowledge workers. . . . and that fits perfectly with what he said in his article, which was that people are being devalued because people regard people as cogs, and discrete units of digital storage as "products". > I know I don't have to tell you and Chip you have to protect yourself from people who are trying to steal your work and ideas. You can't steal my work or ideas. You can benefit from my work, potentially without giving me money or consideration, or you can copy my ideas. These things may be rude, or even fraudulent, at times -- but they are not theft. Theft is when I have a thing, and you take that thing away from me. If you copy my ideas, I still have them; that is not theft. Please do not abuse terms like that. The way terms are abused by people trying to prop up failing business models involving rent-seeking behavior, zealously imposed monopolies, and artificial scarcity actually creates a significant chunk of the problems we are seeing now -- because the moment we start using charged language like "steal" to mislabel things, people forget that the point they should be addressing is how to employ sustainable business models, and start wanting to get the police to arrest their best customers. > You solve a problem, on paper, technical feasibility, and you just deploy and hope, you're very likely to be undervalued because, well, they have it now. Can a content provider honestly expect to come up with so many brilliant ideas that that model will support him/her? Regulations or not, people are people and they honestly don't care that you got screwed. None of this disputes anything I said. As I pointed out, we should be working on sustainable business models. Trying to sell abstracted arrangements of ones and zeros via the expedience of magnetic fields as units of product, without even selling the storage media that holds those magnetic fields, is not a sustainable business model. Yes, people might love to screw me. This is, in fact, one of the big reasons why trying to sell a license to something that can be copied ad infinitum via button press is exactly the wrong way to go about making a living as a knowledge worker. It is not only the case that copyright infringement is more difficult to avoid than to commit; it is also the case that whether copyright infringement per se is wrong is, at best (for those who believe in the moral rectitude of copyright), up for debate. On the other hand, work for hire is not. You either get paid, or you don't deliver what the guy asked. It is simple, it is enforceable, and it is not subject to the whims of third parties who are (you hope) refraining from copying what they already possess.

apotheon
apotheon

If you want to be a developer (full stop), offer development as a service. You don't have to be an IT monkey if you only do the software development support. This often means working with someone else who does the IT monkey work, and possibly another person for the marketing and client relations work, but that's life; if you want to be able to shirk parts of the job, you need to have someone else to pick up the slack (or just live with the damage being bad at business-critical tasks will do to your bottom line). I'm not just saying "Tough for you, I don't have that problem!" either. I am actually pretty crappy at a number of business-critical tasks, mostly due to my incredible personal distaste for performing those tasks. I'm currently in the "live with the damage being bad at business-critical tasks will do to your bottom line" camp, in fact, because I am not great at finding business partners either. The point is that I do not blame "pirates" or try to rewrite the rules of economics to make up for those deficiencies. Rather, I deal with the real world as it exists, and either work around my failings or deal with the consequences responsibly and with integrity. Yes, it's true that per-unit sales as a business model going away will cause problems for some developers who have gotten comfortable not having to deal with the real world while this temporary market aberration has supported their business models, but no, that doesn't mean we can (or should) perpetuate the aberration. It's fading away as a way to reasonably expect to make a living, and we need to face up to that fact or get left behind. Period.

MikeGall
MikeGall

Also: software is a product. Just because the marginal cost of another item is close to zero doesn't mean you don't provide value. Software isn't just of value because someone configured it for you. It continues to provide value throughout its useful life. Thus to use an analogy it isn't like a plumber who comes and fixes a leak and once the leak is gone the service is done. It is more like the pipes/city water distribution system: it continues to add value as long as it is used so a fixed price for what is in the box + a service contract makes sense to me. Free software might make that model harder to sustain over time but it doesn't change that fact that software is a good + service not just service. Another point would be that a lot of the free software out there exists because of companies paying their developers to work on them, Java, Eclipse, Open Office, etc. So even the free software is funded because the existing paid for software business exists. It is also a big motivator for people to learn how to develop, sure it is fun, but I code a lot more when I'm being paid for it than I ever would in my free time because I enjoy it. Not to mention most people wouldn't have bothered learning how to program if it wasn't for the fact that they could get paid to do it. If I spent 40hrs a week installing software that would be 40hrs a week less time I'd spend making new software. Lastly: I'm pretty sure people are more willing to code on a boring project, or hard problem that they are getting paid for than on a free piece of code for fun. Again pay is a motivator. If you don't get paid and the project isn't fun to work on you'll stop volunteering your time. A lot of hard but boring programming would never happen or at least would happen at a snails pace if the developers weren't getting paid. For example, and no offence if anyone works on the project, Mono. It for years was a 2-3 years behind MS .Net implementations. Kind of the nature of the project since it is trying to copy .Net but still even with corporate support Mono lags .Net by a lot ( I think they were still doing .Net 2.0 when 3.5 was out). Relatively speaking they have an easy job because they are copying the ideas of someone else rather than having to come up with the idea and then figure out how to implement parallel LINQ say from scratch on their own.

apotheon
apotheon

The per-unit sales model lends itself to the kind of monolithic software design you describe. If you offer all the new features in plug-ins, you end up with a core software package for which you'll find it very difficult to sell upgrades. The plug-in approach (by far a superior approach for purposes of software architecture) only works really well for cases where you don't make any money off it at all or make money by some means other than selling upgrades. In short, the per-unit sales model essentially mandates the bloated, confusingly complex form of the software you find you don't like.

apotheon
apotheon

> So you are saying that because reproducing software is cheap, you shouldn't be able to charge for it? Not at all. He's saying that because reproducing it is cheap (where "easy" is another form of "cheap") it is going to be difficult to maintain a market presence by charging for it whether you think you "should" be able to do so or not. It's simple economic reality, and not a matter of shoulds and oughts, in this case. > In reality, the only reason most people steal software, music or movies is because it is easy. "Easy" is just a special case of "cheap". It costs you little in the way of time, special tools, and so on. It is "easy". Therefore, people will take that cheap/easy approach in preference to the expensive/difficult approach of spending bunches money for a DRM-infested digital file someone can remotely delete off your computer, especially if the purchasing and registering process is onerous while downloading it illegally is basically a one-click operation. Also . . . it's not "stealing". It's "infringing copyright". Economics, ethics, and the law all agree that copying and stealing are not equivalent acts. > My sense is that the main reason so many companies are rushing to the cloud is that it can finally protect them from the plague of pirates. If the software sits on a distant server and people have to use it from there, it can't be pirated. To some extent, you're right about that -- and this actually fits reasonably well with Sterling's point in the article. edit: typo (missing "for")

tbmay
tbmay

Now I don't think Chip is saying you shouldn't be able to. He's saying he sees that model obsoleting itself whether he, or I, or you, want it to or not.

apotheon
apotheon

If your only marketing for the "free" software is that it's free, you're doing it wrong. It's that simple. For probably about the same amount of money on resources, you can have one of two options: 1. You get one desktop computer running MS Windows with MS Office on it. For periodic additional costs, you can get support when it's needed, usually requiring a house call. 2. You get one desktop computer running an open source Unix-like OS with craptons of software on it, plus an automated backup system on a lightweight server. For very rare additional costs, you can get support when it's needed, and it can almost always be accomplished remotely so that there's no need to get charged for mileage and extra time required by a house call. That's the simple version. It gets cheaper as time goes on, too. After all, you don't have to maintain expensive anti-malware subscriptions (the rare bit of anti-malware needed is free and effective on open source Unix-like systems), you get version upgrades for free for not just the OS but pretty much every piece of software you're likely to run on it, and the current hardware will be sufficient to run your software for probably three more generational system upgrades than it would with MS Windows. That's the home user marketing spiel. Obviously, you should adjust it for small businesses, adjust more for medium businesses, and adjust it more for enterprises. At the enterprise level, it's worth noting that the direct costs of your software licenses is often a drop in the bucket beside the cost of managing software licenses, though. As your business gets bigger, the bureaucratic overhead of using proprietary commercial software starts growing at an accelerating rate.

Sterling chip Camden
Sterling chip Camden

... but they also aren't going to want to pay more to install that same software on another workstation. They already bought it! Yet, the company with ten workstations gets more value from the software than the company with only one. On the other hand, the cost of producing ten copies is no more than the cost of producing one. Supply and demand break down with that model.

tbmay
tbmay

....you are right.

gechurch
gechurch

I certainly agree that it's possible to be a developer only. Loads of successful business software products have developers develop and a differente team (frequently an entirely different company) do the consulting and implementation work. In fact, I'd say this is part of their strength. Software that actively seeks partnerships with other companies and successfully create a community around their product seem to me to be very successful. I don't agree that the job of full-time developer is going away any time soon though. I think we will continue to see a slide away from per-unit sales towards other methods as menioned in the article, but I believe per-unti sales will stil remain the most common way to sell software for a while yet, and I also think that even these new sales models will not affect the developers much. Many developers have poor or no communication skills and no desire to gain them. It's rare to find a developer who is both excellent at coding and also excellent at dealing with customers and explaining things in a way the customer can understand. That's why virtually all non-trivial software titles have sales and support people. Changing the sales model won't change this.

apotheon
apotheon

> Also: software is a product. Not in any way that matters. The fact of the matter is that you do not manufacture an instance of "software" and sell that instance. The only thing we're really selling in a per-unit sales model for business when dealing with software is a bundle of one product and one service. 1. Product: We offer a physical object that facilitates local manufacture by the customer's manufacturing facility (that is, the customer's computer) of another instance of the software, the same way a blueprint facilitates local manufacture by a construction crew of another instance of a given house design. Alternatively, we might offer download of the manufacturing plans (an "installer"), or in some other way provide facilitation for local manufacture of a software instance. 2. Service: We offer a legally binding promise that we will not sue our customers for using the software once it has been locally installed (manufactured), so long as the customer uses it according to certain restrictions. There is no actual transfer of an atomic product. The "product" you have in your possession is not what you transfer to the customer; you still have your copy. What you are in fact providing to the customer is the legal and technical capability to create a local copy for the customer's use. In cases where the technical capability can be had from other sources with greater ease and for lesser price, all you actually provide is the legal permission -- and this is where service-based models (by eliminating the need to enforce most legal restrictions) and open source software (by eliminating the matter of most legal restrictions entirely) are making the productized software business model obsolete and ultimately unworkable. > software is a good + service not just service. That's incorrect. The tools for facilitating installation of software is a transferred "good", or a service, depending on how those tools are provided. The manner in which a productized software business model offers a "service" is by offering a protection racket, wherein the "service" is an ongoing promise to not ruin the customer's life with lawsuits. > So even the free software is funded because the existing paid for software business exists. Nope. It is funded because the need to develop software exists. Your statement assumes that if the per-unit sales business model dried up there would no longer be any need to develop software. > Lastly: I'm pretty sure people are more willing to code on a boring project, or hard problem that they are getting paid for than on a free piece of code for fun. So what? Saying we shouldn't or can't reasonably sell software in units at some point in the near future is not the same as saying developers should not be paid. You are setting up straw men to knock down rather than addressing the actual arguments at hand. > Relatively speaking they have an easy job because they are copying the ideas of someone else rather than having to come up with the idea and then figure out how to implement parallel LINQ say from scratch on their own. Copying the functionality of .NET would not be relatively easy. Microsoft has been so invested in keeping the protocols and APIs of its software offerings a moving target for so long that I don't think it could stop any time soon if it tried. It is more difficult, for instance, to maintain an up-to-date Wine than it would probably be to rewrite Wine from scratch to a particular API standard that is known before work begins. Copying only sounds easier if you assume that what's being copied is a stationary target.

Sterling chip Camden
Sterling chip Camden

Software vendors pile on new features or rearrange the UI so that some users will want to upgrade, then they threaten to drop support of the old version so the rest will have to (if they want to stay supported). If the new features were extensions instead, then that cycle wouldn't work.

Sterling chip Camden
Sterling chip Camden

... are using the service model instead of the product model. In that case, you might be able to charge per connection, per minute, or per bandwidth, in order to realize value for scale. A number of cloud-based service providers are already doing this successfully and encountering little price resistance.

Sterling chip Camden
Sterling chip Camden

MrEddie seems to have used something I said as a launchpad for his favorite anti-piracy arguments. Obviously, software developers have to find a way to get paid for their efforts if it's ever to be more than a hobby. The 'price per copy' model, however, isn't working. It worked for a long time, but it's fading fast.

gechurch
gechurch

But in practice this doesn't happen often. As mentioned earlier, my old boss gave this a go, normally after a person returned for the third time in a year with a badly virus-infected PC. He did all the right things; he explained that the system is different from Windows, and that not all the same software would run but that there are equivalents for pretty much everything, and he explained the Linux is great for people that like tinkering with their PC but probably won't be enjoyed if you're the sort of person that wants it to Just Work like they're used to. The person usually left the store really happy that their virus woes are behind them. Sometimes they returned a few days later ready to throw the PC at my boss because everything was different and they didn't like it. More often, they returned a few days later with a simple request... "can you install this for me?". "This" was invariably a bit of software that only ran on Windows; normally Microsoft Office, a game, or an Adobe product. Rarely was the person happy when they realised they couldn't do something as simple as install their app. You and I both know that this isn't Linux's fault, but the client doesn't care. They just want their app to work, and if it doesn't then the new system is crap. Change is the other big problem. People don't like it, even if they say they do. Most non-geek people freak out enough when changing from one version of Windows to the next. Changing to a different OS entirely just wouldn't work for these people. Even though there are alternatives for just about any Windows software you want to mention, the reality is people want what they know. Even in the example scenarion you gave, you included Microsoft Office in the Windows case, but not in the Linux/Unix one. You could have easily included OpenOffice in the Windows scenario. I assume you went with Microsoft Office because that's what the average-Joe Windows user wants to run. And as well as the familiarity, there is also the quality of software (I'm talking from the users perspective, not from a quality of code POV). Microsoft Office is a far classier product than OpenOffice. I had to use OpenOffice daily for two years, and it was far from fun. It was functional enough, but was slow to load, the interface was ugly and old looking, and there were some surprising problems with it (like opening a file from a network share - it was literally faster for me to copy the file to the desktop and open it from there than to open it directly over the network). My experience with a lot of other open source software has been the same: Functional - usually. Well documented - sometimes. Polished - not often. All of these comments apply to the simple home user market. As you and Chip have mentioned, when you start talking business users moving to *nix is rarely even a choice. I consult for, I dunno, 20 local small businesses. Of those about half couldn't possibly move away from Windows because they have to run software that is Windows-only. The other half run pretty plain vanilla environments. It would be feasible to change but: * It would require replacing software users rely on every day and know how to use. That would require quite a bit of training in all cases, and in some cases very intensive training. It would also annoy the hell out of the end users. * It would affect the way they deal with customers and suppliers. * I'd have a lot of very angry (external) accountants. Here in Australia most account firms want and know MYOB (a Windows-only product). Changing accounting package means changing accountants. Is *nix better than Windows? I dunno, maybe. But it doesn't even matter at this point. It's easy to see why people stick with Windows. I'd go as far to say that in 90%+ of the time it would be irresponsible for us as computing professionals to even recommend our clients move away from Windows to another OS.

Sterling chip Camden
Sterling chip Camden

... is when the user has specific software they prefer that runs only on a Windows platform. Sometimes you can convince them that the alternatives are almost as good if not better, but in some cases (specific vertical market software, for instance) there may not be a choice.

AnsuGisalas
AnsuGisalas

Do 10 copies generate 10 times the number of support tickets? Not likely, is it? So, with the support model you're rewarded more if you push the same product to many clients, say 20clients*5copies, than to fewer clients, at higher saturation, say 2clients*50copies. There will also be a perverse incentive working against making the code as clean and dependable as possible. Things would be different if software was still tailor-made for the system, like 40 years ago. This is a tough nut to crack... As a funny semi-parallel, look at how people running free webcomics do it. They say (truthfully, in all probability) "Look, I'd like to do this comic 24/7, but I have to eat too... so I'm updating once a week. But if y'all make donations, say amounting to i dollars, I'll be able to renegotiate my day job schedules and update twice a week. In developer terms, it would mean making oneself into a developer superstar with a highly energized fan base... "I'm working on the 2.34 release, but other projects are taking priority, so it will take four more weeks. To raise the priority, please donate" Webcomickers also do commission work, but that's probably the kind of thing you do as a consultant, anyway. The fan-base model could make the consulting work more self-advertising, though.

apotheon
apotheon

I don't know if this came across, but I've generally appreciated your contributions to this discussion as well.

apotheon
apotheon

That's going in my list of the best compliments I've received.

tbmay
tbmay

This has been a good conversation too.

apotheon
apotheon

The overbearing weight of regulations on how business is conducted for knowledge workers and their industries creates market distortions that lead people to undervalue what those workers provide. The nature of copyright law devalues actual content creators, turning them into cogs in the machine, for instance. What Sterling's article describes is how things are changing due to the fact that open source software projects (and piracy, though he doesn't address that detail as directly) are becoming more prevalent and influential. Tension is developing between that and the reaction of corporate interests trying to keep a lid on the effective obsolescence of copyright based business models so these corporations can maintain control of their markets. If the trend in regulation -- trying to increase it at all costs for the sake of corporate interests maintaining control of their markets -- were to reverse, we would naturally see a re-valuation of the people who create what they're trying to sell, because the market would then shift toward paying for the work of the value creators, rather than toward paying for units of what they've created. When unit sales are the valued commodities, advertising and revenue channel control are the key factors in the business model; when creation is the valued "commodity", the people who create are the key factors in the business model. This happily coincides with the interests of the customer base, too, because they would then be induced to pay for new innovations rather than just for allowance to keep doing what they're already doing. That is, they'd be better off paying to get access to something new and usefully different than what they do now, which is mostly paying to get more of the same old crap with a new learning curve attached just so they don't get stuck with unsupported software that is no compatible with the stuff everyone else is using.

tbmay
tbmay

I see FAR fewer people who value technical skills at all than I once did. Heck, that's true for knowledge workers in general. No doubt we need to adjust. I just am not sure exactly what model will work in a few years.

apotheon
apotheon

> I don't agree that the job of full-time developer is going away any time soon though. Who said it was? All I said was going away was the per-unit sales model for business success. That doesn't mean a developer's job is going anywhere, unless (s)he's working for a company too hidebound to change with the times, and is unwilling or unable to find employment at a better managed company. > I think we will continue to see a slide away from per-unit sales towards other methods as menioned in the article, but I believe per-unti sales will stil remain the most common way to sell software for a while yet Yes, that's probably true, for the most visible software markets -- but that doesn't mean its prevalence isn't plummeting. If you're unlucky, you'll be one of the developers laid off before that model dips below others in commonality because you refused to find new employment somewhere that uses a more sustainable model before your employer went out of business, or you'll be one of the independent developers suddenly unable to make a living because you were unwilling to adjust your business model. See, that's now it works: it remains dominant for a while, but decreasingly so, until it's no longer dominant. It's not like anyone is saying a currently dominant business model will suddenly drop from 80% of the market to 5% in a three-hour period tomorrow.

apotheon
apotheon

> My point is simply that change costs. There is always a cost in time, usually a cost in money, and there is also cost in the risk involved. Is that a reason not to look at alternatives? No. But the level of cost should determine how hard you go looking. Really? That's not how it looked to me. It looks to me like this quote from an earlier comment of yours sums up your point pretty well: > It's easy to see why people stick with Windows. I'd go as far to say that in 90%+ of the time it would be irresponsible for us as computing professionals to even recommend our clients move away from Windows to another OS. Let's continue . . . > I'm not against looking at alternatives. Judging by that older quote, it seems to me that you're just against looking at alternatives seriously. By contrast, I believe that the percentage is reversed (90% or so of the time a plan for migration is a good recommendation) -- but that, regardless of the responsible thing to recommend, it is highly unlikely to mean anything to a client who shares the same biases you appear to hold dear. > I've already outlined the process I believe should be undertaken, and that process takes into account the benefits of the new system. The preponderance of your statements' tone leads me to believe that process mostly involves looking for "worst case scenario" excuses to stick with what you already have, regardless of the ongoing damage it might be doing relative to what an alternative could provide. > It's just that most of the time this will be a 2 second process A two-second process is a bias confirmation -- not an actual consideration of whether it would be of benefit to consider alternatives. It's nothing but self-justification. If you are already knowledgeable in general terms about the alternatives, the process should at least take half an hour to consider responsibly. If you are not already knowledgeable, it's irresponsible to make a final decision at all. Get knowledgeable, at least by proxy, or just admit to yourself that you don't care enough to consider the alternatives. > This process has already been gone through at some point in the past, and the existing system is the one that was chosen. A two-second "process" of bias confirmation (not to be confused with confirmation bias, though I suppose the two are related) proves nothing other than that you started out as willfully ignorant as you are now if you're still going through a two-second "process". > Sometimes mistakes were made I'd bet real money that mistakes were made. Even if it turns out that the current solution is the "best", if a two-second process (or one that just flat out ignored most alternatives or relied extensively on FUD) was all that was used to come to that conclusion, it was chosen for the wrong reasons -- which leads to an institutionalized incapacity for honestly evaluating whether needs have changed. > Most licenses are perpetual, or have a significantly decreased yearly cost (which normally covers updates and support). Nonsense. Take it from someone who was involved in periodic licensing maintenance as the IT administrator for a government contractor: that's complete BS. Unless you're a minimal-needs business entity with workers in the single digits, that's almost certainly complete poppycock -- and that doesn't even take into account the "must also have" licenses and subscriptions, such as malware defense. > When you take a realistic look at how the process goes it should be clear where my "90%+" number comes from. Yeah, it's pretty clear, alrighty. > Heck, most of the time it isn't even worth spending the time investigating the options. We need to understand that our time is costing the company money. When it comes time for major upgrades or renewals, an investigation that takes a bare minimum of about half an hour into the benefits and detriments of technology migrations should be undertaken by knowledgeable experts who actually know something about (most of) the alternative technologies. Otherwise, you're probably just costing the client more time and money down the road. > As convenient as it may be, you can't just sweep away the negatives by saying "stop being such a negative-Betty". That's funny, coming from the guy who sweeps away all considerations other than conservative easy-way-out decision making so he can do the "hard" stuff in two seconds.

gechurch
gechurch

My point is simply that change costs. There is always a cost in time, usually a cost in money, and there is also cost in the risk involved. Is that a reason not to look at alternatives? No. But the level of cost should determine how hard you go looking. I'm not against looking at alternatives. I've already outlined the process I believe should be undertaken, and that process takes into account the benefits of the new system. I think most people run through this process, or a similar one, whenever they look at upgrading. It's just that most of the time this will be a 2 second process "The current system works ok, it would take x amount of time to look come up with a short-list, y time to look at each more exhaustively, z time to write a proposal, then I'd need to meet with the directors to discuss the change, there'd be re-training of end users and support staff, there'd be a long planning process, costly implementation, and a teething period where support needs are high and productivity will be lower..." the list goes on. And don't forget: 1) This process has already been gone through at some point in the past, and the existing system is the one that was chosen. Sometimes mistakes were made or the landscape has changed significantly since that original decisions, but majority of the time the software that was best for you then will also be best (or at least one of the best) now. 2) Most licenses are perpetual, or have a significantly decreased yearly cost (which normally covers updates and support). The cost to stick with the current system is normally zero, or low. When you take a realistic look at how the process goes it should be clear where my "90%+" number comes from. Heck, most of the time it isn't even worth spending the time investigating the options. We need to understand that our time is costing the company money. As convenient as it may be, you can't just sweep away the negatives by saying "stop being such a negative-Betty". As IT professionals that doesn't cut it. We must focus on the negatives, understand them, and minimise them as much as possible. Fail to do that and you are likely to end up with a system that doesn't meet your needs the way you thought it would, and has problems you didn't expect. Congratulations - now you are in the other 10%, and it's time to start looking seriously at alternatives.

apotheon
apotheon

You seem pretty dead-set on using your "worst-case scenario" explanation to excuse not looking seriously at any alternatives. I've noted an almost dismissive reference to looking at the probabilities, and a whole lot of "I can't use any alternatives, 'cause the world might blow up in my face."

gechurch
gechurch

Correct. That's the "decide on how likely it is to occur" part of the process.

apotheon
apotheon

The chances of having that tire blowout are probably pretty slim, unless we assume other factors are involved (like bald tires that you should have replaced a long time ago). If we don't take probability into consideration, we never get in a car in the first place.

gechurch
gechurch

Fair enough. I can see where you are coming from on most things you are saying. I even agree with some of it. The stuff about the worst-case scenario (on a side note... that's weird how I mis-typed that word twice!) I think you have misunderstood. I was not suggesting you consider completely irrelevant factors. The question I proposed one should ask ones self was "What are the chances I'll die or kill someone if *I* speed down *this* street?". There was no suggestion of considering different streets with different circumstances. So to go back to the car example, we're on that long, lonely stretch of highway and considering our original premise - speeding. The best-case scenario would be you'd fly down the highway and get some thrills. With the nicely maintained highway you describe, that would probably be the average-case scenario too. What about the worst-case scenario? Well, that might be that a tyre blows out while you're going 200mph. Maybe you sustain severe injuries... broken bones or concussion. And since it's a lonely highway no-one is around to help. Even though the chances of this happening may be slim (given the ideal conditions you described), this is still the most important scenario to consider. You need to address the possibility, decide on how likely it is to occur, decide if you can live with the result if it does happen, consider ways of mitigating against the result if possible, then come to a decision about whether the benefits to taking this action outweigh the potential risk. To not take this approach is to be reckless.

apotheon
apotheon

> I sat there and saw people happily nod along, only to return the next day asking for us to install a game. People are funny like that... I can't say I understand it. Yeah, that can be a problem. The way you describe things, though, it appears to be a problem much more often than I would expect, which made me wonder whether the boss was failing to make the matter clear somehow. > I never thought you said everyone should ditch Windows. I didn't mean to accuse you of saying so. My statement that I wasn't saying that was meant more as a prophylactic than anything else. > Although Wine is a viable option I deliberately ignored it for the purposes of this discussion; it's got it's problems. That's true, but there are definite cases where Wine is the right option -- a better choice than either doing without software targeted specifically toward use on a Microsoft platform or sticking with the Microsoft platform itself. As such, I think it's worth at least a brief mention, even if only to say "For most cases, Wine doesn't solve the needs of our customers." > Dual booting may be a good way to introduce the new system for some people. I've tried it a few times though and each time I have quickly ended up booting exclusively into the one OS while the other languished. That's actually how I ended up using open source OSes most of the time -- or, rather, something similar to that is how I ended up doing so. I had two computers side by side, one of them pretty modern and the other close to five years out of date. I had them both hooked up to the same keyboard, monitor, mouse, and speakers via a KVM switch. The newer system was running MS Windows, and the older system was running Debian. Before that, I had used MS Windows almost exclusively, and my only non-Windows usage on any kind of regular basis was supporting Linux-based servers for clients of the consultancy where I worked. I did not much pay attention to how much I used one and how much I used the other at the time. I just used them -- and noticed that even on older, slower hardware, the Debian system performed much better, despite the fact I tuned that MS Windows system within an inch of its life (even turning off the desktop process that allows things like Active Desktop and desktop icons). A hurricane came through the area, though, and there were power blackouts. One of them lasted more than a day. When things got back to normal, the first thing I wanted to do involved the Debian system, so I started it up and did that. More than a month later, I hit the keyboard combination to trigger the KVM switch to give me access to the other system running MS Windows, and I was confronted by . . . nothing. I suddenly realized I had never had occasion to turn on the MS Windows machine in all that time -- and even at that moment the only reason I wanted to use it was to test a Website design in Internet Explorer. I pretty quickly installed Debian on the newer/faster computer, and set up a gimpy secondary system running MS Windows for testing purposes. So . . . similarly to the situation you describe with a dual-boot system, I ended up using one of them all the time, and ignoring the other. That setup is what ultimately resulted in me making the OS switch at that time, though, and as such it might be a good choice for others. The fact people tend to end up using only one of the two OSes, and ignoring the other, is not necessarily a bad thing. > Your average Joe sure won't care whether there's an MS logo on his Office package. But he will care that the interface looks different than what he's used to, and that documents he emails home are often formatted somewhat differently, and that the training manual he's reading doesn't match up at all to what he's seeing on screen. This is true, but part of my point was that changes like this apply to MS Office upgrades too. When the same problems apply to both cases, it's not a very good argument for one case or the other. > Having experienced both OpenOffice and MS Office, my opinion is that MS Office is a far classier, well-rounded product. If you buy the complete business package with all the trimmings -- maybe so. If you get the default, cut-rate version preinstalled on most computers for home users -- not so much. "Ugly" is relative in this case, "classy" applies to neither of them, and "well-rounded" seems to apply more to what OpenOffice.org provides than to what you get preinstalled on a Dell or Compaq for home use. > It has to show significant enough benefit to outweigh the inherent downsides of change. If you start out with the assumption that both systems equally well meet the point-and-click needs of a given user, the remainder of the factors involved almost always favor the open source alternatives except for the fact there's change involved. Even that is not as big a differentiating factor as people imagine, when MS Windows upgrade time rolls around. > For business it's a lot harder. This is true. On the other hand, that added difficulty is often overblown by people who avoid change just because it's change, regardless of the reasons for the change -- and I only recommend such change as a consultant when the benefits outweigh the detriments. While the migration is more fraught with peril in business, the benefits are also much greater; most home users gain very little from such a change, relative to the benefits realized by a business that takes a well-planned approach to at least partial network migration. Don't forget that gaining benefit from switching some systems from one OS to another doesn't generally require switching all computers on the network from one OS to another. In the real world (as opposed to the marketing world), "best of breed" is almost always a superior to "vertically integrated vendor stack", all else being equal. What you describe as a list of problems with migrations is actually a list of things that should be considered, and not just automatically considered problems that apply to a given situation no matter what circumstances apply. Many people use a list like that as a list of excuses for not even investigating one's options, and that's how your argument comes off to me. > Am I imagining the worst-case scenario? Absolutely! To only look at the best-case scenarion, or average-case scenarion would be reckless. The correct approach is none of the above. "Imagine" the actual scenario in front of you. Judge each case on its own merits, and make a decision based on that. Period. > But it is, of course, the worst-case scenarion that matters. Incorrect. It is the present scenario that matters. If you're on a lonely stretch of straight, well-maintained highway at noon with great visibility out to ten miles (the point at which atmospheric interference becomes a serious problem), and there are no obstacles or people or animals or anything else of concern in your way, it's stupid to spend your time worrying about what would happen in the worst-case scenario -- inner-city rush hour traffic with pedestrians and potholes while there's a riot going on and a dozen police officers in view (all of them watching you). Due diligence does not require rejecting possible choices based on completely irrelevant factors. > And unless you are using very poor software at the moment, the answer is very likely to be 'no'. That's where the 90%+ figure comes from. You have quite an overblown opinion of most software, then. 98% of software is garbage, and in many cases we use it because we are not aware of any alternatives -- or because the alternative is even worse -- and not because it's good. Consider browsers: they basically all suck for heavy-duty users of browsers.

Sterling chip Camden
Sterling chip Camden

... the free vs. proprietary software choice. Unfortunately, clients (especially in larger corporations) often have factors motivating their choices that go far outside the stated goals of the choice.

gechurch
gechurch

How frustrating! I replied to this comment yesterday and even saw it display after pressing the 'Submit Reply' button. Now I come back and it's nowhere to be seen! Posts are never the same the second time round, but let's try again... * My boss was the one recommending Linux, not me. But he did all the right things; only suggested it to people whom it makes sense for (generally people who come back every three months with another 1000 viruses), he explained that it's a good system if you like to tinker and not a good choice if you wants things to just work like they always have, and he explained that some software like most games won't work. I sat there and saw people happily nod along, only to return the next day asking for us to install a game. People are funny like that... I can't say I understand it. * I never thought you said everyone should ditch Windows. * Although Wine is a viable option I deliberately ignored it for the purposes of this discussion; it's got it's problems. * Dual booting may be a good way to introduce the new system for some people. I've tried it a few times though and each time I have quickly ended up booting exclusively into the one OS while the other languished. The reason is you set up the system the way you like it, and having to do that for two different systems is a burden. And if you're trying to convince people to make a change, burdening them with more work isn't likely to help your cause. * Your average Joe sure won't care whether there's an MS logo on his Office package. But he will care that the interface looks different than what he's used to, and that documents he emails home are often formatted somewhat differently, and that the training manual he's reading doesn't match up at all to what he's seeing on screen. He will probably also care that he's using a slower, uglier looking product. I've used OpenOffice extensively. We even pre-installed it on every machine we sold when I worked at a PC store. Having experienced both OpenOffice and MS Office, my opinion is that MS Office is a far classier, well-rounded product. I could never go back. * None of this is a matter of being closed-minded. It's just that if you are going to move away from an existing system you need to have justification for doing so. The existing system and the potential replacement do not start out even; to coin a phrase, the potential replacement "starts out at negative 100 points". It has to show significant enough benefit to outweigh the inherent downsides of change. If you can't show that justification, you're just engaging in change for the sake of it. For a home user the cost of change is fairly low; you're typically talking about only one PC, usually only one or two people will be using it, the time to switch will be low, the risk is low since it's easy to go back and therefore you won't need to spend too much time researching the potential new system. For business it's a lot harder. You are talking about more PCs, more users of varied skillsets, there will be more documents and/or systems that need to be tested for compatibility, there will be existing documentation that will need to be rewritten, there will often be a cost for user re-training, there is the cost of paying IT support people to implement the new system, there will be lost productivity and revenue for any downtime, for larger bits of software there may well be other software that links in to it; plugins, exports, macro's etc. And that's all assuming you're only talking about a bit of software. If you're talking about changing the OS itself things just got more complicated. Now you have to check all your hardware to make sure it is compatible, and potentially purchase replacement hardware. You have to check all your software will not only work, but that any support contracts you have will be honoured with the replacement OS. Are all of the above likely to apply to every user/business? No. But many of them individually can be deal-breakers, and if there are three or four of the above that all apply they add up to a lot of incentive not to change (even if none of them are deal-breakers). Am I imagining the worst-case scenario? Absolutely! To only look at the best-case scenarion, or average-case scenarion would be reckless. Imagine if everyone took that approach to driving - "What are the chances I'll die or kill someone if I speed down this street?". If you look only at the best-case or average-case scenario then choosing to floor it is a reasonable choice. But it is, of course, the worst-case scenarion that matters. It might be highly unlikely, but if it does happen the consequences would be dire, so you don't choose that option. I find it strange that you consider this to be closed-mindedness. I consider it to be due diligence. To my mind, if you're asking the question "Is there an alternate bit of software that can do the job?" then you're doing it wrong. You should instead be asking "Is there an alternate bit of software that provides enough added benefit to make the time, training, frustration and risk that comes with the change worth bearing?". And unless you are using very poor software at the moment, the answer is very likely to be 'no'. That's where the 90%+ figure comes from.

apotheon
apotheon

I still want to give a client what's best for the client, though, and find it frustrating when the client insists on a suboptimal choice.

tbmay
tbmay

It's about what we can convince the customer to spend their money on at the end of the day. We've talked about a lot of obstacles that have to be overcome. If those obstacles aren't there with individual customers, you don't have to contend with them. If they are, it honestly is a judgement call as to whether you're putting in, say a Linux server running OSS, or Server 2008. And I use that as a relative example of the broader topic. Either way, the money I personally earn for a project is the same. If we use proprietary software, that's an additional cost for them.

apotheon
apotheon

You have to know your customer's or client's needs to make effective recommendations. If someone has to play all the latest PC games, it's usually a bad idea to recommend something other than MS Windows as the household general purpose computer. My point was not "Everyone should ditch MS Windows immediately!" My point was exactly what I said: if "free as in beer" is the only thing you're using as an incentive to switch OSes, you're doing it wrong. By the way, MS Office also runs on open source Unix-like systems via Wine and Crossover Office. Wine also supports Photoshop, now. Using Wine is not exactly a point-and-click exercise to get software installed, but if the customer was willing to pay your boss to have it installed I don't see the problem -- unless your boss was overreaching by pushing solutions he couldn't support. As for fear of change, that's not a very easy thing to fix. I think the most effective way to deal with that is at upgrade time. When an upgrade is needed, and the only way to reasonably get a new system is to get a new version of MS Windows, it might be worth it to offer the new MS Windows version and the non-Microsoft option side by side. Unfamiliarity will be a problem for both, but if migrating to the unfamiliar applies to all options, it should not stand in the way of choosing the technically superior option. Your comment about non-geek people freaking out over MS Windows version "upgrades" is central to this point. > Even in the example scenarion you gave, you included Microsoft Office in the Windows case, but not in the Linux/Unix one. I included MS Office because of the fact it's not provided as a pre-installed option from most vendors -- not because it is somehow better accepted. If I was piecing something together for a client, where everything is as customizable as it reasonably could be, I would offer alternatives to MS Office as the preferred option for a number of reasons in most circumstances. The truth of the matter is that most "average-Joe" users don't give a crap whether there's a Microsoft logo on their office suites. Most such users, in fact, really don't care one whit about what you describe as the "classier" presentation of MS Office, especially when that is weighed against the disadvantages. Many users actually find the mothering behavior of MS Office stifling and frustrating, and it is (in my aging experience -- I have not used office suites much for the last few years) much easier to turn off that kind of second-guessing automation BS in OpenOffice.org than in MS Office. Yes, there are definitely cases where I would recommend MS Office instead of OpenOffice.org or LibreOffice. No, that is not the default recommendation, and that choice is actually for usability and technical operation reasons, among others. > As you and Chip have mentioned, when you start talking business users moving to *nix is rarely even a choice. I consult for, I dunno, 20 local small businesses. Of those about half couldn't possibly move away from Windows because they have to run software that is Windows-only. Actually, as I pointed out in a response to Sterling above, there are pretty much always options other than sticking with that narrow selection. They may be impractical in many cases, but to imagine that there are no options at all other than doing the same old thing you've always done is to lie to yourself. It is always worthwhile to consider what options exist before locking oneself into a choice that is less than ideal. In discussions like this, I often find myself feeling like I'm arguing with a wall. People who agree to reasonable points come back to the discussion with what amounts to a bunch of excuses for why they refuse to consider alternatives beyond the most cursory glance, ending the decision making process with a statement like "Well, it'll never work, so I won't bother actually thinking about it much." When one begins with an unsupported expectation, then proceeds with a decision-making process by looking for reasons to support that expectation rather than reasons to undermine it, there was never really a decision-making process at all. There are answers to all of your bullet points, for instance, that might apply in a majority of cases, but you are clearly interested in imagining the worst-case scenario for migration and applying it as a limiting factor to every scenario, regardless of whether refusing to consider alternatives is actually an even worse case overall. Note that I don't think you're being malicious. I just think you aren't actually approaching the subject with as open a mind as you probably think. If you were actually approaching this with an open mind, trying to view it in a truly objective manner, that "90%+" figure of yours would surely be substantially lower.

apotheon
apotheon

Those medical offices are no longer my clients -- it's difficult to make "house calls" in Florida when I live more than a thousand miles away. I have no idea what happened to that situation, but I hope they are no longer using Win98 for anything.

Sterling chip Camden
Sterling chip Camden

Yes, you're right. It's hard now to conceive of an Internet-facing Win98 as being the best option (toaster, meet bathtub), but back in the day it often was -- simply because other options would have been much more expensive at that time.

apotheon
apotheon

I had a few medical office clients in Florida about eight years ago whose billing process required the use of a particular medical billing network. The only client software available for that medical billing system was an MS-DOS client that would not run on WinXP. In fact, it wouldn't even run in Win2K. Due to the dismal state of WinNT

Sterling chip Camden
Sterling chip Camden

There's an art to that conversation. Strong assertions may lead the client to think that we protest too much. A rule of thumb: when the conversation doesn't feel right, it needs to become even more genuine. There's a paradox: the art of being genuine.

AnsuGisalas
AnsuGisalas

is that clients may suspect it playing a role, even where it does not. Of course, that's not an argument against that model, it's just something to be aware of, something it can be a good idea to talk about in the open, get out of the way.

Sterling chip Camden
Sterling chip Camden

A perverse incentive can exert pressure without causing someone to cave in to it. In larger organizations, those pressures can find ways to sneak past individual rectitude and into corporate practice.

AnsuGisalas
AnsuGisalas

it's the little voices in the back of our heads that get to us, they mean that a) idiots will gravitate towards it all the time b) normal people will occasionally fail to do the right thing c) upstanding people will have to tackle themselves once in a while to ensure they do the right thing

apotheon
apotheon

It does work for large, inefficient bureaucracies, though. Such organizations quickly grow ponderous enough that they are essentially incapable of maintaining "real service" in a systematic manner -- in large part because "systematic" is roughly antithetical to "real service", at least when applied broadly. Given that such "real service" is effectively impossible for those corporate bureaucracies, pursuing economies of scale that make "real service" effectively impossible is a no-brainer decision. Why not sacrifice what you're not equipped to support anyway?

Sterling chip Camden
Sterling chip Camden

I've seen that tip-jar model used for open source projects, too. "I'll get this done eventually, but if you'd like to contribute I might be able to devote more time to it."

Sterling chip Camden
Sterling chip Camden

It seems like a real temptation, but if you indulge you'll find yourself without clients pretty soon. Real service sells more service. Squeezing the customer doesn't.

apotheon
apotheon

> There will also be a perverse incentive working against making the code as clean and dependable as possible. That may be true for large corporate consultancies, but that's because they operate on economies of scale that are optimized for cookie-cutter deployments and services. Independent and small-business consultancies are more likely to thrive where they can give clients a personal touch in the management of their accounts. It's a simple case of what looks good on paper for large organizations being poison by any other metric.