Lots of systems were initially designed with suboptimal/superseded technology, and over time, adjustments got made. In Spain, for example, they simply abandoned the old gauge and went with standard gauge when building new high speed lines so they could connect outside the country. The problem with BART is its governance structure: an independent government agency that competes with other transit agencies in the same geographical space, and has no particular incentive to serve the greatest need.
An example is in san bruno, where the BART tracks go directly underneath the Caltrain station. San Bruno is the last BART stop between SF and the SF Airport, so it would be a perfect place for a connection between the two systems. But BART chose to build its San Bruno station over a mile away, to serve the Tanforan Mall, and to forego a connection with Caltrain there. I think the reason is BART realized if you could get off BART at San Bruno from SFO, you could take an express train to downtown SF, and BART would lose business (although it would be great for passengers, of course). So the result was the terrible triangle of BART's San Bruno, SFO, and Millbrae stations. Instead of giving both SFO and Millbrae bound train passengers the option to change at San Bruno, which would have served riders much better, they built it as an either/or, so that Caltrain-bound BART passengers had to take a Millbrae train. After a few months, they "realized" that the connector between Millbrae and SFO was not economically viable, so they started forcing transfers from Millbrae Caltrain and buses to take BART to San Bruno and then change trains to backtrack to SFO, for most of the day. Before the BART extension, going from Millbrae station to SFO used to be a free, quick, and reliable shuttle ride. They turned it into such a time-wasting mess that it is a disincentive to ride Caltrain. But of course that suits BART just fine, because they can't make money dedicating trains to shuttling passengers from Millbrae to SFO, but they can make money by being a monopoly provider of train access between SFO and SF. If the two systems were governed by a single agency, I think they would make rational decisions like connecting BART and Millbrae at San Bruno.
It is BART's priorities, not just its tracks, that are misaligned with other systems.
I just got a nearly new version of the predecessor of the N900 - the Nokia N810 Internet Tablet - for $140 on EBay. Prices should be coming down even more. It's not a phone, but runs Maemo, gives you root (with a simple download), and has bluetooth, Skype over wifi, and a USB port, so there are multiple ways to turn it into a phone through a data plan (with USB cellular modems and routers, for example). And it's a GPS device to boot. There really is some wonderful technology out there if you know where to look and don't buy hyped up but locked down "smart" phones.
I agree with your summation. We can judge this article based on what is says about the Affero GPL:
Another curious licence is the Affero GPL - - which aims to close the "Application Service Provider Loophole". What it means is that if I install an AGPLed program on a public web-server and modify it then I must make my modifications public. However, the Free Software Definition , says that one must have "The freedom to study how the program works, and adapt it to his needs.". As a result, I personally don't consider the AGPL as free (because I may wish to run it on my publicly accessible web-server and modify it), but the FSF thinks otherwise. We have enough problems with the suitability of the GPL for embedded systems, that we don't need to kill the prospering web-apps market too.
Apparently the author thinks that if he has to share modifications, then his "freedom to study how the program works, and adapt it to his needs" has been compromised, and the license is "curious". Why not just argue that the GPL itself is not a Free Software license?
There are many aspects to an ICT policy. I'll just address a few points related to procurement versus in-house development, which is one key issue. Universities tend to draw tech advice and management from people who overapply lessons from the corporate world and forget things that are unique to universities. For example:
(1) In my university administrators have consistently bought expensive proprietary tools from companies that do not specialize in academic software, e.g. modifying e-commerce tools to be student course registration and tuition systems. This can lead to mismatches in the user experience - the student's course list becomes a "shopping cart" with a "checkout", and functions that are necessary on a local level either don't get implemented or have to wait in a long list of changes that are expensively requested from the vendor, such as accommodations to allow for flexible credits when that wasn't built into the system or didn't follow readily from the original software model.
(2) Part of the reason for going with off-the-shelf solutions that are poor matches for local needs is the bizarre and usually mistaken belief that there is insufficient in-house talent to get the job done. In few places is this less true than at a university with computer science students, who will often hack cheaply and or even for free and have created some truly terrific tools that blow away expensive proprietary ones. IT personnel are also often more available to hack at a university than elsewhere. University IT departments often attract good programmers who are somewhat underemployed because they like working in a university. In most cases, a tailored solution, open source generally, will be cheaper to produce and certainly to maintain in a university than it will be to buy software from a vendor, even if the vendor specializes in university software. This is less true as you move toward very specialized types of software such as graphical modeling tools, but universities often spend huge amounts of money on vendors to buy stuff with really simple interfaces that could have been developed locally or in consortium with other universities.
(3) Another mistake is letting software drive policy. Software maker says "from now on, courses can't meet at nonstandard times" or "instructors can't change the grading basis", etc., and rules that used to be determined by academic committees get made de facto through programming choices that no one at the university had a say in. Another argument against outside vendors and in favor of in-house development when the software is not terribly complicated.
(4) In some universities the concept of open source goes ideologically against what the powers that be want to promote, e.g. students graduating and forming companies based on proprietary software, or not pissing off donors from such companies. It's not clear this can be called a mistake in the context of the school's overall economic model, but it is a mistake to forget this bias when explaining why a school's IT policy does not favor free/open source software.
Slashdot Mirror
Lots of systems were initially designed with suboptimal/superseded technology, and over time, adjustments got made. In Spain, for example, they simply abandoned the old gauge and went with standard gauge when building new high speed lines so they could connect outside the country. The problem with BART is its governance structure: an independent government agency that competes with other transit agencies in the same geographical space, and has no particular incentive to serve the greatest need. An example is in san bruno, where the BART tracks go directly underneath the Caltrain station. San Bruno is the last BART stop between SF and the SF Airport, so it would be a perfect place for a connection between the two systems. But BART chose to build its San Bruno station over a mile away, to serve the Tanforan Mall, and to forego a connection with Caltrain there. I think the reason is BART realized if you could get off BART at San Bruno from SFO, you could take an express train to downtown SF, and BART would lose business (although it would be great for passengers, of course). So the result was the terrible triangle of BART's San Bruno, SFO, and Millbrae stations. Instead of giving both SFO and Millbrae bound train passengers the option to change at San Bruno, which would have served riders much better, they built it as an either/or, so that Caltrain-bound BART passengers had to take a Millbrae train. After a few months, they "realized" that the connector between Millbrae and SFO was not economically viable, so they started forcing transfers from Millbrae Caltrain and buses to take BART to San Bruno and then change trains to backtrack to SFO, for most of the day. Before the BART extension, going from Millbrae station to SFO used to be a free, quick, and reliable shuttle ride. They turned it into such a time-wasting mess that it is a disincentive to ride Caltrain. But of course that suits BART just fine, because they can't make money dedicating trains to shuttling passengers from Millbrae to SFO, but they can make money by being a monopoly provider of train access between SFO and SF. If the two systems were governed by a single agency, I think they would make rational decisions like connecting BART and Millbrae at San Bruno. It is BART's priorities, not just its tracks, that are misaligned with other systems.
...who said he wanted to start an a capella group, but with instruments.
I just got a nearly new version of the predecessor of the N900 - the Nokia N810 Internet Tablet - for $140 on EBay. Prices should be coming down even more. It's not a phone, but runs Maemo, gives you root (with a simple download), and has bluetooth, Skype over wifi, and a USB port, so there are multiple ways to turn it into a phone through a data plan (with USB cellular modems and routers, for example). And it's a GPS device to boot. There really is some wonderful technology out there if you know where to look and don't buy hyped up but locked down "smart" phones.
Another curious licence is the Affero GPL - - which aims to close the "Application Service Provider Loophole". What it means is that if I install an AGPLed program on a public web-server and modify it then I must make my modifications public. However, the Free Software Definition , says that one must have "The freedom to study how the program works, and adapt it to his needs.". As a result, I personally don't consider the AGPL as free (because I may wish to run it on my publicly accessible web-server and modify it), but the FSF thinks otherwise. We have enough problems with the suitability of the GPL for embedded systems, that we don't need to kill the prospering web-apps market too.
Apparently the author thinks that if he has to share modifications, then his "freedom to study how the program works, and adapt it to his needs" has been compromised, and the license is "curious". Why not just argue that the GPL itself is not a Free Software license?
Maybe they were hoping for jury nullification.
There are many aspects to an ICT policy. I'll just address a few points related to procurement versus in-house development, which is one key issue. Universities tend to draw tech advice and management from people who overapply lessons from the corporate world and forget things that are unique to universities. For example:
(1) In my university administrators have consistently bought expensive proprietary tools from companies that do not specialize in academic software, e.g. modifying e-commerce tools to be student course registration and tuition systems. This can lead to mismatches in the user experience - the student's course list becomes a "shopping cart" with a "checkout", and functions that are necessary on a local level either don't get implemented or have to wait in a long list of changes that are expensively requested from the vendor, such as accommodations to allow for flexible credits when that wasn't built into the system or didn't follow readily from the original software model.
(2) Part of the reason for going with off-the-shelf solutions that are poor matches for local needs is the bizarre and usually mistaken belief that there is insufficient in-house talent to get the job done. In few places is this less true than at a university with computer science students, who will often hack cheaply and or even for free and have created some truly terrific tools that blow away expensive proprietary ones. IT personnel are also often more available to hack at a university than elsewhere. University IT departments often attract good programmers who are somewhat underemployed because they like working in a university. In most cases, a tailored solution, open source generally, will be cheaper to produce and certainly to maintain in a university than it will be to buy software from a vendor, even if the vendor specializes in university software. This is less true as you move toward very specialized types of software such as graphical modeling tools, but universities often spend huge amounts of money on vendors to buy stuff with really simple interfaces that could have been developed locally or in consortium with other universities.
(3) Another mistake is letting software drive policy. Software maker says "from now on, courses can't meet at nonstandard times" or "instructors can't change the grading basis", etc., and rules that used to be determined by academic committees get made de facto through programming choices that no one at the university had a say in. Another argument against outside vendors and in favor of in-house development when the software is not terribly complicated.
(4) In some universities the concept of open source goes ideologically against what the powers that be want to promote, e.g. students graduating and forming companies based on proprietary software, or not pissing off donors from such companies. It's not clear this can be called a mistake in the context of the school's overall economic model, but it is a mistake to forget this bias when explaining why a school's IT policy does not favor free/open source software.