Why I shut down BBC backstage

BBC Backstage Meets the NW communities networking bash

George sent me a tweet saying how much Elizabeth Murdoch loved BBC Backstage, as she mentioned it in her speech to the Edinburgh TV Festival last year.

The BBC has been the market leader for building new relationships and services with creative’s from every sector. Be it the early ground breaking Backstage initiative for technology engineers.

Shes right and it does beg the question, why is there no more BBC Backstage?

I thought this was covered in the BBC Backstage ebook which was put together by the lovely Suw. But it looks like I may have been slightly mistaken. On top of this, I keep making reference to this blog post which I never seem to quite finish. So enough, its finished and out there for all to read…

First misconception: The BBC never shutdown BBC Backstage

Actually I did… When I first mentioned the possibility of closing down BBC Backstage to Adrian (my manager) he thought I had totally lost it. I remember a meeting with Adrian and Matthew (head of R&D) where I talked about shutting it down and I gave my reasoning which made soften the blow a little. I had thought long and hard about leaving BBC Backstage and passing it on to someone else younger and full of energy (I even had a number of names put forward to consider). But it didn’t make sense.

The problems with Backstage were not about who was running it but more about what was happening around it (as we will see in number 4)

Second misconception: The BBC sits on a ton of data.

The core of BBC Backstage was the backstage license which is founded on non-commercial reuse of data. This gave backstage the license to go around the BBC educating/persuading/convincing stakeholders about the benefits of open data at a time when data wasn’t a big thing. The problem is the data wasn’t ours. For example the Met Office would make the weather data available to the BBC under strict licensing. Deals were done for non-commercial use and it was always neigh impossible to reverse a deal without effecting the production side of the things.

Lots of people imagine most of Backstage was hacks. In actual fact lots of it was people experimenting.

Third misconception: Developers found new business models

This backs off the non-commercial problem. Because everything was under the non-commercial license, when things like the Apple App Store came along and offered developers clear ways to make money from their work. We had to shut down a lot of prototypes and tell people not to use BBC backstage data in there apps.

This was actually a issue from early on when Google Adsense, offered developers a nice way to make a small amount of money based on numbers of people who came to the site. It was argued that if developers made enough money to just cover the hosting of the prototype, we could turn a blind eye to. This wasn’t sustainable as it kept coming back to bite every once in a while. But it wasn’t till the App stores when the number of prototypes and services wanting to go commercial blew up.

Once developers learned it was actually against the terms and conditions, they naturally moved on to other platforms.  We did talk to BBC Worldwide many times about working together but it just wasn’t to be.

Forth misconception: The Open Data Revolution passed it by

Backstage had a hand in getting this revolution going in the UK and beyond. 7 years later, we had influenced everyone from other companies to the government. We were there right at the start of this revolution and fundamentally changed the BBC’s thinking about data. However it was clear this was just the start and as a part of BBC R&D, it was right to move on and have the same impact in another emerging area. The developer network part of Backstage was tricky to balance with the push to drive forward.

We did think about splitting it off and working in partnership with others who were later to the scene but it just didn’t quite happen and in the era of cost cutting and doing the things which really have an impact for our audiences it was harder to justify.

Fifth misconception: It was all about DRM and the BBC wanted rid

Looking at the mailing list, its easy to imagine it being all about DRM and not a lot else. But in actual fact while the DRM debates rages on, there were lots of people creating and making lots of prototypes. Lots of them were documented on the website but there were some which were so illegal there was no way I could put them anywhere public. Those were more of a look what we could do…

Even though they were much more black/grey around the licensing terms, they drove the imagination and clearly got a number of us thinking what if…? One such example is the widely talked about blast from the past called Panadora PVR (now called Promise.TV) which lead to Tom Loosemore’s talk at Etech 2007, the Edinburgh TV unfestival and the building of the infamous BBC Redux.

The BBC gained a lot from having the debate and being rather open about it all.

Sixth misconception: There was no money or love for BBC Backstage

This is somewhat true and false. Yes it became more difficult to justify and we had gone through quite a difficult patch, while losing some key people to project. On top of that we had a new head of Future Media (Erik Huggers), moved into BBC R&D and was shifting the project up to the north of England to fit in with BBC’s increasing push to solve the London and South East bias.

Everything was changing and everytime we took BBC Backstage in a different direction, there was push back from the dedicated community. To me this is the way of the world (forever changing) but it certainly makes funding such projects difficult when you want a 3-5 year plan.

There was much love for BBC Backstage from Future Media and other departments in the BBC, there was lots of talk about setting up other Backstages in different areas as a outreach project alone it hit audiences the BBC was not so good at having conversations with. The formula was repeatable but should it be? We could have done Mashed all over the UK but was that a good idea? I certainly didn’t think so and ultimately my thoughts about driving forward were correct.

Seventh misconception: We ran out of steam

Ok this might be true to a certain extent. But not from the lack of trying… You only have to look at the new things I’ve been working on since, including Channelography, Perceptive Media, etc. There is still fire in myself and I still have a lot to give… During that time, I will admit I was well over worked and I was being contacted by many people on the off chance just because I was out in the open. This certainly slowed down daily looking through BBC emails. Hence why I now have a another BBC email.

Ultimately I want to thank everyone who has been involved in BBC Backstage in the past (too many to name). The decision was made under a ton of stress on my part but I felt I was making the correct decision for everyone including the founders, the BBC and the community. Then and even now. I mean can you imagine BBC Backstage in 2013!?

Things need to end (such as BBC Backstage, Innovation Labs, etc) for others to spark, grow and mature like BBC Connected Studio.

 

Reconnecting with half the memories

hajimemashite watashin wa. Ian desu. dozo yoroshiku

Its great looking through my Twitter archive/dump but its frustrating that I can only read half of the conversation.

Funny looking back at this tweet as it was less than a week before I had my brush with death

6 May 10
These early morning meetings are killing me, wondering what people would say if I started setting meetings for 6pm and 7pm?

Yes just imagine… Anyway I can clearly see the gap in my tweeting From 7th May 2010 to June 9th 2010. Not a single tweet…! I also noticed theres no Direct messages in the archive so I can see… Which is a good and bad thing I guess?

Anyway enough doom and gloom…

Here’s is that classic moment which I’ve used to talk about how great open sharing can be/or how twitter is better than facebook.

From 4th January 2009…

Unfortunately you will need to read it from the bottom upwards

Although you know what happens, so it doesn’t really matter 🙂


“thank you but…” passing the card back.”I have a boyfriend, he’s picking me up from the station” so no joy but thanks twitterverse View on Twitter

so I gave her the card and smiled. she looked at it read it with richards jp on one side and my contacts on the other and said…. View on Twitter

Ok headphones are off and shes packing up. Here comes my moment. Geez  View on Twitter

@richardsproject: Ok Richard wrote it, the card is ready. I just need to know what it says View on Twitter

At Stockport View on Twitter

So i was planning to offer her one of my kitkats but i like the card thing. if Richard tells me what it says  View on Twitter

@richardsproject: Tell me what it says and i’ll do it View on Twitter

@sheilaellen: Nope only 10mins left View on Twitter

@JeniT: Ummm like what? View on Twitter

@billt: Ok now i’m laughing out loud, thanks Bill. Think she is running Windows too actually. But shes watching a film View on Twitter

Just passed Mansfield so not long till we get to Manchester View on Twitter

@cisnky: Now that would be good. But how do I start that conversation 🙂 Geez I wonder what @tommorris makes of all of this View on Twitter

@davemee: The twitterverse is my strategy, come on people I got 30mins left to make a good impression and type up my blog entries View on Twitter

@sheilaellen: Shes got headphones on, so that won’t work View on Twitter

Sitting opposite a stunning Japanese lady with a oversized acer laptop. Playing footsie under the table but no joy… View on Twitter

Public 2.0: The era of personal data openness

I was in London Thursday for the Public 2.0 conference, which the guys behind the Data Art  project put together. It was a nicely put together conference with a mix of speakers and topics.
I kicked off the day with my presentation titled The era of personal data openness.
When I was approached about doing a presentation for the data art conference. I wasn’t sure which angle to take. After a few thoughts, I decided to contact the data art guys and see what they were exactly after. After a brief chat, I decided to take the more interesting path in this presentation
The premise of the presentation is Open data from organisations like the government, companies is interesting and the movement around this has finally sunk in. There wasn’t a single government proposed agenda last year which didn’t include something about releasing more open data. And every startup and online business is building APIs, so they can take advantage of the overwhelming power of the rich ecosystem of developers, hackers and early adopters. But I’ve noticed a increase in tools and systems to take advantage of our own data and the data we generate everyday.
I was tracking this very much from the sidelines and had not found a decent way of explaining the topic of self documentation. That was till I had lunch with Rain Ashford.
We talked through a bunch of stuff but got talking about my presentation which I was due to give next day. And after describing the premise like I am now. She said it sounds a lot like Quantified Self
Bingo! Having never heard of the movement, it instantly made sense and further research clarified everything.
Quantified Self is the Era of personal Data Openness….
Its also worth noting Walter De Brouwer’s presentation at Thinking Digital also had some influence but I forgot to mention it. Two links from that session http://curetogether.com & www.patientslikeme.com all fit perfectly…

Openness in data formats

Me and Tantek

Tantek wrote this thought provoking entry about data formats and openness. Which I can't help but kind of agree on and disagree on. So first his entry.

  1. ASCII is dependable. Project Gutenberg insists on publishing their e-books as plain ASCII text as Mark Pilgrim noted, and their reasons are solid.
  2. Compatible XHTML is now also dependable. In the 15+ years since its public introduction, I believe that HTML has established itself sufficiently prominently worldwide that I feel quite comfortable declaring that HTML will be accepted to be as reliable as ASCII in coming years. In particular, authoring what I like to call Compatible XHTML, that is, valid XHTML 1.0 strict that conforms to Appendix C, is IMHO the way to author HTML that will have longevity as good as ASCII. Note that files in most file systems have no sense of “MIME-type”, thus the winged-mythological-creatures-on-the-head-of-a-pin style arguments about text/html vs. application/xhtml+xml that are often used to discredit either HTML or XHTML (or both) are irrelevant for the most common case of keeping archives of files in file systems.
  3. Plain old XML (POX) formats in the long run are no better than proprietary binary formats. XML, both in technology and as a “technical culture” is too biased towards Tower of Babel outcomes. I've spoken on this many times, but in short, the culture surrounding XML, especially the unquestioned faith in namespaces and misplaced assumed requirement thereof, leads to (has already lead to) Tower of Babel style interoperability failures. As this is a cultural bias (whether intentional or not) built into the very foundations of XML, I don't think it can be saved. There may be a few XML formats that survive and converge sufficiently to be dependable (maybe RSS, maybe Atom), but for now XHTML is IMHO the only longerm reliable XML format, and that has more to do with it being based on HTML than it being XML.
  4. Formats that are smaller (e.g. define fewer terms) tend to be more reliable.
  5. Formats that are simpler (e.g. define fewer restrictions/rules for publishers) tend to be more reliable.
  6. Formats that are more compatible with existing reliable formats tend to be more reliable, e.g. HTML worked well with existing systems that supported “plain text” (AKA ASCII)
  7. Formats that are easier to use, i.e. publish, and more immediately useful, rapidly become widely adopted, and thus become reliable as a breadth of software and services catches up with a breadth of published data in those formats.

The microformats principles were based on these observations. Now this doesn't mean I think microformats will replace existing reliable formats. Not at all. For example, I feel quite confident storing files in the following formats:

  • ASCII / “plain text” / .txt / (UTF8 only if necessary)
  • mbox
  • X)HTML
  • JPEG
  • PNG
  • WAV
  • MP3
  • MPEG

So my take on Tantek's thoughts.

Plain old XML (POX) formats in the long run are no better than proprietary binary formats. See I take issue with this, I understand what Tantek is getting at but I would say plain xml without a schema isn't leaning towards the Tower of Babel. And like Tantek already mentioned RSS and ATOM are pretty close to the non-tower of babel direction. I would also add FOAF and OPML to the list. I would love for SVG to also be included in this but alas its not. Formats that are smaller (e.g. define fewer terms) tend to be more reliable. Good point, hence why things should be broken down like how XHTML and SVG got Modularization.

My list of formats are slightly different too.

  • XHTML (Unicode)
  • XML (Unicode)
  • JPEG
  • PNG
  • MPEG3 audio
  • MPEG4 video
  • WAVE
  • SVG

Comments [Comments]
Trackbacks [0]