 Are you sitting comfortably? Good afternoon, ladies and gentlemen, and anybody else who happens to be watching. As is traditional every year, this is the bits from the DPL. So I would like to welcome the one and only Lucas Nisbaum. Thank you. Thank you for coming. Yeah, OK, that's fine. So to start this talk, I wanted to look back a bit about what we achieved as a project since last year, because I think that this was a great year for Debian. First, we made the decision in its system debate, in its system choice. So that was hard, but we made it. We set up LTS support for Squeeze. That's also something that's been discussed for a few years, and it is finally starting and working. If you look at what others think about Debian, I think that shows that Debian is stronger than ever as a foundation. After the decision on SystemD, we want to follow just a few days after that. Valve choose Debian as a basis for SteamOS. That shows that people look at Debian and see a strong foundation for their own projects and follow our technical choices. So there have been many new exciting developments such as DebianNet, Tracker, DebianOg, Debian Contributors, Debian CI, and many more to come if you look at the schedule for DebConf. And the Jesse Freeze is looking quite good. We are down to 340 RC bugs. If you look at the stats for the previous releases, it means that we are about 21 weeks to release. So if you just hurry up a bit, we can release by Christmas, basically. Well, maybe that's a bit of a dream, but who knows? We'll see. Okay, so I wanted to use that talk, talk about things that were discussed quite a bit during the DPL election. And that might be boring to some of you, but I think it's important that we take a look at Debian's financial status to understand where we are. So in that talk, all values are in US dollars since we are in the US, which means that even if you see a value about FFIS, which holds funds in the EU, for example, or DebianCH, I've converted it using those rates. That was a rate a few days ago. So first, Debian funds are not held directly by Debian, but Debian uses a set of trusted organizations. So basically Debian has bank accounts at several organizations. Each organization provides a different level of service in detail about money that they add about Debian, which means that doing all those stats actually takes a lot of time and requires quite a lot of scripting. So the current list of Debian trusted organizations is the following. So we have SPI in the US, which uses US dollars. FFIS in Germany, which uses euro. Debian in France, which uses euro as well. Debian of Deutschland, which uses euro. And Debian CH in Switzerland, which uses Swiss francs. So the current balance is the following. So for SPI, the data is from the end of June because they haven't published a report for the end of July yet. So the two main trusted organizations for which we use the most to make expenses are SPI and FFIS, that's why they are involved. We have about $30,000 at both FFIS and Debian CH. $4,000 at Debian France and zero at Debian Deutschland. So what's more interesting? I didn't make it 25 euro. Okay, sorry. I didn't ask, I should have. So more interesting, that's the current balance. Let's look at how it changed over time. So that graph is about SPI, that one is about FFIS. I could not generate it for Debian CH, it's probably less interesting to look at. It's mostly the depth of 13 surplus. So for SPI, the purple part, so that's time. I'm not sure if you can read in the back of the room, that's 2009, that's 2014. The purple part is Debian funds and the various other parts are funds for various depth conf editions. So blue one is depth conf 14, that's depth conf 13, et cetera. So one can see that it has been increasing quite steadily, especially during the last two years thanks to the great work done by the depth conf 13 sponsoring team. Probably for depth conf, yeah. Probably for depth conf 14 it's going to drop a little because there are things to pay, we are not here for free. But still, it is expected that depth conf 14 will also generate a surplus. So... You suck, spend the money on some travels from the ring. Yeah, sorry. Yeah, so it looks a bit exponential actually in the end, I don't think it is, still it's a bit scary. For FFIS, it's a lot more stable. It has been going down a bit recently but that's just because we have been using FFIS for quite a lot of quite large expenses since the beginning of the year. That actually starts in 2002, so you see that. There's always been between almost zero and $60,000. So I try to look at various aspects that are related to Debian money first donations. So I've passed the data about credit card donations to SPI account. So those donations are processed through third party service called Click and Pledge. So if you go to the Debian.org slash donations webpage, you get a link. If you want to donate via SPI, you get a link to a page that looks like that. And actually what's important for the next slide is that that form enables you to donate to various organizations, not just Debian, but you have a long list of organizations where you can donate to. So that's actual numbers. So the year, of course, that's a total donation to Debian for the given year. It's for 2014, that's up to a few days ago. That's a total of donations where Debian was involved. So what happens is that you can go to that page and decide to donate $150, $100 to Debian, and $150 to another organization, for example, OpenWRT. So that's a total of donations. That could be $150, and that's $100 that goes to Debian. So one can see that the median value for donations is actually really stable. We get a lot of small donations. It's important to remember that that there are lots of individuals giving small amount of money to Debian. It's actually fairly stable if you consider the fact that in 2010, 2001, 11, 2012, we got three large donations using credit cards. So if you remove that, basically it's stable over the years. It looks like we are a bit lower than, well, we are two-thirds of the year if you multiply it by, well, if you do the computation for 2014. The projection looks a bit low, but that's also probably expected because we get lots of donations at the end of the year. I think that's because U.S. citizens do a tax report at the end of the year, and that's the point of time where they decided it's a good idea to give to Debian. December is usually the big month for our donations. So if you have clarification questions about that, just ask. So now that all the scripts are written, yeah, it would be quite easy to regenerate the data. Oh, yeah, I will just repeat that kind of questions, but I was asked whether the data would be available again at the end of the year. So let's look at expenses. So the question is, oh, does Debian spend money on? What does Debian spend money on? So the first, well, a big expense for Debian is debt conf. The budgets vary quite a lot depending on where that conf takes place. We have the new cost, for example, that varies quite a lot. It's between $150k, $150,000 per year, including travel sponsorship. For this year, it was $42,000. We spend quite a lot of money and other kind of travels for sprints. Some, but not so much on Debian developers depending on traveling to upstream conferences. That occurred two or three times this year, I think. We found some other events, for example, mini debt confs, to make it easier for people, for speakers to travel to mini debt confs. We founded Tails Act Fest in July. We also spent quite a lot of money on infrastructure, so hardware, of course, but also stuff like DNS domain names, SSL certificate, hardware warranty. I don't have the data to take a breakdown for SPI, which would be more interesting, but actually a lot more work to do. That's the data for FFIS, so it's mostly an example because the amount spent at FFIS is much lower than at SPI. But it shows that basically it's split about evenly between infrastructure, related and travel-related. So some thoughts about that. First, I think that before talking about Jeves, I think it's important to state that we must respect our donors and to use their donations to improve Debian. So that actually is quite interesting. There are two sides to this. First thing is we should use their donations to improve Debian. But we should also use their donations and if they donate money to Debian, I don't think that it's quite right to just have it sitting in a bank account. Of course, it's important that we have some amount of reserve in case of, well, emergency expenses, but having almost $250,000 bank accounts might be a bit too much. So, yeah, I think it's important that we have enough reserves. We have basically what could be needed for one full Debian. So I'm not encouraging the Debian 15 team to fail completely. But still, we could afford that. So please don't. We could probably improve on fundraising. We are both with this morning about this issue. There are lots of ideas flying around about how to improve fundraising. I'm quite sure that if we were slightly more aggressive, we would be able to raise a lot more. And we sometimes feel too guilty about using Debian money. I've heard of people who are really core contributors to Debian who spend a lot of time on Debian and who decided not to come to Debian because they didn't feel that it was right for the project to pay for their travel. They couldn't afford it themselves, so they decided not to apply. That's really sad because probably it would have been really useful to have them here. So we had the discussion, many of these discussions last year about ideas for spending more money. I've tried to go through it and summarize it. So I think that there are many ways that we could use to make good use of Debian money and spend more money. The first set of ideas about increasing visibility of Debian and attracting more contributors. So we could help more of the organization of mini debt confs. That's a good way to reach out to our users and potential contributors. One way to do that is to sponsor Debian developers who travel to such events and talk about Debian development. The second point is likely to be less consensual. I think that we could use some money to just to send a signal to our new contributors that we appreciate that they are contributing to Debian and welcome them to our community. For example, sending quite cheap goodies on the order of a teacher to new contributors. I think that's something that we could do. I'm thinking of spending something like $5,000 per year on that. I think that would be quite reasonable. It would be a first step, a first nice step before, well, saying to them that we noticed that they are starting to contribute. We kind of know that becoming a DM or becoming a DD is a really long path, but at least we know that they are there. Something else is material for Debian Boost. So we have a Debian event team that set up a kind of Debian event box and be sent to events mainly in Europe. It's actually kind of empty, so it could be a good idea to work on buying stuff like banners and other materials that are frequently used at their conferences. Another thing that was discussed is improving security and trust of Debian archive by providing cryptographic cards for DDs. We could also do more about improving the efficiency of development, organize prints. So I think that's the message I want to yeah. So let's okay, I'm quite sure that not all of this well, some of this might be a bit controversial. Let's discuss it at the end of the talk. Let's not start a big discussion right now. I hope that there will be time to discuss this. But if you have clarification questions I'm fine with taking them now. So yeah, so regarding prints, there are quite a lot of prints that are being organized. Mostly by core teams, I think that we can extend to more teams and have we don't have that many packaging teams meeting in prints. We could totally do more of that. So hardware used for Debian development. So I don't think that we can afford buying laptops for Debian developers. But when someone needs specialized hardware, could be portal machines for development machines for porters Last year we bought a quite powerful system so that one of the maintainers could do builds of DI at home with a fast machine. So that kind of expenses, I think that's something that we could do more as well. And then finally, more trouble sponsorship for DebConf. I don't think that we can afford sponsoring every DM plus DD to but probably we should look into sponsoring more or even a lot more. Like for example, for DMs it's quite nice to have them at DebConf get involved in the community and that's usually probably most of you will realize that but once you are at DebConf you talk with a lot of people and usually as a result you do more in the future in terms of the BIAN development. And then last point about improving communication with upstreams we could sponsor travel and attendance to some upstream conferences. For example it would totally make sense for the BIAN to sponsor travel and attendance to PyCon for our Python developers if they cannot find another way to attend. And that's important to have a good communication with our upstream developers. So I think there was a suggestion at some point to have dinner once a year with your upstream. I don't think that the BIAN should pay. Well maybe it depends on the kind of dinner but that's something that could be discussed. But that's the kind of things that if it contributes to the BIAN development why not? So just to be clear actually in favor of everything listed here so there are things that clearly need coordinators so if you want to volunteer about working on them just contact me. So just before moving on to the rest of the talk I'd like just to do a quick show of hands for each item so that we know where people stand. So for each item I will ask two questions who would be in support of spending the project's money on this particular item? Who would not be in support of spending the project money on a particular item? So first one help organization of who would be in support who wouldn't be in support of reducing our current spending of money on such thing possibly to zero. Well currently we are spending money on this so so so goodies for new contributors who would be in support who wouldn't be in support so I would say about 70 of 80 percent of people are in support just for the for the video because we are not regarding the room and for 100 percent for the first item. So material for the BIAN booth who would be in support okay. Who wouldn't be in support okay so probably 80 or 90 percent um cryptographic smart cards for DD's would be in support okay who wouldn't be in support okay so 90 percent at least 95 percent uh sprints who wouldn't be in support wouldn't be in support okay so 95 percent adware used for the BIAN development who would be in support who wouldn't be in support okay one hundred percent I said no laptops I was thinking more travel sponsorship for would be in support who wouldn't be in support okay 100 percent and uh sponsoring travel for certain ones to assume conferences who would be in support who would not be in support okay 100 percent okay so the most uh unpopular one is goodies for new contributors but uh at least 70 percent support for all of them. So we can we will be able to discuss this at the end of the talk uh I made it quite short so that we have time to talk about this I'm not going to just think that there might be good points in the 30 percent that disagree so the second part of the talk I wanted to do some uh say think tank about the BIAN uh so I don't know who is familiar with SWOT analysis so the idea is to try to look at uh strength weaknesses opportunities and threats to the BIAN in that case and look at yeah what can we build on in terms of strength what are the opportunities so the difference between uh strength and opportunities or between weaknesses and threats is that strength are uh from internal origins that we are stuff that we build ourselves and uh opportunities are stuff that have an external origin that is stuff from the outside that just happen to happen at the same time as uh uh currently uh okay so uh yeah weaknesses and threats are things that uh are or might be uh unfull to us now or in the future so I tried to do the uh that work you might disagree with me so let's go through it because strength I think that what's quite uh really great in the BIAN is that when you talk to people there's a strong uh shared common uh uh ideas and goals uh among contributors we all uh are feel very strongly about uh our general uh goals we might disagree on many small details uh that's for example what is free software and what isn't uh but still uh I think that uh it's quite for organizations that's really great that we agree on so much and care so much about uh it but also widespread agreement about our foundation documents and procedures of course uh the secretary might sometimes have things to say about particular things but still uh we all care deeply about respecting uh uh those documents and maybe even a bit too much maybe a bit too conservative sometimes about uh the documents um um everybody cares about the BIAN and likes it even when not using it if you look at the system you debate it was uh all over the news uh uh because everybody looks at the BIAN and cares about it and everybody loves the BIAN when you go to conferences not depth conf and uh you say that you are involved in the BIAN everybody even using uh derivatives uh say that they are really big fans of the BIAN there's a deep respect for the project uh we have a large active community of volunteers um that's uh so I was wondering uh earlier this week that someone know of larger free software projects other than the BIAN community projects I think that the BIAN is clearly by far the largest uh community uh free software project and uh that it works so well in some sense uh it's really uh how many are you talking what are the numbers on that so we have uh one thousand uh official developers plus about 300 uh dms 240 dms plus uh a lot of people who are just contributing without any official status and uh to a single project I mean if you take the Python community as a whole that's probably uh larger than that but uh to a single uh under a single umbrella I think that uh that's really large uh also uh the BIAN is independent and we don't compromise with it and that's actually some things that is probably quite attractive to many other entities if you look at uh companies from the company point of view the fact that uh someone can join the community and don't feel like they are joining an inside company name shop uh is actually uh quite great and probably that's why uh companies like uh Valve or more recently uh HP uh are looking into uh working with the BIAN so in terms of uh opportunities we are probably one of the few remaining large community projects uh uh at least this distribution in terms of size we are probably by far the largest many other uh projects are becoming more and more company oriented and I think that we all care deeply about the fact that uh we are remaining mostly independent from any uh any company that's also uh following all the uh Snowden stuff hostility towards some big corporate players and by being having such independence I think that we are in a great position to to succeed to success to succeed you know let's look at the darker sides and our weaknesses she just likes a bit longer not a good sign but first point is uh we tend to well we are a large project but there's some dispassion of manpower uh so the slides will be available see people taking pictures but uh that's not that might not be useful so there's a dispassion of manpower we are lack of manpower there's a lack of manpower on core things most of our core teams are clearly uh lack lack help and would use a lot of that more help but also a lack of interest and contributors to non-technical tasks uh if you try to do auditors both or fundraising both you will see that those are the most unpopular event at Debcon a bit to both and that's a bit uh strange I mean that's important as well for the success of Debian and uh it's quite interesting see so many people in favor of spending more money but at the same time being so interested in attending a fundraising both um there's some um quite a that's probably an unavoidable due to the size of Debian but there's some implementation uh inside Debian we tend to have teams that become their own projects and don't share that much as they as much as they use to with the rest of the project the one good example is uh packaging workflows for many years we had different workflows in each team basically uh so I just started some work to try to move towards fixing that but still uh we probably could uh have more exchange more between teams another example is um uh each scripting language that tends to have its own solution for switching switches between transitions between versions that's something that having kind of overview of what each team is doing and what are the pro and cons of each solution could be quite useful um packaging is difficult even if well if when you talk to people who are really strong uh developers or this admins and you ask them to do the first Debian package usually it's quite hard for them and the success rate is actually quite low and this probably limits the use of packages that are standard software distribution mechanism uh if our if it was easier to build Debian packages maybe wouldn't have so many uh alternative and language specific packaging systems uh it's very difficult to get started in Debian um so I did recently uh I looked recently as at old ITPs and uh mostly ITPs bugs and there are lots of people who did the work of creating a Debian package for something and who gave up because they could not find a sponsor we also have quite high requirements about quality uh most of the package that uh managed to get sponsored out of mentor that probably of much higher quality on average than uh packages uh DDS upload uh well without any review uh maybe that's a bit unreasonable and we just we should just file bugs about uh minor issues not care so much about lintian pedantic tags um there's also some disconnection from upstream for many maintainers uh by that I mean that uh uh Debian maintainer works on its package but has has never exchanged an email uh to uh one of the uh to the upstream uh developers community and uh there was a blog first from your kaplan on Planet Debian today about this but that's really something that uh yeah we should try to improve so some threats so external things first the perceptions the growing perceptions that uh distributions are solved problems and we are we are not cool anymore and all the cool kids are doing something else at working in distributions that probably wasn't the case 10 years ago I think that we have a lot of things to do as distributions lots of interesting problems to solve and uh schedule at Debian shows a lot of things that uh distributions can contribute to solving but still that's uh us and we need to be to communicate this to to the rest of the world so that uh we are not perceived as the all guys that do uh all the boring stuff um the required skills to work on Debian are actually quite rare and not typically not taught in typical university uh curriculums uh if you look at uh projects doing web development for example every student uh doing computer science knows about web development what's required in Debian for to contribute to Debian is a bit uh unclear actually it's a mix of development skills his admin skills will give uh systems skills and uh yeah that's something that is not taught anymore at universities and it makes it much more difficult for us to recruit students for programs like GSOC or to recruit uh new contributors and actually when so maybe you know about gift bugs so the name is not quite good but um the idea was to tag bugs that are suitable for new contributors and there are very few bugs tagged uh like that and very few turn over about uh those bugs getting fixed probably because we have problems identifying what's uh what's the level of skills expected from new contributors um there's also an increasing competition with emerging language specific packaging solutions uh I can't think of a scripting language or high level language right knows that doesn't have its own packaging solution uh can you think of one maybe not ask her but um that's uh that's the kind of kind of a failure for Debian not having or for distributions in general not having been able to uh impose uh Debian packages as a de facto standard so as I said uh I wanted to uh leave a lot of space for discussion today uh the slides are available here to make it easier to discuss I will just copy paste the slides okay that are going to be the most discussed probably on Gobi so there's a Gobi document in the talk sub directory and well thank you and uh I'm waiting for your questions or comments or whatever uh with the I think we want to maybe so again so I don't know if you were in uh Stefano's talk um on Saturday I think it was um he identified something that some some things that I think probably ought to be on our radar as threats and possibly also as do you think those are important um so yeah I thought about that uh so yeah yeah I think I think that's a threat for the clearly a threat for the free software community uh I'm not sure if tibian has so much to contribute to solving this uh as a distribution um one so well probably uh there's some improvement to be done in making it easier for users to install software so they can run their own infrastructure their own uh web services but that's something that we have not been able to do well probably yeah with people to work on web applications packaging update the policy on web application uh the current one uh based on what 10 years ago it's totally probably unsuitable to recent um uh web applications uh we need to fix that problem before uh I think uh going further in that area that's a problem that we know has existed for a long time um I just wanted to pick up on that comment you made about debconf and the um you know show of hands about travel sponsorship and uh just wanted to say that we're very well aware of this um and we would like to spend more money on travel sponsorship and get more people involved if they can if they have the time in the past it's always been a little bit of a time constraint and this year actually we had more money set aside than was actually claimed so we got some money back um this means two things first of all I think we should start a little earlier and we are on that so that it's easier to plan your time and uh and get vacation improved and second uh we also need to encourage people that as a matter of fact your participation is important and we will help you do it and that's the job for all of you guys and we'll work on the rest so one of the things you listed as a threat the idea that the packaging skills are a combination of system administration and development skills um given that I just had a giant argument with that with the previous employer um the one of the things I want to call out there is that we have an opportunity uh in being clear about what we do inside Debian I think to attract a lot more people by making by making the point that the things that you do in Debian is part of building a package is actually DevOps skills so that combination of development plus system administration is something that the industry has been fighting about for years and the DevOps camp that says that you should do both of those things together in one team with one set of people is mostly winning um and if we can point out that and I tried to point this out in my talk about enterprise system administration and for Debian in New York um that those really that the skills that you do in Debian packaging are DevOps skills are enterprise system administration skills and vice versa anyone who can do DevOps can do Debian packaging um that might be an opportunity for us to get more attention and more um attract more contributors and make it look cooler uh to address one of your other points on spending money spending money I'd like to see the LWN editors at Debian Comp 15 also the um package specific um language specific package managers I see that as an opportunity rather than a threat because it means that we can develop tools to easily turn those into Debian packages yeah so I'd like to hear from people who did not support the idea of goodies for actually you had a comment and I'm sure that's what it was yeah that one uh oh yep okay I was just going to point out that um if we do buy cryptographic smart cards that does violate uh the key ring team's requirement of uh 4k keys because as far as I know um the maximum key like yeah no turn around okay yes that's true 2k needs are fine 2k yeah cause as far as I know as far as I know the maximum you can get problems all but a key ring might place 4k a new key supports 4k keys of the open pgp smart card yep but this is the hardware all way track okay nevermind uh my my understanding is first of all that you can convince the open pgp cards to do 4k keys there's a trick to it where you tell generate a 4k key and then it realizes it can and it's all good 2k keys only in exceptional circumstances proved to me it's a good idea otherwise 4k keys so do the trick on the card to get a 4k key my concern about cryptographic smart cards is we order a thousand cryptographic smart cards and then all of a sudden what do I do? let's see I'll trojan a thousand cryptographic smart cards for Debian. I'm not sure how to do reliable distribution for it I think it would certainly help in many ways but there are complicated things which is much more than just the money around it that's why it's in red on that slide actually I'm not going to work on that myself people can well if you figure out how to solve the technical issue I think you can consider the money issue to be solved at my point that's not what is going to be done for nothing we can buy them on the technical side we are fine with buying them thank you thank you very much many thanks to Lucas