 So, so, all right, so, so I've done a bunch of academic work and I'm an academic now and have been for a lot of the recent past and I tend to focus on the types of things that I'm involved in, like the WM project and like freedom of the search software. And as it turns out, a lot of other people, both within the WM community and in many cases outside of the WM community have looked at the WM project as a source of inspiration and as a source of knowledge about the way that large communities, large voluntary organizations, hackers, et cetera, et cetera, work. So, so, and they've come to a lot of conclusions that in many cases they believe apply to a variety of other types of organizations that apply to other large voluntary projects, other free software projects, et cetera. And one thing that has frustrated me a little bit about this is that while they've done, while there has been a huge amount of research that has used Debian as the sort of the object, the ethnographic sample in terms of ethnography and the sample in a whole set of other things, other fields. In the vast majority of cases, this information never makes it back to Debian. So, so my thought with this talk is why don't we try to, why don't I try to close the loop? Why don't I go out and look at a bunch of groups and individuals, many of them academics but not all of them, who are looking at the Debian project for inspiration and making conclusions that they believe apply more broadly. And then tell Debian about them, right? Because if they apply to other projects, because if the research from Debian applies to other projects, it almost certainly applies to Debian, right? So what is it that we can learn from looking at people studying us? That's sort of the idea. So the structure of this is going to be a lot less like one talk and a lot more like, you know, 10 or 11 lightning talks. Let's see. I didn't have a clock here. So I should time myself strictly. So great, so that I can, in fact, do this. So I'm going to try to, in most cases, talk less than four minutes on any particular paper or subject. And I'll put up what I'll, in many cases, all I'll show on the slide is just a reference so that you can go and look this stuff up and do it. But I'll try to learn more about it. But in many cases, the language that's used, the methodology that's used are ones that are not familiar to the pre-sof or to the Debian project, which is the reason why many of the people who do this work, even though many of the people I say, you know, the world outside Debian, even though in several of these cases, the people doing the research or writing things up are actually from the Debian project or around here, they're often presented in terms that are not the ones that would be as easily understandable. So I'll try to do the birds eye view. So without further ado, since I'm on a strict schedule, I will rush forward. So the first group I'm going to talk about is software engineers. And in particular, people who like to study software engineering. In particular, a lot of these people are academics. Many of them work in business schools or in this sort of, in this area called organizational studies. They look and see how organizations work. And in many cases, they look and see how software is produced and how people might produce software better. And through software in particular, and they come up with a lot of descriptions for the way things work. And as it turns out, you look at the pre-software community and they're completely unable to explain why it works. They say, well, you need a manager or you need a manager. It's a whole set of things and they look at, wow, wow, that's totally not going around here. So this has been a really interesting point of research for a lot of people because it's questions that are difficult to understand. And many people have decided to study Debian. So one group I'll talk about is this group in Madrid who was presented a little bit earlier on Sunday by Javier who presented a bit of their work. But one of the things that this group sort of headed by Jesus González-Parajona has spent a lot of time on counting and how to look at how much stuff is in there. So I'm not going to spend as much time on this as I could because this has already been discussed a little bit in depth. But the major question behind a lot of this stuff is statistics gathering and how big and how economically important as a result is free software. So this is actually a really interesting question. A lot of people want to know how hard it would be to produce something like Edge, right? And so they do things like count lines of code, count the number of times that everything goes into it. And as it turns out, because it's this collection of everything and this is a sort of theme that I'll come back and turns out to be a really excellent place to start because it's sort of this snapshot of free software universe. So there was originally this paper written by someone named David Wheeler who looked at Red Hat and concluded that it was worth a giga buck or I guess 10 to the billion dollars. And then this group said, well, actually, looking at Red Hat is much smaller than that because we can look at the Demian Project, which is much bigger. And they've gone through a whole set of things to determine not just first how big it is, but then also how many people are contributing to this and how many things are sort of connected to each other. And as a result, I mean, this research is primarily descriptive so we all have a sense. But it's interesting stuff because you can get an idea for just how many millions and millions and millions of hours have gone into producing the stuff that we have right there and actually it's really quite staggering. I guess the benefit that we can take is that even though we sometimes can be a little frustrated by the sort of swelling size of the archive, at least useful to some people. There's another paper that I looked at which was this idea of trying to do sampling, which was done by a group in Zurich, and here's a link to the paper, but the idea is that they did sort of a similar argument and they were trying to look at the free software community in general, but their question was a little bit different. They wanted to do sampling. They wanted to look at creating useful samples of the free software community. And it turns out people do this a lot and what they've historically done is look at SourceForge. SourceForge has like, I don't know, tens of thousands of projects, something like 70,000 projects, but there are lots of problems with it. One of the problems is that most of the projects in SourceForge have failed. The number of projects that have never had an upload, very high, never done a release. The number of projects that, and there's other ones, it's also incredibly incomplete. The vast majority of the largest and most important projects, you know, GCC, E-Maximum, the name of the project, it's probably not posted at SourceForge. So as a result we have this, it's useful in that there's this huge collection of pieces of software, but it's not useful in that most of the time they're not very useful. Or they're not the ones that are most used or they're not the ones that are most downloaded. So if you're interested in, so in this way it creates a very incomplete sample, you know, instep's Debian, right? And they argue that Debian is better suited to sampling because it avoids biases and it also has unique information that's only available in this integrated environment, right? So SourceForge, sure, it describes a few things about the software, but Debian has a whole ton of extra information, dependency information, maintainers, people you can ask about what's going on in there. Something that in many cases, SourceForge doesn't provide. This group is particularly, I think this group is particularly interested in this idea of reuse. So they want to know how often are pieces of code reuse and does this happen more often in the free software world? It seems like it should. And this is a question that's reasonably difficult to answer in SourceForge but it's really easy to answer in Debian because we've got dependency information that describes every library that's used from anywhere else. So I'm sure it doesn't stop the people that have cut and past new diff into their application, the hundred times that's happened. But it's a pretty good start. So it turns out that many people studying free software first need to assemble a sort of comprehensive list. Debian provides that list, right? They've got information of different versions over time. We've got guidelines and standards for including that information. Something that SourceForge for the most part doesn't because any idiot who wants to create a SourceForge project can. But getting a project in Debian is, I don't know, maybe slightly harder because at least one person needs to use it. Or needs to maintain it, not use it, although that might be a nice rule. There are also information on sections and tags, right? Ten tags. Awesome. Huge amount of information added by humans about packages that are in there. Great information. It's really hard to get out of free form descriptions in SourceForge. There's also these contact people that I mentioned. And there's also the fact that Debian is just way more complete. They said that they sampled 157 random libraries in the Debian project and then went to check to see how that stacked up professionally. Only 39% of those projects posted in... 39% of the sampling projects were available had fresh news pages. Only 58% had fresh news pages and only 39% were on SourceForge or Tigris, or RubyOS, or any of these other sort of hosting things. So in this sense Debian is a snapshot of all that's sort of out there. The little bit that's nice is that Debian for the most part only contains successful projects. At least if successful means they've done at least one release, something that SourceForge doesn't have. So that's sort of the cool little thing. All right. It's time for that. Here's one that is someone who's not so outside the Debian project. Barton Nicole Meyer, of course, our former fearless leader spent a huge amount of time in the next few years. He's the host of some other papers he wrote on Debian. But a few. But what's interesting is that because most of his work is focused on writing to this sort of audience and software engineering, all of it is always accessible or visible in the project. But he's made some really interesting conclusions by looking at it. This is a dissertation which I read in the last week and I actually enjoyed. I hope my own thesis was entertaining. He talked a lot about, one of the questions that he asked was that can volunteer teams with their high volatility regarding project collaborations ensure consistent levels of quality in their output. And if they do, how do we do it? What are some techniques that we can do? And he looked particularly on the role that release management and different styles of release management plays. Something that maybe we have learned a little bit about and could stand to learn a little bit about as well. So it begins with this sort of discussion of quality management and ends with a longer discussion of release management and it's a seven in-depth case studies. Among those, Depegan is the one that he's most familiar with probably, but it looks like an online project and the one he's currently on a variety of other places. He does mostly qualitative sort of analysis meaning that he does a lot of interviews. He follows the project over two years. He looks at mailing lists, documents, direct observations, so on and so forth. His conclusions are really, are really interesting. What he ends up doing is he ends up coming out and arguing very strongly for time-based release schedules in the context of voluntary projects in particular. This is something that we sort of seen in time-based releases that sort of worked, but Kanom, of course, is a very different type of project and that they have a lot of people paying to work on it. But he says looking at a variety of projects that time-based releases are absolutely essential because there's a lack of planning, which leads to problems, which such as delays and quality. And it's especially important for volunteers because of two factors that he says in time-based releases and interviews. Regularity, the first one, meaning that you have a specific interval that allows projects to create sort of a reference point that contributes to what kind of changes other members of the project have made and that contributes to familiarity with the release process and the second thing is schedules. And so having time-based releases without firm schedules is shown to be totally ineffective. So firm schedules and ones that are stuck to in the use and time-like features as the orientation for the release and as a result, planning becomes possible in these voluntary projects. And he describes sort of important deadlines and methods for tracking dependency information and so on and so forth. So anyone who's at all interested in releasing or in the release team I absolutely suggest reading his dissertation because he has some really great stuff and some interesting conclusion. All right, okay, so here's the next one. There's some of the other papers that he's written. These are just the ones I mean, he's published lots of other names in the last few years as well, so he's been busy. And unfortunately it wasn't able to talk. Here's one that we did a few years ago that Martin did it and I had this position of helping out a little bit on. But I sort of realized that we hadn't ever really communicated this to the Debbie Projects as well. I'll do that now. The basic idea was that we were sort of asking about what are the problems and solutions that are associated with voluntary labor and with the role of individuals in free software projects. And of course most of us should be familiar with the Debbie Project with some of the problems there. People are very busy, people go away, people block things, you know, people do NMUs which have developed over a period of time this sort of stigma. And as a result they will get very upset. And we looked at the role of group-maintenorship which also has a series of problems. If you have team-maintenorship one thing that we found by looking at doing a bit of analysis was that people are much more willing to if you've got a group repository people are much more willing to do commits than they would otherwise. They're willing to make changes. But there's the group in general is much less likely to do a release than the total than any individuals. Meaning that if you've got a given project we can call it a convene G-Lib C is a great example. G-Lib C went from being maintained by an individual to being maintained by a group. There became much, much more work in G-Lib C and much less frequent releases. Because while more people were empowered to make changes no one felt empowered enough to speak for the entire group and make that release. So that's an interesting sort of issue. One thing that Debian has done which a lot of people have looked to is having team-maintenorship and then explicit uploaders group of people who are explicitly empowered. Nothing is different in that the team is still making the upload. But people because their name is in a place they feel more empowered to make the decision for the group. And there's also just the matter of whether a group can be conscious of this. And if people realize this is a problem they can be more willing to communicate about this and plan and do this as well. So there's a simple thing. Paper is online very as well. And I believe I have two more in the software engineering thing. I've got, Martin is working on some more stuff as well if you want to do a two-minute sort of thing. Yeah, Bobby, I can do one more if you want. Do you want to talk? I'll do one more. So here's one more. This is one that I read and thought was super interesting. Martin of course, because he's done everything else that did this. But this was a quantitative analysis of the role of volunteers working at a deputy project in particular with the idea that there'd be confusions for a variety of places. They asked a bunch of questions and they had really interesting answers to a variety of these. The question they asked was, one thing they looked at was the number of maintainers. So the idea and the conclusion that they came to was that the number of maintainers over the last most of the life of the deputy project has been growing pretty consistently at about 35% a year. They also looked at interesting to know they also looked at team maintainership and what they found was that in the period they looked at connections between 2.0 and I guess the release of Sarge or maybe even Woody, they found that there was this increase from 14 packages that were team maintained or about 1% of the archive, 600 which is about 7% of the archive in about 6 years. And that's not including the and this effect shows that even if you don't include the QA team which is a little bit different because they maintain a lot of packages that have been ordered. So we've seen this sort of in part because of people finding out that team maintainership is a good thing of working, there's been this massive growth in team maintainership. They also did a lot of tracking of individual maintainers. So they looked at okay, I think 2.0 there are 216 contributors people who maintain packages in the distribution and they look at 2004 and only 55% of those before made and if you look at the life of the deputy project if I'm very consistently at any point there's a half life of about 7.5 years, 90 months for people to persist meaning that on average devian developers we take a group of devian developers and all of the people who are maintaining packages right now in 8 years or in 90 months only 50% of us are going to still be active in maintaining packages. I mean perhaps the people who come to DevCon are less likely because we've sort of established something but this is really interesting. So there's this idea that people are always upset and people are losing but maybe this is something that's maybe this is bad maybe there's things you want to do to change this but maybe it's not bad because it's been with us for a long time maybe people aren't leaving to go to other things because they hate devian maybe they're just leaving because people sort of burn out. What they also saw was that burnout was something that happened basically on or off meaning that if someone a series of packages you know one time 7 years later they weren't likely to be maintaining less packages they were likely to be either maintaining more packages or basically not they either disengaged or increased maybe or a state level in terms of their contributions also interesting to know maintainers who leave so at least people are leaving 60% of packages are adopted pretty high actually most people when they leave most packages are picked up is not adopted and falls out of release the chance of it being picked up again very low it's sort of also they also created a they had some interesting ideas about a maturing model for determining which packages were likely to be picked up or not something that we might actually be able to model pretty simply in the project which might be really really useful they also sort of established an experience and importance there was this correlation so that packages that were more likely to be used by more people tended to be maintained by people with more experience probably a good thing happening naturally I guess we can pat ourselves on the back on that another thing that they know which I think is actually very useful is that the Debian project is not adding maintainers as fast as it's adding packages so as a result the ratio of maintainers to packages is increasing in time this actually may show a potential problem so people sometimes think oh no and I'll talk a little bit more about this when I look at some other research people are worried that there are too many Debian developers they're not good enough but in fact that may actually be not true Debian developers is now responsible for on average more packages than they were last year which was more than a year before in fact we should probably be adding people more quickly we should have a new maintainer process the goal should not be to keep people out in so far as that's the goal of the new maintainer process some people have suggested that I've been one of the people that have suggested that we should work on getting people in and encouraging them to make contributions even more easily because we're actually creating more work for ourselves and we're burning and the result of that maybe we don't have numbers for this burning people out and increasing that number so entry results before we move on to the next sort of section I'll let... yeah I don't know off my head but the paper is right there you can look in there there was a question that Joey asked how sponsors were taking into account in here and I said I didn't know I don't recall reading in the paper but you can look there and of course we can ask Martin and other people as well just quickly we're currently discussing actually the Debian maintainer status to answer that question of yours so in the future we might have actually Debian maintainers who can upload their own packages without having to go through the entire process but there's news on the announcement of Debian agents from yesterday hold on let's get on our side of the question can you define burnout burnout means people that were maintaining packages that stopped maintaining packages so we don't know if it's burnout or if they just sort of moved on to other things I'm using burnout in a very sort of technical way it just means people moved on right it's not I'm not I'm not I'm not there are no psychologists in this team this is not a medical condition to burnout there's no it's not these people hate Debian they might just you know I used to like you know I like trains fine okay alright I'm going to give a little bit of an overview of the research that I'm doing in addition to the talk this morning but some of you haven't been able to make that I assume that so what I'm doing is I'm looking at method diffusion and large open source projects and that means if there is a new tool, a new workflow or a new something that could potentially improve I know what conditions our volunteers are going to adopt it so what I'm doing is I'm looking at tools that we have previously adopted in Debian stuff like Dev Helper which is definitely one of the primary tools that I'm looking at and also many others that have been adopted or not and I'm just going to try and figure out which ones of these characteristics and actually let or suggest that this adoption was a success like was there documentation available was the maintainer, quick get fixing bucks and so on and so forth there's a number of these characteristics and in my research I'm trying to find out where which ones of those are the most relevant and well this is all about like people working from outside to Debian and using Debian as part of the research I'm inside Debian so I'm not really in that first category but I definitely do believe that should I manage to come up with a number of characteristics that define when a diffusion is going to be successful then that's going to have a impact on open source and possibly even on other fields including organizational and management science so this is when I started this project I was going to look at various different projects, Debian, Sloan and Git and so on and so forth but in the end now I'm limiting myself down to Debian only not only because it's already quite a nightmare to get all this data but also because Debian is a closed system and I can actually do much better research within Debian that can then be ported to the outside and if I would focus like on other projects at the same time doing things like I mean in films like comparing apples and oranges in some way so I'm just limiting myself down to Debian does that answer your questions? Okay and alright social scientists not that no one there told me that social science a lot of the scientists are social so the first thing I want to talk about is this interesting paper on managing the boundary of an open project which focused a vast majority of the paper focused on Debian and in particular on the Debian new maintainer process it looked at it sort of touched a nice little bit of my heart I applied to become a Debian maintainer right before the process changed and then I put in the wrong email address in the back at and I didn't get the mail back and then had to go through the I was one of the first people to go through the new maintainer process because I just put in the wrong address and didn't notice until why haven't I heard anything three months later so I was sort of watching this entire process when it happened so it was a pretty interesting sort of thing so I looked at the creation of the new maintainer process there was this period where you basically I mean it was a little bit more complex than just emailing someone saying aye aye aye social contract thumbs up I'm good don't worry about it and then moved to this process where people where there was this whole process by which people were added to the project and then one of the decisions that there were a couple of decisions that were made there was a group of people who became the new maintainer committee which now is the group of applications all the people who do all the AMs and these are the people who for the most part decided for the project what the requirements were going to be for someone joining the project really interesting sort of a really interesting process and they did was they looked at using things like the web of trust what the difference is what about those people and one thing they found out was that the best predictor for whether someone a debbie in it all would become one of the people who decided what the new maintainer process was more than what packages they maintained more than anything else was how many signatures they had on their P as it turns out had more than 5 connections were 65% more likely to become one of the people who decided what to do this and the result was very soon that having strong debbie signatures is something we care about okay sure but there was tenure in fact had a negative effect new members were much more likely to want to participate than people who had been there for a long time the result being that what happened was this creation and this is still true roughly with the new maintainer process people who are more recent developers are more likely to be participating in this process than maintainers who have been here for a long time which means that there's this process by which people who and and there's this fact that as the system became stricter and it sort of created this little loop where people were asked lots of strict questions the people who went through there and who liked the idea that this was and became the people who then came back and asked increasingly strict questions and as a result the new maintainer process has gotten increasingly difficult and you can look at this and this paper looks at the way that it gets increasingly difficult I mean it used to be even since the new maintainer process the number of questions asked, the number of hours spent leave this now I mean I can do my own sort of editorializing which about this I mean I told a story once someone was holding a story about how scientists had taken rats and run them through a maze trying to make them smarter and smarter and they had these methods really good at running through a maze but it turned out that they weren't actually getting smarter they were just partially deaf and partially blind they were they couldn't get distracted and so my joke was maybe the new maintainer process by having people answer lots and lots of very long emails is training people for something other than what we really want and playing wars of the future are something to worry about but in any case I mean that's sort of a joke only sort of but it's interesting to look at the process that's brought us to where we are today and the values that have sort of played into this based on the self-selection of people who are participating in the process and I think that I found this it's about 50 pages but it's, you know, it's double-spaced and it's actually a really quick read and I would recommend it to anyone who's interested in the new maintainer process and the way that these processes have been created and the way that that's framing the idea of what a deafening developer is or who a deafening developer is these days and the way that it's sort of having this process going forward so the yellow can I put you on? okay so this is our resident resident anthropologist the old woman so yeah you can sit in my chair I'll be more than 5 or 6 minutes so a lot of people know me, I'm a yellow Coleman but I thought I would give a little bit of an overview of what I've done and where I'm going so and how it pertains to Debbie and although I have to say what Mako has mostly talked about is not in my format because I'm an anthropologist and we don't really have findings but still I hope to make a little bit clearer what I do so basically I think in terms of my work I wrote a dissertation in 2005 that I had worked on since 2001 and it explored the links between free software ethics and the liberal tradition and by liberalism usually when I say that word people especially from Europe have a small heart attack because they cannot talk about the liberal party and they're like no I don't believe or associate with that and by liberalism I don't mean a political party that's either the United States or in Europe or is something that has to do only with let's just say the American Civil Liberties Union but instead has to do with a certain type of philosophy which relates to questions of freedom meritocracy, autonomy, free speech and property and so what I'm interested in as an anthropologist is to make sensible how it is computer hackers and free software people integrate the liberal tradition and change it through software projects, legal codes and how the transformations within free software then changes liberalism in a broader capacity so basically one of the things that a lot of social scientists have worked on in free software is the question of motivation why do free software developers want to do X, Y and Z and for me that's an interesting question that's been well researched but it's not the one that interests me instead what I want to get at is what sorts of transformations happen within the field of free software so someone starts as a little developer who joins Debian and goes through the new maintainer process learns a lot about the law and also gets involved with a lot of conflicts and flame wars so the paper that I have up here which is available on social science research network, you just do a search for Gabrielle Coleman in SSR and it'll come up, looks at three different ethical moments by which in a sense hackers become hackers one of which is the new maintainer process which draws on an article that Mako and I wrote together the other one is legal pedagogy so what you learn through learning the law and then finally through crisis and the crisis I look at was the Vancouver meeting that happened a couple years ago and this is the strongest chapter in my dissertation and the one I'm most proud of because I have a theory about the cabal and why people joke about it and how it serves to smooth over contradictions and I know a number of people have read it but I would really really love it and people did read it because right now I'm transitioning into the current Fiela I'm working on transforming my dissertation into a book and this is obviously going to be there and so any sort of feedback I get would be really wonderful and excellent you know the introduction is a little heavy but I promise that as you go through it it should be a little bit more understandable and certainly much more understandable than certain other of my dissertation chapters so that was a lot so as I mentioned I'm working on a book which is called The Red it's called a Recoding Liberal Freedom Hacker Pleasure and the Ethics of Lean Open Source Software so basically an ethnography the purpose of it in this sense is like a two-way street on the one hand a lot of people out there don't know about the world of free software computer hackers there's a lot of weird esoteric things that happen in this world so part of the point of ethnography is to make that sensible and intelligible to non hacker people why do they do this, why do they love to create technology, why do the social codes that bind them together, what's the function of a hacker conference in a sense how does it function to cement virtual communities at the same time while there's a lot of computer hacking that is only relevant to this world people would basically find very strange because they've just never experienced it there's a lot about computer hacking that also relates to the wider culture and society in which it sits in and this again is where the liberal stuff comes in, commitments to free speech and meritocracy so you know we're at Edinburgh University of Edinburgh which of course is an education system that implements the meritocracy so I'm interested in also revealing how it is that software and computer hackers is a site whereby liberal ideas are reformulated and in terms of sort of practical elements of this, I mean I sort of joke that there's none but I do think there's some, I mean one of which is maybe just a little bit of perspective that's one thing the second thing in a sense that I think is really interesting with Debian is that they implement different modes of governance and in that paper I talk about I look at meritocracy ad hypocrisy as well as a commitment to democracy and in a sense there's these different modes of governments because there's different commitments, democracy is a certain commitment to populism and meritocracy is to who does the best work and so by writing this I hope it does give a sort of perspective on possible solutions to the conflicts between these different modes of governance and then the second thing is which Mako has mentioned is the question of scaling so Debian has gone from something very small which was almost like a village, everyone knew each other to in a sense something much more like a nation where you have an identification but not everyone knows everyone and they have to integrate certain solutions to make sure that you can scale effectively so I write about that and I want to continue working on that and then finally in terms of more sort of broader practical implications in my work if you follow the law a lot which I happen to do after read a lot of legal cases for my work copyright and patenting intellectual property cases there's an interesting move where a lot of the debates posits behavior based on assumptions about natural behavior that people automatically want to X, Y and Z and there's been a very nice move in the last 20 years in the law where there's been an integration of not what people what we think people do but what they actually do and so and people like Lawrence Lessig and Yochai Benkler lawyers and also write Amici Breeze for legal cases are more and more turning to live examples so I hope that my work can contribute to that so then finally people ask me so yellow what are you doing here are you still doing research are you just hanging out you know what's going to happen in the future and I've been very I'm about to wrap up very lucky that I got a real job which I'll be starting in September and so I will continue with this research project but I also have an additional one which is on patient activism and psychiatry and if people are interested they can find me because there are connections with this project but I do you know I do continue in this world I'll be involved for 20 years unless I get fired which is always a chance and so I plan to continue doing work and one of the next questions I would like to research is under what conditions people get kicked out of Devian I've witnessed one last year very dramatically and there's obviously been a recent one and I think that sort of analyzing and writing about this process would be a maybe positive thing I mean the big problem is I don't have access to private which is where a lot of this stuff happens anyways so that's what I'm going to talk about and you know people can always find me if they have other questions anybody you think they might get thrown out of private or get kicked out of the project I'll talk to Beal so Beal jokes a lot of this stuff isn't as a factor in patients but I guess I respectfully that I think that I've learned although it's harder to point to things like yes you see there's this percentage of things happening this way we need to act in this different way I think that a lot of the anthropological work on the Devian project puts me when I read it it puts me in a perspective where it gives me the perspective to do a type of critical sort of analysis of the type of behaviors and sort of social systems that we're working in that ultimately leads to to me making arguments for the type of changes or reevaluating a lot of things that I might otherwise take for granted so I mean I appreciate that alright just academics and so I'll quickly now that I've got two minutes the good news is this is mostly over there's a few other things I want to talk about so as it turns out it's not just academics who are interested there are a lot of lawyers and a lot of people who write licenses have looked to Devian because you know Devian legal and the Devian project as a whole through things like the new maintainer process there's just people to think about licenses more than all those other people on her so as it turns out a lot of people look at it so we all know about the I won't even have to say it I spent more of my life thinking about this particular license than I imagined I ever would Devian legal in particular criticized the GFDL and eventually got it was non-free for a variety of things that it had done the biggest of these the most important or most egregious was the fact that it had invariant sections and Devian took on Devian legal in particular took on you know Richie Stallman and the Free Socket Foundation in a big argument about what free was or wasn't and as it turns out it seems like they kind of won we won even so far as there was the FSF said okay we really respect you on this let's talk about it and created a committee it was myself and Darren Strong who spent a lot of time talking about bits and pieces and negotiating for something and ultimately there's a new draft of the GFDL which you can check out now as part of this process for the new GDL and it is so much better and as it turns out it does not have invariant sections and fixes majority of the other issues with the license we had the Devian project while people while you hear these calls they will sort of out of sync with the rest of the project we had a vote on this and decided that invariant sections were not okay the rest of it was probably alright but then invariant sections were not something that were acceptable or free under the Devian Free Software Guidelines and this seems to be something that the FSF is listening to whether or not they believe it and are changing it in the text of their license so we win so so as it turns out it's not just the GFDL there's this other organization that creates content licenses that that the Devian project decided that they had some problems we had a list a long list of eight problems Evan Pajromo wrote up a summary of a long discussion on legal with the whole list of problems there was there was a request to limit the scope a request to remove references, waive attribution after the request allow access control to private distribution to allow distribution of DRM copies if other distributed copies were made available require credit for comparable authorship rather than comparable authorship credit the whole list of eight things and with the exception of one or maybe two depending on how you count there was consensus among at least the group of people who were sort of chosen by Devian to represent this we got everything we wanted to now what's interesting is that we published this list of problems Evan published this list of problems with the CC licenses and CC came to and we love this thing let's work together to get these issues fixed and it's not because CC thought that and it's not because CC thought that it was so important to get CC works in Devian I don't think that for the most part people in CC really care that much although they might this year I don't think they did then but they asked because they respected Devian's opinion as the group of people who think about licenses more than anyone else and who understand the real implications of very subtle imperceptible to normal human being differences in text on freedom in very real ways so Devian has this and they're willing to come and ask it for so we got almost everything we wanted as a very similar thing happened when this organization that we didn't always have such a great relationship with at least after the GFDL sort of thing came to us again and Don and Brandon at the time DPL and Greg Pomerance who's the lawyer for SPI and myself were all explicitly selected to participate in committees there were probably what, 100 people maybe 100 people in the world 40% of the people who participated on committees were singled out because of their work in the Devian project and for that reason because they really did respect our sort of ability to analyze licenses so I think and as a result of the work that we've done I think that the licenses are much better as a result there's this other thing of this license the Afero General Public License a license that Devian Legal looked at several times and decided to have some serious freedom problems it's a license that allows people to allow users of applications who do not have copies distributed to ask for source it's like the GPL except if you're using a web service which seems to be happening more often so it did this by creating a barrier to modification and said if the software can distribute a copy of its own source code it could also you couldn't remove that functionality turns out this is problematic because Devian Legal and other people involved decided this is problematic because one could create a piece of software that distributed its source code in a particular way like using a patented service or a particular hardware device and you wouldn't be able to remove that so you'd still create tendencies as it turns out there's a new version of the AGPL which is what they're doing largely because of Devian and because of Devian and the involvement of people in Devian who made these sorts of arguments our position of the committee's position was helped hugely the entire debate was framed because of the type of license analysis that happened in any of your projects so lots of good stuff there and one quick thing there's this whole thing of trademark policies fun trademark policies you have this open use trademark license and then this official use license which is not used by anywhere I like that the HP shirt which is apparently not the official use used the official use logo and the official shirt used the open use logo but maybe that's just sort of funny but Devian has been thinking about and making decisions about open use trademark longer than anyone else as a result Devian and SPI in particular have been approached by just about every other who has a trade market who wants to allow it to be free for ideas of how to make it work that's an ongoing discussion right now there's not a happy ending but Devian will be instrumental in doing that because Devian is instrumental in thinking about these things within the entire community and then the last thing which is something that I'll not talk about in depth too much is this whole thing of distribution makers it turns out when people sit down to write a Linux distribution they usually sit down in front of Devian as a result there's a few of these Devians this is actually very incomplete this is about two years old but there's quite a few of them if you come tomorrow there will be I'm running a derivatives round table I'll send out emails to all the participants in this the idea is that we're going to try and get a group of these people who are deriving from and we're now in this really complex situation where there are now derivatives of derivatives and sometimes you can derivatives of derivatives of derivatives of Devian right there are the people who make a derivative of some of Unge derivative which is a derivative of Devian and there's some real hard questions we haven't answered yet about how we're all going to communicate but this is just sort of a test of it when people want to create something they look to, that takes into account the free software universe they look to the best representation of the free software universe in existence which is the Devian project so that's a bit that's what's going on here what we've built is we've built a summary and a collection of what's going on in the free software world we've built something that can act as a sample of what free software is we've built one of the best documented examples of a large successful volunteer project in general and in terms of an explicit shared goal and work together towards that goal this is the sort of thing that couldn't happen in this way before the internet we're one of the examples of the largest thing so not only one of the largest free software projects one of the largest projects of this type and as more and more work happens through the internet examples of things that people have learned from Devian will help everyone else and by keeping an eye on this stuff there's a Devian research group of people who are doing research on Devian and I think that I'd like to maybe organize a project by which we sort of do summary of our own work for the Devian projects that we can sort of close this loop and I look forward to, you know, in DevPomp 27 coming back with Bella as she's finishing up her lifetime of research and with everyone else here and to present all the great stuff that we've done here so congratulations everybody we've built something that's a lot more attractive than just a learning distribution so I mean if there's a question people should leave them and we're over we're five minutes over already we have to wait six minutes alright so six minutes if there are people that have questions unfortunately I can't answer a lot of the questions about the specific of this particular research I can pull stuff up because I didn't do most of it but but I just read the papers and talked about them so if people have questions or ideas or if they have other research that they know or examples they know of that would be a great thing to share so it's not so much a question as an observation and a request when you do the alphabet soup acronyms can you spell them oh yeah CC 3.0 sounds to me like an old compiler CC 3.0 CC 3.0 well, yes, not so old if it's CC 3.0 creative comments sorry okay, maybe we could alright are there other people that have something to say do it once, do it twice alright great, see you at the room tomorrow