On Thursday 06 December 2007 12:16:19 Andy wrote:
> On 05/12/2007, Matthew Wood <[EMAIL PROTECTED]> wrote:
> > The delay is just a
> > small-team-working-on-/programmes-and-trying-to-fit-it-all-in thing.
>
> Any chance of explaining what the BBC actually have to do when someone
> says "let's open source Y"?
You never got an answer to this, so hopefully the following will be of
interest. Before I give an answer based on what I've seen, some caveats:
* I'm most definitely speaking from what I've seen, not on behalf of
the BBC. (I hardly think how projects get released is secret)
* Corollary: I'm saying what I've seen, not saying what's policy. As
you'll see there's scope for improvement. Any policy would trump this.
(I doubt a formal policy would be better though, a common best
practice might be better, dunno)
* I won't therefore have a complete view (Not _that_ bad though :)
I do tend to answer this question internally fairly often though.
* Opinion is likely to leak through - I'm an engineer not a reporter.
* If I'm wrong on things, someone will correct me. (Please)
I'm assuming that as well as interested in the specific answers around
this project (I'm interested too), that you're interested in this generally
as well. Hence this reply.
I've seen how around 1/2 the projects listed on the BBC's open source
page[1] went through this process, so perhaps it might be useful for me
to reply to this with a BBC hat on. I'll try and not report opinion here, but
I'm not a reporter, so excuse (and correct) any inaccuracy or bias below.
[1] http://www.bbc.co.uk/opensource/
(that list is also incomplete since I know of several projects which aren't
listed there)
The bottom line is, its different almost every single time - there is no one
process. (given every piece of software can have very different context, I'm
convinced that's not necessarily a bad idea. Not necessarily good, but not
necessarily bad either)
There first of all is (as far as I'm aware) no policy in favour or against
open source at the BBC either use, modification or origination.
That means decisions go back to first principles - does an engineer who thinks
something is worth released as open source feel they have the authority to
make that decision for themselves, or not?
For small things, they may well feel able to do so. There are some projects
listed on BBC opensource where the engineer just decided that they had the
right to release the code as open source, and so they did.
At the other extreme, as a pathological case. Then there's stuff where the
engineer didn't, but his/her immediate boss said "yes, that's fine". Then
there's the situation where neither the engineer nor the immediate boss feels
OK to say yes.
One project for example went to a boss, then 2 other managers, then 2 others,
then someone above them, then to a group of 12 managers, one of whom
said "no" because of a misunderstanding of *why*. That process of bouncing
round managers and resolving the why took around 7-9 months. The final sign
off, if I recall correctly with that project involved another 3 or 4
managers. The first group outside the department to use that code for
something useful? BBC Audio & Music Interactive. :-) (ie James's team :-)
Neither extreme is particularly unique.
For some parts of the BBC there's a form which you fill in, which has evolved
over time, which if it matches certain criteria you can release the code
as open source. In which case its a matter of "find the person who knows
where the form is and identify who signs it". (not as trivial as you might
think :-)
Then there's the stuff from working with standards bodies. The common
standing rule (at least in BBC Research) for standards bodies is that we
can contribute to them if they further the needs of the BBC[1]. So, if that
happens to include a workstrand on a reference implementation which happens
to have an open license, that's considered acceptable, or at least that's how
I had it explained to me.
Similarly, an open source project the BBC uses - like perl, python, apache,
etc is considered to be much the same as a standards body, except the
standard there is a piece of code[2]. (After all, conceptually, what's the
difference between a reference implementation of (say) MPEG, and ogg
vorbis aside from formality? (Not a hypothetical example: I've contributed to
ogg vorbis on behalf of the BBC regarding documenting how to use libvorbis) )
Clearly in both cases there has to be a clear justifiable reason for
contributing to either, but as long as there is, in BBC Research the
decision to engage with a standards body has normally been left at
the engineer level[3]. (time permitting)
[1,2,3] I've heard this from multiple people, so it's not an unusual
viewpoint/position at the BBC.
Incidentally, the BBC Charter Agreement is actually helpful in framing the
discusson when you hit a problematic case (in the new charter agreement,
this would be section 87 paragraph 4).
ie contribution to something pre-existing is much easier than origination. To
my mind that's quite sensible.
So, all in all, it varies. The higher up the food chain you are, the more
able you feel. I'm guessing in this case James just said "We're doing
this" :-) (But then he's high enough up, and there's a clear demand - both
of which help :)
Finally there's also "what about code developed by BBC people, but NOT on
BBC time, released as open source"? That's actually covered by this rule
from the BBC's terms on conflict of interest:
You are free to undertake certain types of work in your own time,
such as writing for publication (including software) and lecturing.
However, you should seek the permission of your manager if you
intend to use material or information associated with your work or
make specific reference to the BBC.
That specifically allows (due to the inclusion of software) staff to work on
open source projects. It probably also allows work on commercial projects
outside work as well, but I _really_ don't want to go there. (Not saying open
source can't be commercial, but open source in your own time is pretty
non-commercial normally :-)
Incidentally, it also produces a logical loophole, which I've not exploited,
but find entertaining, if you think about it long enough. (exercise for the
reader)
> It's normally a relatively simple for a small individual project
> (simply adding the appropriate license file and copyright text to each
> file).
Packaging is hugely underestimated. *hugely*
Not /vital/ for release, but really really important.
You could always make that a focus for invited contribution in initial
release :-)
> However I assume it is somewhat more tricky for a large
> organisation. Does this have to work it's way up to high management or
> are individual teams given freedom to make these decisions themselves?
See above. *everything* happens. Probably more than I know. The BBC has over
20,000 employees.
> Or are you busy removing all the derogatory/rude comments entered into
> the code?
> (Scarily this does happen in some places, even with open source code.)
There's a few easter eggs (as error strings) in Kamaelia's codebase.
(humourous I hope - they shouldn't actually get displayed, so if they are,
something that stands out is useful). The word "VOMIT" is used as an
encouraged tag for particularly artless code.
I also know of one case where the project was actually translated from
one language to another before release. Specifically translated from Ada
to something more friendly. That caused a bit of a delay :-) Among the
reasons there was to make it easier for people to contribute and to
make optimisations easier.
However everyone I've met at the BBC is too polite to do the things you
suggest :-)
> Will you be accepting bug reports and patches from people outside the
> BBC or is this a "release and forget" kind of thing? (Unfortunately I
> am not a Perl coder so there isn't much I can do).
As I say, not speaking for James's team.
Accepting patches is an overhead. Some teams find the benefit of accepting
patches and collaborating a net benefit, and some find it net-negative.
Generally speaking it varies. We all like hearing from people who use our
work, and even that is nice feedback. (heh, even hearing from people who
look at it and decide it's not useful is useful feedback, if they tell you
*why*) I know most projects like to have help. :-)
Incidentally, not all contribution has to be code.
For the record, Python people are always welcome to Kamaelia :-)
Actually so are people who's native language is something else, Kamaelia isn't
just intended to be just python based, it's meant to be a better way of
building software for the long term in any language (it's designed to make
concurrency natural - ie multicore stuff).
[ However, all work on Kamaelia currently happens on my own time since the
project isn't allocated any resource at work. That means the BBC isn't
accepting patches and help, it means it's just little old me. (The reason is
due to a resource crunch mid year this year) I'm hoping to integrate
Kamaelia back into my current day project at some point, but that depends
on how valid that would be, not my personal desire.
(I'm not fussed by this BTW - the BBC made a huge contribution by
committing resource to it as long as they did. And by resource it means
brainy challenging, hardworking people I was working with :-)
Kamaelia is however very much alive though. I'm planning on releasing
a bunch of sub-projects as standalone things whilst I'm on leave over
Christmas. (p2p whiteboarding, timeshifting, database modelling, greylisting
]
Trying to bring this back on topic to backstage, I'd be really interested in
hearing someone implement Ian Forrester's flow ideas in Kamaelia, since it
should be fairly trivial to do there BTW. That discussion may be more
suitable for the backstage-developers list or Kamaelia list though :)
Finally though, the single best (recent) contribution I've had is this "I'm
still using your greylisting server, works great". People rarely post to
mailing lists saying something works. You can boost the morale of every
open source project (not just BBC) that you use by simply saying
something similar (as long as its true :) :-)
Best Regards,
Michael.
--
Michael Sparks, Senior Research Engineer, BBC Future Media Research&Innovation
[EMAIL PROTECTED], Kamaelia Project Lead, http://kamaelia.sf.net/
All errors and opinions above are mine, not the BBC's. Corrections,
enhancements welcome.
-
Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
