It probably took less than a minute for TED.com to win me over when I was first introduced to the site in the summer of 2007. The organization had started releasing its talks online the previous year under a Creative Commons license. I loved the concept of being able to sit down and watch a video for 20 minutes that would give me new insights, challenge my beliefs, get a glimpse of the bright future of a particular field, or on a really good day, have my mind completely blown (the number of high-quality presentations on this site still surprises me).
Ever since TEDxEdmonton began in 2010 — as part of TED's initiative to allow independently organized local franchises — I've wanted to attend one of these events in person. As luck would have it, a few of us from Cybera were able to snag tickets to the first Salon Series, held last Wednesday, February 8th.
Probably the most interesting talk for me was from Amy Shostak of Rapid Fire Theatre. As an improv artist speaking to a bunch of tech geeks, Amy was a bit out of her element, but I think this "outsider" status gave her some of the best insight into open source culture.
My favourite part of Shostak's talk was her definition of the three key virtues of a great improviser:
- Find everything inspiring.
- Embrace failure.
- Serve the scene (as opposed to your own ego).
You don't have to look too hard to find similar virtues extolled in open source software development. In fact, I would say these rules apply to any sort of software development.
Look at a really good piece of code and you'll probably find the first virtue, often in the form of a really well thought out metaphor. You install "drivers" on your operating system for various hardware, which really do "drive" the hardware (they could have been called "software based hardware programming toolkits", or something similarly horrible). Or consider the "desktop" on which you move virtual objects around every day. These names make sense now, but they didn't at the time, and they came about because influences outside of software were brought in to bear.
Embracing failure is also fundamental to open source ' after all, the whole point is to get your idea out there for others to improve upon — and it's even starting to make some inroads into more traditional sectors. Ashley Casovan, Strategic Coordinator for the Chief Information Officer at the City of Edmonton, gave a talk about the city's open data initiatives. She was asked about concerns over the quality of data, and how those factored into the decision of whether or not to release it. Her response: if you wait until the data's 100% correct, you'll never release it.
Casovan outlined this rule of thumb for releasing government data: if the government is willing to make decisions based on it, it's good enough for release. That statement was both surprising and encouraging in its balance between carefulness and openness, and it's one that I'd imagine most people would not expect to come from any level of government.
Finally, there is serving the scene. A great close-to-home example would be the development of OpenStack, which we've talked about in previous Tech Radar posts. This development comes from competing companies recognizing the utility of putting aside their rivalries in this one area to make a great, open alternative to proprietary public clouds. With open source, it really is about making better software.
I should also make a quick mention of George Siemens' provocative talk about applying big data to education, which relates to my previous post on digital textbooks. He proposed a system that would analyze student patterns using a variety of sources, including social networks and other available records. This information could then be used to design a student's curriculum to suit his or her particular needs, as opposed to the traditional "one size fits all model". So, instead of just having an "interactive textbook", think "personal textbooks" that explain concepts in a way that fits your life experience.
Of course, there are more than a few privacy concerns with this approach. Audience members also brought up the danger of pigeon-holing a student or driving them towards easier concepts that they want to learn, as opposed to harder ones that they need to learn. To his credit, Siemens recognized these would be issues and had thought about various checks and balances, usually involving opening the system to human intervention at certain stages, in order to mitigate the inherent error of computers deciding what's best for us.
There you go: a small window into the first of the TEDxEdmonton Salon Series. I didn't get a chance to cover all of the talks, but they all raised some great points and I'm excited to see what will come out of the next TEDxEdmonton event!