The following content has been provided by the University of Erlangen-Nürnberg.

My pleasure, thank you.

So just to repeat everything that was said.

My name is Brian Forster.

I actually, I'm an alumni of FAU, so I used to go to university here and I actually had

some lectures in this very room.

I believe it was on network security, not quite sure.

I've been an open source contributor since 2001, well before my university time.

I started writing Perl-based parsers for IRC log files and then later web servers and all

sorts of other daemons and published those and got some feedback and essentially got

hooked on working with an open source community on all sorts of projects.

I started the CollegD project in 2005 while I was still a student here.

I was working for a company in Nürnberg at the time I started writing this and eventually

the company moved to also using this project, so that was another success and it felt great

and got me hooked on open source work.

Then I graduated in 2011 and right now I'm employed by Google and work as a site reliability

engineer.

Today, however, I'm talking to you at my private capacity as CollegD maintainer.

I just want to quickly mention CollegD and give a URL to this and a second open source

project called NoPing, which I also started, I don't remember when, and these two are very

different in scope and the amount of work I put in and the amount of attention they

get.

So, every once in a while I hope, if I don't forget, to contrast these two just because

they're both community open source projects and they are actually different.

I've done various one-off projects, I was just talking about one when I came in here

that reads the speed and connectivity information and number of users of ICE trains.

Just whenever I hack on something that seems cool and people might want to look at it or

like it, I'll just publish it because why not?

And I've done countless of contributions to other open source projects.

Whenever I see a bug, I dive in and I fix it.

A bit of background to CollegD, not that it's that important for the rest of the talk, but

just so you know the scope and what I'm referring to.

CollegD is a daemon that reads system metrics and application metrics and handles them in

some ways.

So, usually you send them to a central server and then you have some graphing infrastructure

that draws pretty graphs and dashboards and then your on-call personnel can look at those

graphs when a problem arises or you can use it for capacity planning as in how much room

do I have if I get a thousand more users, are we still good with the number of servers

that we have?

These sort of questions can be answered with the data that's collected.

There are hundreds of private and mostly corporate contributors to CollegD.

I checked before coming here and there were about 300 code contributions, so 300 individual

people contributing code to the project and there's probably an order of magnitude more

people who contributed by opening bug reports and giving feedback, word of mouth and whatever

else helped the project along.

We're currently three active maintainers as in people who A, have the keys to the castle

and can submit code and who accept contributions and look at code and answer bug reports and

that sort of stuff.

But the line is not as clear cut as you might think.

So that's CollegD and the kind of project that it is.