LimeWire's Mark Gorton Brings Open-Source To Urban Planning 91
mytrip writes to tell us that Mark Gorton of LimeWire fame is translating his knowledge from moving bits to moving people. Taking profits earned from his software business, Gorton is applying them to projects aimed at making urban transportation safer, faster, and more sustainable. "That's not the only connection between open-source software and Gorton's vision for livable cities. The top-down culture of public planning stands to benefit by employing methods he's lifting from the world of open-source software: crowdsourced development, freely-accessible data libraries, and web forums, as well as actual open-source software with which city planners can map transportation designs to people's needs. Such modeling software and data existed in the past, but it was closed to citizens. Gorton's open-source model would have a positive impact on urban planning by opening up the process to a wider audience, says Thomas K. Wright, executive director of the Regional Plan Association, an organization that deals with urban planning issues in the New York metropolitan area."
Re:Sounds like... (Score:5, Interesting)
Urban planning can be good and bad. Certainly Central Park is a win, but highways largely suck when they are run through existing cities. New York's mass transit is a combination of free market and planned routes...
Personally, one of my favorite little projects that demonstrates how a lack of planning is sometimes best is at University of Maryland. They have this center mall. Basically, the kept having to re-sod it because no one would stay on the paths. During a renovation it occurred to them to just pave the deer-paths... it looks crazy but now they don't have the same sod problems.
An interesting approach. (Score:5, Interesting)
Although I would quibble with some of the Prince of Wales' suggestions for urban villages, I think they would make for a sound footing for any kind of open source urban plan, even if they're sub-optimal. Sort of like POSIX is flawed as an OS specification, but starting from POSIX or using POSIX as a guide often produces better results (such as Linux) than starting completely from scratch (the way Windows has).
I would also point out that optimizing things for mass transit requires that the area in question actually supports meaningful mass transit. Most States either restrict it to a relatively insignificant area (eg: Portland OR's TriMet) or render what is supplied useless (never, ever take a bus in Norfolk, VA, unless you've got a week's supply of food).
I grew up with British Rail, Greater Manchester Transport and - when they finally appeared - Busy Bee Buses. As much as I had contempt for them - BR once excused their late trains on the wrong type of snow, and a single inspection one year failed over 30% of GMT's buses due to brake failure - the speeds, coverage and level of service would put any American mass transit system to shame.
Would I accept the UK's level of service in the US? It wold be infinitely better, but I wouldn't regard it with any less contempt. You don't have to go far to be infinitely better than zero. It would need to be vastly more reliable and vastly more dependable and have superior coverage.
(When you look at the disused stations and abandoned rail lines in the UK, you can get a better feel for what I consider to be an acceptable level of coverage. It must be possible to dispense with cars for the majority of the needs of the majority of the people, or it's insufficient to fix the root problems and will merely delay the inevitable.)
Re:Sounds like... (Score:3, Interesting)
Bah, try this link instead [google.com].
Are you bloody nuts? (Score:5, Interesting)
You want the same people who will be hopping around in their underwear, half-drunk, screaming at a television screen this sunday to be involved in how our roads are designed, our bus schedules, rail lines, and more? Allow me to interject some reality here -- there's a reason the public sector only allows people with the word "Engineer" in the job title to work on these projects. They cost millions, sometimes tens of millions of dollars, they effect millions of people, and a screw-up can cost lives or be a logistical nightmare for decades to come. Just think about your morning commute now, and then realize that this situation was created by some of the brightest and most educated minds we have in society today. These people model these problems on supercomputers, applying sophisticated algorithms and methodology that takes months, sometimes years, of slaving at a desk every day, 9 to 5, to effect a merely "acceptable" solution.
Of course, try telling this to the average driver and you're likely to get a string of obscenities and an "I could do better attitude." With all respect, no sir you cannot. Not anymore than how most of the population thinks they'd be a better president, or a better quarter back, or much of anything else. There are some classes of problems that cannot be solved by simply throwing more people at it. A thousand people working on a problem isn't necessarily likely to come up with a better solution than a hundred, or even ten people, working on the same problem. It's about suitable labor, which is a quality issue, not a quantity one.
You people should know better than to suggest this. I do not want Joe Average doing urban development, especially when he has enough trouble just getting through rush hour traffic without going postal on someone. And so we come to the part of the discussion where rationality ends and zealotry begins. There are some things that open source methodology will be suboptimal for. Specifically, things that require extreme specialization and/or have exacting standards generally won't have a healthy community of open source developers. There's only so many people in the world with the time, resources, and dedication to perform a given task, and open source development requires a certain critical mass to be reached to succeed.
Plot a supply and demand curve and if you find those people come at a very high cost any open source development will be labored and frustrated. All open source does is severely cut the labor cost. It does NOT solve the problem of lack of suitable labor resources. This is why open source excels at general purpose systems and applications. Open source is (as a rule) quite flexible. Which is also exactly why it's ill-suited for highly specialized systems with exacting standards -- there are few labor resources in the market to support it. Ergo, those resources are at a premium. Open Source as a broad concept takes under- or un-utilized labor and creates goods and services from it. You won't find much open source development from resources that are being heavily utilized. Or, in plain-english -- college students, the unemployed, part-time workers, etc. That is your labor capital for open source. Not the engineer making $150k a year designing fire-control systems under contract for the military. Chances are, the more established and well-paid you are in the field, the less likely you are to be investing in open source projects.
So there you have it. Before you hit reply, I just want to remind you that these are general statements, so before you present your edge case in some half-hearted attempt to prove the entire argument wrong, please consider the bigger picture.
Re:Removal of People (Score:4, Interesting)
Building a city flow is very different than building data flow.
The number one difference is that cities take pride in their monuments and historical buildings, which tend to become the source of traffic bottlenecks. It would be best if our cities could move with traffic demand, and scale with traffic demand. But currently that is impossible.
Actually, the number one difference is that in road traffic, the packets can think, and decide that they're more clever about which route to take than the information available.
For example, for years and years now, there have been live signal systems that are capable of gathering traffic data and making realtime adjustments to signal timing to optimize flow. But they don't do that; instead, they use the traffic data to make changes to the established timing, but keep it basically the same from one day to the next. Why? Because if a person hits the same light at about the same time every day, and *sometimes* it's a short red and *sometimes* it's a long red, their frustration increases, and they're more likely to run the light if it's "taking too long."
Packets will patiently wait their turn, "trusting" the system to do things right. People, not so much.