 Okay, the next presentation is about caretaking of Debian finances by Martin Mike Schleimer and Martin Wurthel. Both names that no one can pronounce and then we just discussed whether we should be adding some more mountains to the team. So this, this talk and so we, so basically I submitted the talk a while ago and then didn't hear anything and so I assumed it wasn't accepted, but apparently it is accepted. But I think it's more really like a buff. It's really just to show you what we're planning to do and then have a discussion to see what the needs of different people are. So we just give a brief overview of the organization in terms of money and other assets with Debian and its trusted organizations. Then we will describe the different tasks that the Debian auditor is going to do and then we will talk about the next steps. So that's the things we will do soon. And so just briefly about the terminology. So the Debian auditor, I don't actually think it's a good name because if you actually look at the tasks that are involved, most of them actually really about financial recording and reporting. And the other problem with the name auditor is that whenever you talk to people, you know, they're really worried and ask, you know, what did I do wrong? You know, they think that we're the Spanish Inquisition. So maybe we want to change the name to something more neutral. The other thing is an asset because that's what we will talk about a lot. So an asset is basically something you own. So it could be money, it could be hardware, no domain names, whatever. And the liability is something that you owe. So for example, outstanding reimbursement for expenses. So the Debian auditors. So look who is not here. And then a few months ago, Suck was was looking for some volunteers to help with this team. And I foolishly told him that I'm currently interested in learning more about accounting. And yeah, I never talked to Suck. It's a really bad idea. And so basically that's when I when I sort of opted to help out with with this team. But but like I said, I'm really just learning about it. So I'm not an expert at all. And so a few days ago, I asked Martin, who is a real expert, who's actually whose day job is financial reporting. I asked him whether from time to time it would be OK if I ask him some questions. But as it turns out, I think he's actually joining the team. And and maybe I'm going to be his slave. And he's actually going to do everything which is the small tasks. So I think it's a good team. Thanks. So basically, I think Debian is a really interesting the way things are structured, because Debian in a legal sense doesn't actually exist. It's not a legal entity. So normally, you know, you would have Debian and Debian, which is own money. But that's not the case. So what actually is the case is that that there are other organizations and we call them trusted organizations and they hold assets on behalf of Debian. And historically, the the big two have been SPI who has been handling money in the States and FFIS in Germany and Europe. And and over the last few years, a number of small organizations have also come into existence like Debian UK, Debian Switzerland, I think there is Debian Japan. There are a lot of those regional organizations that also hold assets and on behalf of Debian. So so what does Debian actually have and that's going to be one of the big tasks is to actually keep track of what we have. So we have money, you know, in in Germany, in in the States, in Brazil. We have some hardware. We have some servers which are controlled by by DSA and which are owned by Debian with we have other servers which are not owned by Debian but controlled by DSA. And then we also have some some hardware that that is not controlled by DSA but still owned by Debian. So we and historically we haven't kept a very good track of of of, you know, what is the hardware, who has it, what is it being used for, those kind of things. We also have video hardware and and, you know, all kind of other things. Then Debian owns a number of trademarks and we also have domain names. And for example, with the domain name, once we keep track of it, it will be interesting because we can also keep track of the the expiration day and make sure that the domains are going to be renewed. So what are the the tasks? So the I think well one of the the big tasks is going to be to define procedures. So for example, that there are actually some informal procedures already. For example, in terms of the reimbursements for Debian expenses. At the moment, it basically works that you ask SUC and then SUC approves an expense and then we figure out how it's being paid. So for example, if it's in, you know, if you're in the States, then it makes sense to to for SPI to pay. But if you're in Germany or Europe, then it makes sense for FFIS to pay. And lately SUC has started seeing all of his approvals to the auditor email address. So we know when something has been approved and the idea behind that is once we obtain the the financial records of all the different trusted organizations, then we can compare every expense to an approval email. And if there is no approval email, then we can ask, you know, why was that expense made? What is it for? The other thing, we think it might be useful to have some criteria and some procedures for those trusted organizations. For example, you know, we can say that there has to be a Debian developer involved in the organization. We can say that you have to report your financial data to Debian, you know, every quarter. And if you don't do that, you're not a trusted organization anymore. Those kind of things. And we have also been working, we just had a discussion yesterday with the event people to see how we can keep track of t-shirts and other things merchandising for conferences. The other big task is the financial accounting and reporting. So the basic idea is that, like I said, you have those different organizations that hold money and they make some expenses on behalf of Debian. So for example, Debcon travel reimbursements or some sprints. And the idea would be that those organizations make those transactions available to us and we would load them in some kind of accounting system to keep track of all of them. And then we can also classify them. So for example, if there is an expense for a sprint, we can say that, yeah, that is an expense for a sprint. And one thing we need to do is figure out how we're going to classify those things. Because you could say it's an expense for travel, it's an expense for accommodation, but probably we don't care about that level of detail. We probably just care about, you know, is it a sprint? Is it a Debcon? Is it something else? And I think the next step is going to be to look at the reports produced by KDE and GNOME to see what kind of details they report. And also just to see for ourselves what kind of level of detail is interesting for us to know. The other thing is to keep track of expenses that have been pledged. So for example, the SAC, so sometimes someone comes to SAC and says, I want to organize a sprint and it's going to cost roughly 2,000 euro. And then SAC says, yeah, that's a good idea. Please keep me posted. And then the other people go off and organize the sprint. But at that time, they haven't submitted any expenses yet. But at the same time, SAC wants to know, yeah, there are 2,000 euro that we're probably going to spend in the future. And so those are things we want to keep track of. Simply so SAC knows how much money is there, how much money has been pledged, would not spend yet. And similarly, there might be a sponsor who says, well, I'm going to donate that amount of money, but he hasn't actually done so yet. The other thing, as I mentioned, track various assets. And then also do the one thing we haven't done is, even though we receive donations, is to actually show people what we do with their money, how we spend it and how those expenses improve Debian. And I think that's really something we need to do to produce some financial statements that show we have put that much money into sprints, we have put that much money into debt conf and those kind of things. Well, the idea is, how will we do that? We will retrieve the different financial data from each trusted body. Those data come in from different jurisdictions, so we need to somehow streamline those data, so make it comparable. We have the issue of currency translations, we have real, we have US dollars, we have Swiss banks, we have zeros, we have... It might be necessary to do some consolidation. For example, if we transfer money from Debian Swiss to FFIS, currently for the Brazilian reimbursement process, we need to add a consolidation level. We definitely want to step towards the cruel-based approach, so we can start with financial planning. Like, for example, in money that has been pledged for sprints, money that has been pledged to debt conf, that will be paid probably only after it's over. Then basically hardware replacement schedules, we will need to know, okay, in the next two years, we will need to spend like 15K on new servers at what time, because they have reached end of life. So to give the DPL much more financial background to have a better resource planning. So far it seems we will end up doing enterprise resource planning, and the best option so far seems to be Open ERP. We've been looking a bit inside this software. We mainly know that, for example, Creative uses it, and so far it seems it has everything inside we will need to get to finish the statements out. And potentially it could also be used to track things like inventory, like the t-shirts, those kind of things. So it has a lot of functionality. Yeah, domain name and expiration and all that stuff. Well, why do we do this? We want to help the DPL to make decisions. We want to keep track of pledges received and given. We already managed the hardware replacement schedule, and also it's interesting where is the money and how can we do a cash flow in case of reimbursements. Only a minor issue for the Debian auditor is actually auditing stuff. We will compare the annual reports by the trusted party with the data they provided us beforehand. We compare entries from organizations with DPL approval mails, check procedures of those organizations, but it should only be a very minor task. The next step, we've already started identifying organizations that hold Debian money. We've gone into contact with the treasury bodies of those organizations with most of them. And the next step are then if we have all the data setting our chart of accounts after looking at the GNOME project and the KDE project, get open ERP installed. We already opened the ticket. It will run on DSA hardware and then create the procedures. Since we are all about transparency, it is for us very important that our accounting system runs on Debian hardware and basically we want to have, once it's complete and set up, full read access for every Debian developer, so to have a maximum of transparency and trust. Any questions? Ideas? My question is about transparency. You were already treating it. Which are the policy for letting no details about Debian financing, both to Debian members such as, for example, developers, I'd say, and people outside Debian. So I think we should have an idea of how, okay, precisely how deeply we can let people know about our finances. Are there already established practices on this? The idea is to have sort of a management account and with goals mainly to the DPL and is accessible for all Debian developers. And there will be an external reporting, which is basically for our sponsors, where our main goal is to tell them, okay, we got so much money, we spent it on sprints, and in the sprints we achieved these and these goals. So it will be very aggregated on a case-by-case basis. And if I can just add, basically in the past, we didn't have any reports whatsoever. And then Luke a few months ago started writing some internal reports, so he sent something to Debian Private. But so far we have never made any public reports. And I think there has been a discussion about on Debian Private about that, whether we should be reporting that to the public or not. But I think the fact is that every non-profit, if you look at any other organization, makes those public statements just about, how much assets do you hold? What's your income? What's your expenses? And so we are going to do the same. It's just because we rely on donors. And so it's responsible for us to let them know what we do with their money. Yeah, so just a brief comment on that before passing it over to Ian. So according to constitution, we are bounded to let the project know how we use Debian money. So this is already required. And I think and actually I decided after the decision which has been mentioned to actually go fully public. So I think it's, as they said, a duty of Debian in general because we are here for openness, but also something we really should do. If we are asking for donation, the minimum you can do is letting people know how you use their money. But that said, I don't think that the reason why it hasn't been done up to now is malice or whatever. It's just that we have never had some established process and some people willing to implement them. So it's great that now we have people who are actually, we have the knowledge and we're interested in making that work. Thanks. This all sounds absolutely excellent. I'm looking forward to seeing everything being much better organized. One thing that occurs to me is it sounds like this is going to be a lot of work. Are you all happy doing this work? Do you have a sufficient supply of volunteers? Is there some other approach that might be possible? We can always use an additional pair of hands. I was afraid that might be what you were going to say. I'm just thinking that accountancy is not something that's generally very fun. I've done it occasionally for much smaller projects and for something the size of Debian, it's going to be quite a lot of fairly boring clerical work. It occurs to me that this might be a useful thing indeed that we might spend some of our money on. Well, the thing is we want to set it up initially and we already talked to the Debian CH guys and they think of, if we can provide them a sane default that they move their accounting directly into the project into the open European system once we have it running. If we can get many of our bodies streamlined or basically get wire scripting their data inside, I know FFIS has a SQL interface, so it shouldn't be too much of a task to get the basic data synchronized and then the rest is mainly getting the default procedure set up and then basic consolidation runs out of self. I'm head of group accounting at Treasury for a company with something like 120 legal entities, which I have been working for four years with monthly full reports and stock publishing. If you get your European system sort of really set up, it's not that much of a work to keep it running. However, getting it there is like three to six months. Thank you, excellent. I had a very quick question about the sort of global approach to this and about the consolidation that you mentioned and the benefits. I don't want to doubt in any way that you have the capacities and or maybe the capacities, but definitely not the competencies to do a consolidation across different currencies and across different legal entities. It is a tough job to do that. And I just simply wonder what the benefits are that we are going to get out of a consolidated budget, a consolidated financial statement that every year, compared to what we have at the moment, which is more or less a chaotically organized couple of entities and when something happens in Switzerland, then we'll take care of it. And if something happens in Austria, then maybe Debbie in Switzerland takes care of it too or maybe FFIS is faster. And we just report that to you and you keep track. What are the benefits that you think of having a closed accounting system? Well, for example, if we want to know we have to spend like 30K on whatever next year, we want to know how much money do we have now? Well, we have it in like 10 different currencies. You can't just sum it up. You need to somehow convert it. And if you have it in the system, it's like just a click away. Sure. But you will know that by the 31st of December for every year if you consolidate. And then if in August we need 30,000 for a new hardware, your financial statements are not going to be up to date anymore. So what you'll end up doing is asking Debbie in Switzerland how much is it that you have at the moment? Okay, you do have your centralized system. So you will actually have an overview of that. But is it really that often the case that we need this sort of information to warrant all the effort that we need to put into this? With you, accounting can be actually be fun. It's a challenge to do something like this. And I'm willing, as Debbie in Switzerland, treasurer to cooperate with you on this. But I don't see the benefit quite yet, other than the geeky aspect. Well, and maybe I can just add something in the meantime. I mean, one thing is that at the moment, for example, FFIS and SPI, they hold money for Debian. But for them, they don't care how we spend it. They don't classify any of those expenses. So we need to do that anyway. I mean, maybe for Debbie in Switzerland, because you're really only about Debian, we could tell you, we could give you some guidelines, how to classify the expenses. And then you could do it by yourself. And we wouldn't have to do it centrally. But for someone like SPI and FFIS, we have to do it anyway. Because for them, they don't look at the transactions. They don't care. And if we have to do it for them, then doing it for a few other organizations is probably not that much more work. I mean, that's the way I see it. And also, we intend to have quarterly updates. So we will have quiet accuracy for our purpose anyway. So you've understood correctly. Martin, part of your question is whether there is value in having a sample of one month with respect to a sample of 12 months. And you say that if the trust organization reports only once per year, consolidating is not much of a value. Is it it? No? My question was, no matter how long the period is, whether it's quarterly or yearly, there is definitely benefit to having a consolidated financial statement and an overview of all your assets and your liabilities. And even knowledge of the cash flow inside Debian is actually probably going to increase sponsorship, I think, or it has the potential to do that. So there are benefits to it at the same time. There's a lot of work that needs to flow into it. And I simply wonder whether the work that needs to go into it is worth the benefits that we get out of it as compared to the chaotic system that we have now. It's not like we are going to do real IFRS-based financial statements on consolidating with all those notes and that stuff. It's 99% of it is just an accumulation, including a currency translation, which is basically once you have the data in, the program does the work for you. So the main use case, I think, is minus DPL when Zobel maids me as DSA and tells me, okay, we need the replacement of 10,000 euro machine. Maybe we get it donated by someone, but maybe not. And in the maybe not case, I need to know, okay, we have this current spending power with this degree of certainty. And the degree of certainty is the money pledged but not the expanded, of course. So the much we have consolidated parts of our budget, the more we have consolidated part of our budget, the easier it is to answer that. So it's not Boolean, of course. We can have part of our trust organization which are consolidating the budget as we see them now and part which are not. But for that use case, the more it is consolidated, the better. And I think it's not only about money. It's also about trademarks and no main names, behold. We should take care of that. We are currently in some sort of process getting that sorted out. And finding out which trademarks Debian already has is not an easy job, I can tell. Is this on? Yeah. I absolutely agreed but we have to distinguish and maybe this is something we have to agree on what we want to do, we have to distinguish between inventory and financial statement. And if you want to put all of our hardware and our trademarks into a financial statement, well, and consolidate that across currencies, good luck. So I was once treasurer of the Cambridge University Science Fiction Society which has an enormous library and one of the things that one treasurer once attempted to do was to include our library on our financial statement on the balance sheet. This obviously didn't work very well because nobody knew what the library was worth in cash terms and anyway, the library was run separately by the librarian and the amounts of money that the library was worth was definitely much, much bigger than the amount of cash we had. So the whole thing was a bit silly really and I think it seems to me that Debian is in maybe a vaguely similar position and probably we want more money but our physical assets and trademarks we don't regard them ourselves as having financial value and therefore we probably don't want to deal with them in our accounting system. I think we have to distinguish since we are using an ERP system putting something like hardware or licenses in and then signing it in actual well is a different thing and doubt we can just put it in with an amount of zero because we already spent the money but the asset trackkeeping is our main purpose for this stuff. You're talking about using open ERP, is that correct? Sorry? You're planning on using open ERP? What? Yeah. Sorry, I was basically reading my email. Yeah, I try to use the open ERP for a very long time and battered my head against various things including the fact that it's maintained in large pad by people that don't apply to bugs. So yeah, if you're writing open ERP yourself that's a really good idea you do what you like but if you think that open ERP is as good as its publicity is then well, I was driven close to suicide before I changed to a ledger CLI and you know, ledger CLI you just put it in vim, go easy everybody can understand it there's four implementations of it one in Haskell so you might want to think about that instead. If you have anything better? Yeah, well ledger CLI lets you do sums open ERP the illustration is that I was trying to get a chart of accounts for the UK sorted out but I'm not an accountant so yeah, okay I was starting from the wrong place really the chart of accounts that was the module that was said chart UK seems to have been derived from SQL ledger or one of those and it was completely broken before it was extracted from SQL ledger and then they broke it even more so that things like Firmature got added to VAT because what they'd done was they took the numerical codes for all the things and then they assumed the numerical codes meant something and did the hierarchy based on the numbers not on the sense of the thing okay, so I reported a bug against open ERP and it was laid dormant and the bug said basically this is a toxic disaster anybody that tries to use this module will become very angry you should just remove it and it took them eight months to triage it well okay there's another module that was the actual sort of closest attempt to a UK chart of accounts that had a bug in it where it would add the expenditure VAT to the purchase VAT so your VAT liability would just go up all the time because no matter how much you bought that bug took a little bit less about three months to fix the sort of contribution hostile opening up well I don't expect us to run into many of those problems because all the bodies are doing their accounting and text filings themselves we just take the figures group them by the chart of accounts and make a reporting we don't do any text filings we don't do yeah sure but you know if you find a bug in it yeah good luck I just wanted to before before we talk about the technicalities and how we maintain things you meant in Git by the way not in VIM but uh no I mean uh you can edit ledger CLI it's just a text file you do your accounting in VIM and then you put that version of the month's accounts into Git and then you can see exactly what you changed exactly marvelous um before we get onto that level though can we can we just agree from what I understood that you Martin to the right said we're not going to try to activate our assets but we are going to have an inventory of ours assets and we're going to have a balance sheet that is only currencies and liabilities yeah okay and so in terms of ledger so I also use ledger and that that is what I was planning to use cool however I don't think it handles multiple currencies very well like I mean I because I track my personal finance and I ran into a lot of issues and so even even though I think it will be easy to get started with ledger I think doing any of the reporting is going to be a nightmare and so so Martin suggested open ERB and I don't I don't know it but I mean it looks really interesting I guess we would just have to take a look at it and see if it works I mean I agree it looks really interesting I spent you know six months that I could have been consulting trying to make it work for myself so but then I'm a rubbish accountant so you know it's probably mostly my fault it seemed to be very good at when you had an invoice in a different currency from your default it was very good at coming up with a fractional amount of tax that you can't settle so that you can't close the invoice and things like that it's got lots of little edge cases that you can bump into and you know I don't know how to fix it any more questions issues well from the perspective of the one of the treasurers then what is it that you expect us to give you every quarter whatever you report mostly an income statement that's Gewinn Verlust Rechnung yeah yeah okay good basically your bank account movements and yeah okay that and and possibly sure and possibly the inventory like of the shirts that we have and all this kind of stuff but not the balance sheet yeah but you don't need to do a physical inventory inventory and the quarterly basis now just what you think you have best estimate okay okay thank you thank you