Interesting question with, I think, answers that branch in two
directions.
In one direction, we might concede that math research is not the bread and butter of computer science that it once was. For now, at least, the development and application of computer systems can get by without a lot of inquiry into mathematical fundamentals, much in the way that the routine development of optical systems no longer requires inquiry into the fundamental nature of light. That inquiry has already produced a rich theory which appears sufficient for most applications. So maybe we should call the job done and move on.
However, it often happens that we wish to do things for which existing theory is not sufficient, and then it helps tremendously to have a rigorous discipline by which to judge whether such a wish is utterly doomed (mathematically or physically nonsensical) or just not yet fully explored. I can't help but think that the people who are least able to tell the difference between the two are also the most likely to disparage the mathematical roots of computer science.
Then in another, even more prosaic, direction there is the daily routine of software development which, let's face it, contains very little sexy math. But still I'm constantly astonished at the number of times I have to intervene in a conversation among software developers or computer systems people whose capacity for formal reasoning is not up to the task. And here's exactly where it helps to be a computer scientist with some exposure to mathematical formalism, because I can help to lay the discussion bare and find out what the fuck it is that we're actually talking about.
I remember many years ago drinking beer with one of my number theory profs and naïvely asking him where in our careers he thought we would be applying this knowledge. His answer was, oh no, I though you understood, that's not the idea at all. You'll never use this material. I'm just teaching you how to think.
I came to the conclusion that the best way to judge their "production quality" code is by their error handling
I was going to offer a dissent, until I noticed how carefully you have phrased your observation.
What I was going to say was something along the lines of how it can be a benefit to modularity to leave out the error handing. But that's in the prototype stage of code development, where (I feel) that all available cognitive bandwidth should be applied to understanding the structure of the system without distraction.
But you're referring to production code, at which point all choices concerning modularity have been weighed and decided and baked it. And if part of that baking didn't involve a careful walkthrough to test for impossible or out-of-bounds conditions, error returns, and so on, and if the error handling framework itself lacks coherence, then yeah, that's not quite what I'd call a finished product.
Someone who thinks it is is still operating at the apprentice stage. These people are easy to hire and they can still be useful to have on staff. But they should be working under supervision, and for that you definitely need to have a master on staff.
Yes, certainly, if measured as number of person-hours spent engaged in philosophical inquiry. This was, and is, the monastic tradition, and worldwide it did and does greatly outnumber the activities of the privileged, and published, few.
You counter with some interesting examples of overt philosophical inquiry which produced events of historical significance. These were certainly influential and important for society at large, but that being so does not address the previous -- and eminently valid -- comment that philosophy is not a pastime of the wealthy.
I don't get the fuss. Over the past thirty years I've had on and off professional access to some of the most exotic computing environments on the planet. Sure, it seems like a big deal at first, but over a lengthy span of time, it becomes actively irritating merely to keep up with it all. Eventually you find that it works best to just ignore most of it. My household furnace is important too, but it runs just fine with routine maintenance. There's no need to get obsessive about it.
I no longer have a TV. I had one for awhile, but found that there are more interesting ways to spend time, like dating women for example. I have ADSL, which is not quite as fast as that 10 gig network I got used to at one point, but it still lets me work effectively from home, and keep up with party invitations. But when I'm up at the island I do completely without, for weeks at a time, until the boat comes to take me back to the mainland.
I have a cell phone, which is handy when I want it, for example when I'm alone on the island running a chainsaw or something, but it usually stays in its charging cradle where it won't intrude on my life. Before cell phones came along I did without that as well. We have a community radiophone down by the dock and in the old days it was either that, when it worked, or wait a day or two for a boat to come along.
I found that degree of isolation scary for the first few years, but also inexpressibly delicious, far more deeply rewarding than playing with some new techno toy. I already get plenty of technology at work, and I approach its use, I suppose, with a certain amount of professional reserve, knowing that nine out of every ten hot new technologies are going to be forgotten within five years anyway.
Want to invest attention in something worthwhile? How about spending time with your friends? Yes, there's more to friendship than showing off your toys.
If Linux is so secure users should be allowed to install applications!
Absolutely. Users already can install applications. There's no great mystery to it. They're also free to develop applications, if they care to. All the tools they might need are there, or can be downloaded off the net.
Of course, with Linux being a secure environment, your system administrators probably won't let you have root, and they may restrict what you can do in other ways, even to the extent of disallowing programs to execute from your home directory if it's felt, for example, that choice of software is not your responsibility. But it should be clear that's a matter of policy, not capability. Apart from security, one good reason the policy might be in place is to prevent people from diluting the economies of scale that your organization is trying to achieve through centrally managing software installation and upgrades.
It sounds like you're complaining that the policy is not to your liking. That's something you can discuss within your organization.
Ferrie also figures that the increased reliability represents a substantial savings, although he admits that it is hard to quantify. ... However, perhaps the greatest benefit of switching to free software is that the reliability of the new system frees up technical staff to do more than routine support.
I agree that it takes a fair amount of tracking to quantify total cost of ownership beyond the large but incidental fixed cost of implementation.
Still, staff salaries are usually a significant cost to any operation, so if staff resources are able to shift into new activities as a result of the change, it would seem common sense to begin by tracking that. The article has two sentences side by side. It shouldn't be hard to connect the dots between them.
Moreover, if we're measuring true TCO, we should look at overall effect on staff time, not just tech support staff. In a Linux terminal server environment, the entire staff population will now be spending zero time on fiddling with their workstations. It would be nice to compare this with the number of hours on average that individual staff members previously spent in dealing with issues on Windows workstations. That's a big part of TCO as well, but if you never measure it, how can you know when you've improved it?
I don't know the answer in this case, but I'll make one general observation. When Microsoft promotes its lower TCO calculations, look to see whether they fairly compare the total staff time spent in system configuration, software installation, failures due to bugs, compatibility and security issues, problem analysis and resolution.
I don't entirely get this either. Maybe someone who knows the legal process in the United States can enlighten us.
My understanding applies to Canada only, where I believe that generally someone has to register a complaint with police in order to initiate a criminal investigation, unless of course the police themselves witness or have evidence giving cause to investigate. If charges are laid as a result, they must be approved by the Crown before going to court. This also holds for diversion.
So who laid the complaint in this case? Not the store, evidently. The police acted on suspicion. That's fine, but I wonder what happened next. After all, the store indiscriminately made its network available to the public, set no conditions of use, apparently made no request of this individual not to use the network, and made no complaint to police. In Canada, the Crown would have noted the conspicuous absence of complaint or due diligence from the store and therefore, I suspect, found no basis to uphold the charges.
But governments are responsible for managing public records and making them available to the public. This responsibility cannot be properly exercised through the use of proprietary document formats, since these would unreasonably exclude a segment of the public, and potentially excludes the government itself.
By definition, proprietary document formats are not in the public domain, are not standardized, and are subject to the whims of whatever proprietary software supports them on a given day. No responsible society wants its public institutions held hostage in this way.
Believe it or not, it turns out that not all governments are as corrupt as the United States federal administration. Some are more corrupt, some are less corrupt, and what principles of government in particular are up for sale depends on the government.
Even within the USA it's not all uniform among the states, take Massachusetts for example.
So, while it's fine to be cynical in a particular instance, it's not possible to extend your reasoning more generally from that position. In other words, there's hope. There really is.
If it's not technically possible, then you don't have a problem.
See CALEA section 105.
Of course it's always a sensible business decision to operate in
a jurisdiction whose conditions are favorable to your business.
That's just a general comment about how the world works. As a
Canadian computer scientist, I made this comment during the
Clipper chip initiative, where key escrow under control of the US
government was going to be part of its capability. To an
international observer, such a chip seemed doomed from the
outset, because there was absolutely no market for it outside
the United States. It might have ended up being mandated within
the States, but outside, forget it.
Whatever the legitimate security needs of society may be, we have
to come at them in a way that actually delivers value. Your
message service is an example of this concept. I'd personally
rather operate within a distributed certificate infrastructure,
but that's because I don't find the technology a barrier, and
I'm more comfortable managing my own key separation. But more
power to you.
In any event, I think that history, and the history of law,
shows an understanding that there is a net benefit to society
from respecting individual privacy. The cool thing about
asymmetric crypto is that privacy and anonymity are factors
that can be treated in separate ways. You can have public but
anonymous transactions (voting) and every other combination.
I think that's how society will ultimately be able to address
fraud, an activity which the numbers tell us costs society far
more than the risk of illegal conspiracy ever has.
Well, here's the thing. Unless there's some way to connect with the service, it isn't much use to anyone. Imagine that it's just a device sitting on the net somewhere, and packets are going back and forth to it. If you ask the service provider what do those packets really mean, and the provider can truthfully say "I dunno" then, in my understanding, CALEA has no application. So it would be on a backbone router, for example.
Where CALEA has traction, however, is at the edge of the network. The rationale for extending CALEA to broadband was that broadband subscribers are essentially like dialup subscribers, so if surveillance is permitted for the POTS network it should be okay here as well. At this point in the network, there is a mapping between an individually identified subscriber and his or her traffic. After all, this is how network providers can bill for services.
All of this is essentially restating your comments, just to be sure we're on the same ground. Now, the interesting and perhaps contentious part is what exactly constitutes the edge of the network. What if that device sitting on the net somewhere isn't just passing uninterpreted packets? What if it's providing, say, encrypted file storage? If there is any notion of "subscriber" to that service, then there will be packet traffic to and from that device which is particularly associated with that subscriber. Then CALEA applies, and under section 105 the provider must not just capture but also decrypt the traffic upon lawful authorization. (Apologies for my previous post which cited section 104 for this.)
Under CALEA an intercept is performed against a specific individual, for example a broadband subscriber. It is illegal to capture traffic except to and from that individual. As you point out, that can add up. So who pays for it?
When the FCC went through its comment period prior to the Second Report and Order, many network providers expressed concern not only about equipment changes, but also about bearing the cost of this traffic, since they are neither allowed to increase their rates nor to bill the government. In its decision, the FCC essentially said, we've listened to concerns from industry and we're confident that industry will come up with a solution if compelled to do so.
Under CALEA section 105, if this service is based in the United States, you will have to provide decryption of traffic to and from this service if presented with a court order or other lawful authorization. The FCC contemplates fines of up to $100,000 per day per incident for noncompliance.
Your point about the checks and balances involved in getting a court order is correct, and I generally agree with your comments. Each intercept requires a deliberate act by the carrier, so it can't just be activated by remote control from some police station. The exact text from CALEA section 105 is:
A telecommunications carrier shall ensure that any interception of communications or access to callidentifying
information effected within its switching premises can be activated only in accordance with a
court order or other lawful authorization and with the affirmative intervention of an individual officer or
employee of the carrier acting in accordance with regulations prescribed by the Commission.
Moreover, CALEA specifically prohibits interception of traffic except under these terms, so a carrier which, let's say, didn't carefully scrutinize a court order could find itself in violation of federal law.
But in terms of civil rights, CALEA creates a slippery slope. Even though the powers of CALEA itself may be limited, once the capability exists to perform this sort of surveillance, then other legislation such as FIMA or the Patriot Act can come in and exploit the capability. Even within CALEA there is an emergency provision to perform surveillance without a proper court order, which I think puts the network provider in a tight spot.
This is true, but our interpretation is that it simply means that CALEA does not require a provider to develop a specific intercept capability for those services. In other words, if a provider operates some sort of message board system, the provider does not have to develop some kind of surveillance interface for it.
However, the provider does have to perform surveillance on the traffic between its subscribers and that system per CALEA section 103, which amounts to the same thing. Now imagine that traffic to and from the message board is encrypted. CALEA section 104 does not in general require decryption capability but makes a specific exception when "encryption was provided by the carrier".
Section 103 covers the above points. On the subject of how CALEA expects to treat encrypted communications, it also contains the following passage:
A telecommunications carrier shall not be responsible for decrypting, or ensuring the
government's ability to decrypt, any communication encrypted by a subscriber or customer, unless the
encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the
communication.
I'll add another response which accords with the first two.
In a very small organization, you end up with your hands on the hardware a lot, but this condition dilutes in larger organization due to economies of scale. For example, the person in charge of infrastructure is not doing desktop system installs. A more junior person can do that at less cost. Even then, a knowledgeable person doing desktop installation and maintenance has figured out the value of doing that centrally as well. There comes a point where an untrained office worker can go over to the supply closet, pick up a box, and plug it in. Half an hour later, a fresh new system fully configured and ready for login. Because that box is not infrastructure, it represents an effective use of infrastructure.
The real infrastructure work is about anticipating the evolution of technology, adding capabilities to the infrastructure pyramid, and capacity planning. And as this whole pyramid tends to become larger and more complex over time, the hardware layer becomes proportionally less prominent. This holds true on the desktop, in the server room, and on the network.
If you add up what you really do in a day's work, most of it does not require dispatching staff to the site. User support, though only peripherally an infrastructure function, is worth mentioning because it too doesn't actually require staff on site either. This does not match popular expectation, of course, which is that infrastructure is just a fancy word for laying cable and installing desktop software and things of that nature.
Great point, and one that doesn't appear in the article, nor even in Susan Landau's piece cited therein.
Another point that didn't seem to come up anywhere is the cost of commuting. Perhaps it's so obvious that people assume it doesn't bear mentioning, but I think it represents a significant, and understated, part of the cost/benefit equation.
The evolution of technological complexity that makes it hard to match up a sophisticated enterprise with talented workers has produced a culture in which people transport their bodies substantial distances away from their homes simply in order to transport ideas. But this benefit is at best marginal compared to effective telecommuting, in cases where that's possible. To assume otherwise is simply an old habit that needs to be reexamined.
If we add to this equation a proper accounting of the effects of commuting on parenting, the development of community, environmental impact, mental health, opportunity for exercise, the enormous burden on road infrastructure and the cost of traffic accidents, not to mention the sheer waste of human time, the social arguments in favor of telecommuting would seem to dominate.
You should be even more surprised that it's not mandatory!
How is this all related to Open source and its effects?
I don't think that it's possible to claim a direct relationship, but indirectly
these trends create a market for certain capabilities. And if you develop
software for the traditional office market, this might cause you to rethink
some of your assumptions, for example, that you get to sell into a space which
controls what goes on both the servers and clients.
The way things are trending, any software you put out there has to interoperate
with whatever is already out there. And what type of software is agile
enough and ubiquitous enough to interoperate bestest and fastest? That's how
the discussion moves on to open source. I think.
Of course this will work. It's the same principle that gave rise to the Internet and FTP and HTTP and all the rest.
With the cost of entry converging toward zero, it's not hard to cross the point where it's easier and cheaper to just do it than to worry about how to make money doing it.
I'm glad to see these points being made early in the discussion. First, the existing legislation was formulated in consideration of fair use. It seems to me that those terms of reference have not materially changed. Unless this legislation is to be revoked, it will remain in force. Second, the existing media levy already compensates copyright holders. No doubt this legislation was not developed in a vacuum, but at the request of interested parties. In other words, the right to fair use of those copies has already been paid for.
As Michael Geist points out, if copyright reform is indeed being proposed by the Conservatives, it will not be received with acclaim but with public hostility, and rightly so.
Slashdot Mirror
Interesting question with, I think, answers that branch in two directions.
However, it often happens that we wish to do things for which existing theory is not sufficient, and then it helps tremendously to have a rigorous discipline by which to judge whether such a wish is utterly doomed (mathematically or physically nonsensical) or just not yet fully explored. I can't help but think that the people who are least able to tell the difference between the two are also the most likely to disparage the mathematical roots of computer science.
I remember many years ago drinking beer with one of my number theory profs and naïvely asking him where in our careers he thought we would be applying this knowledge. His answer was, oh no, I though you understood, that's not the idea at all. You'll never use this material. I'm just teaching you how to think.
I was going to offer a dissent, until I noticed how carefully you have phrased your observation.
What I was going to say was something along the lines of how it can be a benefit to modularity to leave out the error handing. But that's in the prototype stage of code development, where (I feel) that all available cognitive bandwidth should be applied to understanding the structure of the system without distraction.
But you're referring to production code, at which point all choices concerning modularity have been weighed and decided and baked it. And if part of that baking didn't involve a careful walkthrough to test for impossible or out-of-bounds conditions, error returns, and so on, and if the error handling framework itself lacks coherence, then yeah, that's not quite what I'd call a finished product.
Someone who thinks it is is still operating at the apprentice stage. These people are easy to hire and they can still be useful to have on staff. But they should be working under supervision, and for that you definitely need to have a master on staff.
Yes, certainly, if measured as number of person-hours spent engaged in philosophical inquiry. This was, and is, the monastic tradition, and worldwide it did and does greatly outnumber the activities of the privileged, and published, few.
You counter with some interesting examples of overt philosophical inquiry which produced events of historical significance. These were certainly influential and important for society at large, but that being so does not address the previous -- and eminently valid -- comment that philosophy is not a pastime of the wealthy.
I no longer have a TV. I had one for awhile, but found that there are more interesting ways to spend time, like dating women for example. I have ADSL, which is not quite as fast as that 10 gig network I got used to at one point, but it still lets me work effectively from home, and keep up with party invitations. But when I'm up at the island I do completely without, for weeks at a time, until the boat comes to take me back to the mainland.
I have a cell phone, which is handy when I want it, for example when I'm alone on the island running a chainsaw or something, but it usually stays in its charging cradle where it won't intrude on my life. Before cell phones came along I did without that as well. We have a community radiophone down by the dock and in the old days it was either that, when it worked, or wait a day or two for a boat to come along.
I found that degree of isolation scary for the first few years, but also inexpressibly delicious, far more deeply rewarding than playing with some new techno toy. I already get plenty of technology at work, and I approach its use, I suppose, with a certain amount of professional reserve, knowing that nine out of every ten hot new technologies are going to be forgotten within five years anyway.
Want to invest attention in something worthwhile? How about spending time with your friends? Yes, there's more to friendship than showing off your toys.
Absolutely. Users already can install applications. There's no great mystery to it. They're also free to develop applications, if they care to. All the tools they might need are there, or can be downloaded off the net.
Of course, with Linux being a secure environment, your system administrators probably won't let you have root, and they may restrict what you can do in other ways, even to the extent of disallowing programs to execute from your home directory if it's felt, for example, that choice of software is not your responsibility. But it should be clear that's a matter of policy, not capability. Apart from security, one good reason the policy might be in place is to prevent people from diluting the economies of scale that your organization is trying to achieve through centrally managing software installation and upgrades.
It sounds like you're complaining that the policy is not to your liking. That's something you can discuss within your organization.
...
However, perhaps the greatest benefit of switching to free software is that the reliability of the new system frees up technical staff to do more than routine support.
I agree that it takes a fair amount of tracking to quantify total cost of ownership beyond the large but incidental fixed cost of implementation.
Still, staff salaries are usually a significant cost to any operation, so if staff resources are able to shift into new activities as a result of the change, it would seem common sense to begin by tracking that. The article has two sentences side by side. It shouldn't be hard to connect the dots between them.
Moreover, if we're measuring true TCO, we should look at overall effect on staff time, not just tech support staff. In a Linux terminal server environment, the entire staff population will now be spending zero time on fiddling with their workstations. It would be nice to compare this with the number of hours on average that individual staff members previously spent in dealing with issues on Windows workstations. That's a big part of TCO as well, but if you never measure it, how can you know when you've improved it?
I don't know the answer in this case, but I'll make one general observation. When Microsoft promotes its lower TCO calculations, look to see whether they fairly compare the total staff time spent in system configuration, software installation, failures due to bugs, compatibility and security issues, problem analysis and resolution.
Could be because a successful intrusion is invisible? Just a thought.
Does that mean there's a "least optimal" too? How about "very optimal", or even "optimally optimal"?
My understanding applies to Canada only, where I believe that generally someone has to register a complaint with police in order to initiate a criminal investigation, unless of course the police themselves witness or have evidence giving cause to investigate. If charges are laid as a result, they must be approved by the Crown before going to court. This also holds for diversion.
So who laid the complaint in this case? Not the store, evidently. The police acted on suspicion. That's fine, but I wonder what happened next. After all, the store indiscriminately made its network available to the public, set no conditions of use, apparently made no request of this individual not to use the network, and made no complaint to police. In Canada, the Crown would have noted the conspicuous absence of complaint or due diligence from the store and therefore, I suspect, found no basis to uphold the charges.
P.S. Saw your sig. I'm going to Fairbanks on Wednesday, hopefully before any of these CALEA orders start coming in...
By definition, proprietary document formats are not in the public domain, are not standardized, and are subject to the whims of whatever proprietary software supports them on a given day. No responsible society wants its public institutions held hostage in this way.
Even within the USA it's not all uniform among the states, take Massachusetts for example.
So, while it's fine to be cynical in a particular instance, it's not possible to extend your reasoning more generally from that position. In other words, there's hope. There really is.
Of course it's always a sensible business decision to operate in a jurisdiction whose conditions are favorable to your business. That's just a general comment about how the world works. As a Canadian computer scientist, I made this comment during the Clipper chip initiative, where key escrow under control of the US government was going to be part of its capability. To an international observer, such a chip seemed doomed from the outset, because there was absolutely no market for it outside the United States. It might have ended up being mandated within the States, but outside, forget it.
Whatever the legitimate security needs of society may be, we have to come at them in a way that actually delivers value. Your message service is an example of this concept. I'd personally rather operate within a distributed certificate infrastructure, but that's because I don't find the technology a barrier, and I'm more comfortable managing my own key separation. But more power to you.
In any event, I think that history, and the history of law, shows an understanding that there is a net benefit to society from respecting individual privacy. The cool thing about asymmetric crypto is that privacy and anonymity are factors that can be treated in separate ways. You can have public but anonymous transactions (voting) and every other combination. I think that's how society will ultimately be able to address fraud, an activity which the numbers tell us costs society far more than the risk of illegal conspiracy ever has.
Where CALEA has traction, however, is at the edge of the network. The rationale for extending CALEA to broadband was that broadband subscribers are essentially like dialup subscribers, so if surveillance is permitted for the POTS network it should be okay here as well. At this point in the network, there is a mapping between an individually identified subscriber and his or her traffic. After all, this is how network providers can bill for services.
All of this is essentially restating your comments, just to be sure we're on the same ground. Now, the interesting and perhaps contentious part is what exactly constitutes the edge of the network. What if that device sitting on the net somewhere isn't just passing uninterpreted packets? What if it's providing, say, encrypted file storage? If there is any notion of "subscriber" to that service, then there will be packet traffic to and from that device which is particularly associated with that subscriber. Then CALEA applies, and under section 105 the provider must not just capture but also decrypt the traffic upon lawful authorization. (Apologies for my previous post which cited section 104 for this.)
When the FCC went through its comment period prior to the Second Report and Order, many network providers expressed concern not only about equipment changes, but also about bearing the cost of this traffic, since they are neither allowed to increase their rates nor to bill the government. In its decision, the FCC essentially said, we've listened to concerns from industry and we're confident that industry will come up with a solution if compelled to do so.
Don't say that I didn't warn ya.
http://www.askcalea.net/docs/calea.pdf
But in terms of civil rights, CALEA creates a slippery slope. Even though the powers of CALEA itself may be limited, once the capability exists to perform this sort of surveillance, then other legislation such as FIMA or the Patriot Act can come in and exploit the capability. Even within CALEA there is an emergency provision to perform surveillance without a proper court order, which I think puts the network provider in a tight spot.
However, the provider does have to perform surveillance on the traffic between its subscribers and that system per CALEA section 103, which amounts to the same thing. Now imagine that traffic to and from the message board is encrypted. CALEA section 104 does not in general require decryption capability but makes a specific exception when "encryption was provided by the carrier".
- Perform an intercept as specified in a court order signed by a judge in good standing.
- Not perform an intercept on any other network traffic but that specified.
The complete text is at http://www.askcalea.net/docs/calea.pdf.Section 103 covers the above points. On the subject of how CALEA expects to treat encrypted communications, it also contains the following passage:
In a very small organization, you end up with your hands on the hardware a lot, but this condition dilutes in larger organization due to economies of scale. For example, the person in charge of infrastructure is not doing desktop system installs. A more junior person can do that at less cost. Even then, a knowledgeable person doing desktop installation and maintenance has figured out the value of doing that centrally as well. There comes a point where an untrained office worker can go over to the supply closet, pick up a box, and plug it in. Half an hour later, a fresh new system fully configured and ready for login. Because that box is not infrastructure, it represents an effective use of infrastructure.
The real infrastructure work is about anticipating the evolution of technology, adding capabilities to the infrastructure pyramid, and capacity planning. And as this whole pyramid tends to become larger and more complex over time, the hardware layer becomes proportionally less prominent. This holds true on the desktop, in the server room, and on the network.
If you add up what you really do in a day's work, most of it does not require dispatching staff to the site. User support, though only peripherally an infrastructure function, is worth mentioning because it too doesn't actually require staff on site either. This does not match popular expectation, of course, which is that infrastructure is just a fancy word for laying cable and installing desktop software and things of that nature.
Another point that didn't seem to come up anywhere is the cost of commuting. Perhaps it's so obvious that people assume it doesn't bear mentioning, but I think it represents a significant, and understated, part of the cost/benefit equation.
The evolution of technological complexity that makes it hard to match up a sophisticated enterprise with talented workers has produced a culture in which people transport their bodies substantial distances away from their homes simply in order to transport ideas. But this benefit is at best marginal compared to effective telecommuting, in cases where that's possible. To assume otherwise is simply an old habit that needs to be reexamined.
If we add to this equation a proper accounting of the effects of commuting on parenting, the development of community, environmental impact, mental health, opportunity for exercise, the enormous burden on road infrastructure and the cost of traffic accidents, not to mention the sheer waste of human time, the social arguments in favor of telecommuting would seem to dominate.
You should be even more surprised that it's not mandatory!
I don't think that it's possible to claim a direct relationship, but indirectly these trends create a market for certain capabilities. And if you develop software for the traditional office market, this might cause you to rethink some of your assumptions, for example, that you get to sell into a space which controls what goes on both the servers and clients.
The way things are trending, any software you put out there has to interoperate with whatever is already out there. And what type of software is agile enough and ubiquitous enough to interoperate bestest and fastest? That's how the discussion moves on to open source. I think.
Beautifully said. I don't know when I've seen a concept put forward so clearly and succinctly on Slashdot. Cheers!
With the cost of entry converging toward zero, it's not hard to cross the point where it's easier and cheaper to just do it than to worry about how to make money doing it.
As Michael Geist points out, if copyright reform is indeed being proposed by the Conservatives, it will not be received with acclaim but with public hostility, and rightly so.