Internet, and the article
@Doug Glass, this really is pretty well inarguable, not because of simple costs like you are implying. But, historically, early implementations of ARPANet software were ALL open source, as it was a research project that numerous people at different locations could and did improve. The OSes were sometimes commercial but the user got access to the source. This was important, as it allowed anybody with enough programming knowledge to make improvements to the TCP/IP stack, either in the form of actual code, or in the form of seeing how it operates and generating RFCs (Requests For Comment) suggesting improvements.
What did commercial companies come up with? X.25, which was complex and strictly connection-oriented. , Thee were also proprietary protocols (DECNet, SNA, and so on). Not saying they were bad but they were not interoperable except through specialized gateways (which were not automated -- one had to connect to the gateway, then to the next machine they wanted to go to -- or in the case of E-Mail specify the gateway manually.) Later on? OSI -- this was "protocol by committee", and frankly didn't work out at all. Many commercial TCP/IP implementations (including the one in Windows) use the BSD code (BSD licensing doesn't require any release of code, just a BSD license file somewhere or other.) Either X.25 or OSI would not provide anything similar to our current internet.
As for the actual article -- it's all true. But Matt Assay, a COO at Canonical -- really? You could have put a *somewhat* better spin on things. Here it is -- it's all true, open source is not going to make running a large-scale operation suddenly cost-free, because hardware is expensive. Good sys admins, programmers, etc. are also expensive. However, there are several advantages --- 1) Since the source *is* available, modifications can be made to both customize software in other ways, and to find optimizations, even if site-specific, to speed up the code. A large, popular site will still need large amounts of hardware, but this will reduce the amount of hardware needed compared to just having some closed code that *can't* be customized in any way. 2) Licensing costs. I really don't think I need to add to this, the larger the number of machines, the more licenses the operator would presumably need. Not having to pay for this is money in the bank.