 All right, so not too loud. Okay, yeah, the volume is okay. Yep, because it feels very sensitive. Okay, there was, so the name of the talk is Unhobbyst Software. And this is the talk I actually gave in Kern in one of Linux Audio Meetups. And it has been, if you've seen this, I hope that I'll be able to update some of the things. If not, then great. So what this talk is about is actually very general about any hobbyist software endeavor in general. And what I wanna do is I want this talk to be really bouncing off ideas off of you and hoping to receive some feedback. So this should not be any type of last word on the issue. I don't consider that to be this. It's just my thoughts over the years that have accumulated about hobbyist projects. And so the way I define hobbyist software is any software that is made not as a job, not as something that typically brings you money. Of course, theoretically you can have a hobby that brings you money, but I'm talking about software that usually does not. And you will hear me use Linux software, free software and hobbyist software interchangeably because Linux happens to be one of those domains which is mainly hobbyist software. If you look at least at the client side of things, and I would be very happy if somebody corrects me on that and shows me statistics that it's not correct, but from what I see if you get a typical Linux distribution like Ubuntu, you will see that most of the client software that you see that the user sees is mostly hobbyist software. So, and what I want to do here is to kind of not really criticize, although it will definitely have like the sound of it being a criticism, but more of analyzing how I see the hobbyist projects, open source, free software, Linux projects in general work, why that happens, but whether this is good or not is absolutely based on what context you're coming from. So if your context is one, even for me, some of the things are good in one situation and bad in another. And just to give another kind of introduction to this and to explain where I'm coming from, I'm actually a huge Star Trek fan and I've been into Star Trek for a long time. I've watched it throughout my growing up and I can say I have been raised by Star Trek. I'm not the only one. I'm in good company. As you know, in the 70s and the 80s, many people, a whole generation of engineers said that they were really inspired by Star Trek. So, but one of the things that not all of you, if you're not Trekkies, you might not know is that if you're a Star Trek fan, you love taking apart all the episodes and explaining how the writing is bad, how that character should not have behaved the way he behaved, how that plot line is absolutely stupid and that's a lot of fun and we're doing it for episodes that we really, truly love. And so the reason why I do this kind of things and like criticizing some things and taking them apart is because I really enjoy hobbies, communities. I have been into that for a very long time. So that's like kind of another thing because now the reason why I do a lot of these introductions is because over the years talking to developers and especially after my talk in code and I have approached several developers, conversations were actually very difficult because this seems to be a very painful subject in general as people consider their projects to be very personal. They identify with them, which is very understandable but then any discussion of any like kind of critical nature is difficult. So, okay, so let's start. You are a user who knows nothing about Linux or open source or free software projects and you come on board and here are the things that I believe you should expect on a very fundamental level. So number one is that very often you will see a very uncommon for proprietary commercial software projects characteristic feature that you will see a software that has very cool, unique, never before seen in the history of humankind features but you kind of don't have some of the basic stuff and maybe some of you have seen this. In fact, can I ask for a raise of hands for those of you who are considered themselves to be primarily developers and not users? So yes, if you're a developer but not a user you consider yourself to be mostly developer. Okay, so, okay, 50-50 about, very nice. So that's good. So anyway, so many of you might have seen this and I believe that there is a reason behind this whether you consider it to be bad or not is a separate issue but I believe that the reason for this is because many of hobbyist software does not really have professional roadmap and by professional roadmap I mean something that is being assessed typically professionally in a commercial software development fields meaning that you have a clear vision of what the software is, what the audience of the software is and what the workflow should be. So there are several things that are exceptions and exceptions to these rules are mainly software packages that have been commercial for a very long time and then they have been open sourced. Blender is a good example. Some, I had many other examples while I was walking here but now they're kind of forgotten them but anyway. Huh? Yep, QT, also known as QT. There was, you know, you would ask somebody what framework are you using? He will say QT and you're like, not from our crowd. Anyway, so yeah, so a lot of these are pretty good because they have been developed commercially for a long time and then they're into the wild and very often they actually do benefit from this. Eclipse, yeah. Actually, does anybody know if GIMP started out as free software initially or was it also commercial? I think it was free software initially, no? Oh, it was actually free. So this is a very cool exception. I love GIMP, anyway. So, Libre, oh yeah, I'll talk about Libre Office, yes. So let me give you an example of what I mean no professional roadmap because many developers will tell you like straight out, no, we do have a roadmap, here it is and we actually have let's say monthly meetings, Skype calls, whatever, REC chats to understand what we want to work on. So what's the difference? Well, the difference is that one thing is just to have some roadmap and another thing is to have a roadmap that would kind of professionally assess towards your goal and if your goal is to produce functional software then your roadmap has to reflect on that. One of the things that I usually bring up as an example is that I was working with one DJ software available for Linux. It's generally a very good reliable package and I was asking for one feature from the developers so imagine you're loading a loop and that is a loop that is like based, it's a BPM 130 loop, drum based loop. So what you wanna do, if you open a sample editor in the software, you want it to have bars and so you want it to have a grid so that you can for example, you have a four by four sample and you want very quickly to make it two by four and that is being used very often in live performances where instead of you do this kind of thing and you can put it on a media knob and then quickly do this. And so I asked them for this feature, I explained what it is, I didn't go into too much detail but they did implement it a year later and they said, it's out, I'm like yes, finally. So a lot of the software I tried to do this and it doesn't work and the thing that they did incorrectly was that let's say they have a big sample, you want to cut it in half basically, so what you do is you drag the sample endpoint and you drag it to the point of 50% the second bar but what happened was that while you were dragging it, the sample continued bouncing off of it and so you could not really do it in a live performance because what you wanted to do was drag it and it had to keep the old endpoint in place and then when you let go, then it happens and I think that the reason why that error was made because the developers never really understood why I needed it. They never wrote a user story even into their mind of why that guy is asking for this. My understanding is that they just read, okay, so this guy uses this software a lot, he's really nice, he's on the forums, so he's asking for it, let's do it. But if you think about commercial software development where they have some sort of understanding of, okay, what is the audience we're working for? They would ask, why do you need this feature? Maybe this is important. What practical example is for this feature? And of course, one can say that in a hobbyist environment, the user should be more detailed and I agree with that but on the other hand, it is the developer that spends the time. So it kinda is a little on the developer side to make sure he doesn't waste time and energy on doing something that perhaps in the end is not that useful. In this case, of course, it's easy to correct, I think but there are situations where I've seen people do features and then it was not really clear why they did it. So another thing is that if you don't have a clear vision of the product, and this is something that I generally call kind developer syndrome. And this is something that I have very mixed opinions about and I think everybody should. When you're asking a developer for a feature, there are people who will say, I will not do it. I just won't do it, I don't care about your request and they're generally considered to be evil guys, what an evil son of a bitch. So and if he says, yeah, absolutely, next month you'll see it, that's a good guy but what happens very often is that you see software that has huge amounts of options, huge amounts of features but they're kinda either weird or tailored to a very specific workflow or and then you have some basic things lacking, maybe perhaps they're very difficult to do or because nobody just asked for them. And so if you would have a vision of what your software has to do, you probably would not have it because you would say, okay, this is, let's say, this is a video editor that has to produce videos and has to render it, it has to apply effects and then somebody says, oh, by the way, I do VJ'ing here, can you please add? And if you say, okay, my software is actually not VJ'ing software, so this request, although interesting, will go to the back of the backlog. Then this would be perhaps a different story. And one of the things that I see a lot in the generally mostly Linux community is that there is this idea that, you know, it's better to give user the options and let the user choose. And it sounds like, you know, it's not a bad idea, why not? But the problem very often is that, let's say that you have a piece of software that has one functionality and there are dozens of ways to get there, dozens of ways to add a track, dozens of ways to add effect on the track or something like that. Then what happens is that in each of these points, this is a potential source of bugs. And if you have just one strict workflow, it's easier on a practical standpoint to make it reliable. And I have seen situations where there would be an audio workstation software sequencer and would have several ways to add a track and one of them would be broken. And then they fix it and then the next month another would be broken. But if there would be just one way to add a track, that would be not a problem. And a lot of, like, it doesn't mean that there shouldn't be options at all, but I think that they should be very carefully weighted. And I do see this as a sort of a trend. May I say? Yes. May I add from the developer perspective, this software is often created in a developer-centric way. And the reason why you get this much options is because there was a contentious quarrel behind the scenes. There were developers, they are highly opinionated. Neither of them is a professional in that area, but they have opinions. It has absolutely to be done in that way. We are creating a video editor. We had a huge quarrel. If you put the play and the play control buttons into the viewer window or into the timeline window. And it is almost intersolvable and it starts a war. So you resettle that button, you may make it an option. The user can choose it because we want to end this quarrel and get back to coding. The most, in my opinion, is the reason for this much options because the developers couldn't settle down upon a, and they couldn't toss a coin to just decide. You know, the saying, when you can't resolve a quarrel by reasoning, you just toss a coin. But that won't happen at open source setup. We'll go on with quarrelling and arguing forever so that the most reasonable way to end that quarrel is to make it optional. Thanks, I wrote it down. That's a good point. And I've seen that happen, but I kind of never put it down. So thanks. That's very useful. But actually, so I'll start, I'll give one more point and then I actually give another developer insight that was not known to me and that I think is very important in the discussion. So one of the things, another thing that kind of annoys me and that's where I'm really being annoyed. So before it was like, happens, this is where I'm annoyed. Reliability is almost never, ever in the list of features in the hobby of software world. It's like, so I have to mention this software and yeah, so there is a software called OpenShot. I made a video about it. I love the software, but in a bad way. I hate it, okay. So the problem here is not that, I don't have any basically personal problems with developers or anything. I'm just looking at it as a user. I come to the website which says OpenShot is a great video editor for Linux. And you read on the blogs that video editing on Linux kind of sucks and people complain about it. And you come to the website and it has a list of features like chroma key, key framing, effects, anything you want. And you're like, what are they complaining about? How is that possible that anyone can complain with this perfect software existing in the world and of course on the internet? And then you start using it and it kind of doesn't work. And the problem with OpenShot is that it's not reliable. And by not reliable, I mean like, top one unreliable software I've ever seen in my life. Really, my first C++ program crashed less. Okay, it was a whole world, but anyway. So that's a problem because I think that this is very misleading. You come to, and very often people come to Linux and they say, oh, we have lots of things. And you open up a repository and you have huge amount of packages and you say video editor and there's like a huge list of packages but they're like some complimentary packages that are like 12 pieces of software and you start installing them and you go through them and none of them work. And that sucks. And I think that this is dishonest. That's why I mentioned it. So I think that, but reliability is a huge part of what software should have, especially. My point here is that, especially if we're talking about editing tools, as soon as you have something that you have to do work with, not just the video player that shows something, you can kind of live with a buggy video player but you have to do videos or to do text or to do music. It has to be reliable. I want it to have less features and I want it to be more reliable. And just I have heard arguments against that. Well, you know, there's no testing and I'm gonna speak about that a little bit more but one of the ways that reliability could be bolstered and I've talked to several developers and they said, actually we do do that for Windows but we don't do that for Linux. Okay. Is that you try to incorporate the libraries that you use including UI libraries into your software. And that's kind of what many software packages do at least on Windows is that they don't have this Linux situation where you can just, oh, I have a repository that has a library and that's a UI library that I'm using but that then creates a more break situation. It breaks all the time. They update the libraries incompatible and that's bad. And so you have to roll back your updates and sometimes it's not very easy to do. Whereas if you just package a stable library then it will work for a long time. And one of the things that OpenShot developers have said they would say, you know what? Our software is absolutely stable. It's like rock solid. But we're basing it on MLT and this is like a multimedia framework that actually does video processing that breaks. Okay, so then how can you say that your software is like software is video, if you're saying, oh, I wrote a knob here it's absolutely great. Yeah, the whole software crashes, sure. But this is, anyway, sorry. I know that was too emotional, but I just... So now let me give you another story. So I said, okay, no professional roadmap. Why is that, people are not stupid, right? They have their reasons for this and very often these reasons are rooted in circumstances that people find themselves in. And so one of the discussions that I have with a developer of a very known Linux audio package, he told me something that I was not aware of but maybe some of you may relate to. He said, okay, so on our roadmap one of the top pieces, and that's what I criticized and initially said, how can you have one of your top roadmap items changing the skin of the software, like changing how UI looks when you have this, this and this absolutely show stopper bugs. And he's like, okay, we don't have developers. And the problem is that if people who are in the community around the software they are not programmers mostly. I want to make them interested in programming. So I will throw out something that is super interesting like beautiful UI, that is interesting to many. They'll start working around it. Some of them start learning C++ which actually happened and then these guys begin to code more complicated features. And so he says this is basically a way to market a developer space for other developers. And I think that this is a very interesting insight and it explains that, yes, these things happen and the roadmap in these communities can be tailored towards a different situation, very different from what you see in commercial development. For the end user, this might create problems. You can see a software that has a very strong developer community or so it seems that doesn't work but people are doing things around it and they're saying it's great. And in reality, this is difficult. Like one of the things that I was also told is that some developers might contribute a lot and they could be very skilled but then they leave abruptly, just leave that's it. And they have features that are not done and why shouldn't they leave? This is just, they don't have a contract or anything. They have things in their life that happen so they leave but the people who are left they have to solve this problem. So one of the things that explains this behavior and shows that actually it's not about people per se who are working but more about circumstances that they find themselves in. I found this to be a really interesting insight. So that was number one, roadmap and everything connected to the roadmap. Number two is actually what you said is that Linux is a very developer-centric community. There is a blog post or an article that I find very helpful which says Linux is not Windows and it's an article which I think many of you might have read in the past that explains why people who try to migrate from Windows to Linux find it irritating because they have certain assumptions about how Linux should work and actually it does not because it's a totally different approach and this is the same thing. Linux is basically, it's a developer-centric community because it's generally a group of people who decided to build things for themselves and that is a difference that is overlooked by many people who are not around this community and who don't even understand that Linux is basically more of a community. It's more of a, it's like if you take away the community I think that Linux will not exist as a phenomenon that it is right now. So, but because it's developer-centric then the user who comes to this community he might expect other things or several certain things that are a consequence of this being developer-centric community. So number one and these are not in any particular order is that generally software and discussion about software is burdened by developer problems that in all other situations the user should not care about. Let's say that something does not work, your video editor or sound editor does not save files and the developer says, sorry, I mean the library's broken or the library doesn't work anymore, we have to fix it, it doesn't work and maybe you can find a fix for it but that's the problem. And the consequence of this is that you can very often find yourself with crippled software and at the same time it's unlikely that developers will feel that this is a showstopper bug that you have to forget about everything and just try to fix it. And that again is just about the circumstance that they find themselves in. And one of the examples that I have and somebody mentioned LibreOffice which has Libre Impress, has anyone ever used this piece of software? I see a couple of hands. Yes, so I've used it as well and that was the last time I did it because it turns out Libre Impress, if you try to make like over 10 pages of presentations like over 10 pages, it has a bug that has resurfaced over the years again and again that it will randomly delete images from your presentation. And if you read Google and like websites where people report bugs, there were people who are saying my university stopped using LibreOffice because of this because we can't make presentations. And I spent like about eight hours making a presentation and I didn't close it, I was just saving it and then next day I decided, I was not even closing it, just pressing save. And then I returned to slide number 15 from slide number 50 and I realized some images are missing and like, what's going on? And I look into the XML file, of course, and it's just blank, there's nothing in there, no path, no anything. And then when I try to manually enter the path, it doesn't work. And I started reading and it actually it's a bug and it hasn't been fixed. And basically one of the reasons why it's not fixed was that, well, nobody really using it so we don't really care. Like they use Excel kind of stuff, like how do you call Excel? I forget. Yeah, Calc, so people use Calc, they don't really use Impress, of course they don't use Impress, I don't use Impress anymore. But that's one of the, so another thing, developer opinion typically overrides opinion of the user. So many of you might have seen it and it actually, like in light of me talking about the roadmap, it might make sense in certain situations. However, if you go to commercial software, then you usually, of course you have to do it scientifically. You have to make sure that you're listening to the right users who are using your software the way it was intended to be and not like weird ways and say, I want this feature for whatever reason. But you kind of have to listen to your users because they're usually the ones that have practical understanding of this. And one of the arguments, and last time I talked, somebody thought I was quoting somebody, no, this is a very generic argument, that many developers say, what reason is there for a user to believe that his opinion is better? But if we look at products and Linux audio conference, so let's mention some musical products, Tractor Studio for DJs, Ableton Live, apart from just having testers sitting in a room hired as QA specialists, you have many actual performing famous DJs working with developers directly, and they have to look at what this guy's doing, why he's doing this, and then they understand, and they say, oh, okay, so this is why he's asking for it. And it's not just a whim, he really needs this. One of the examples is Knob. And Knob example is one that I really like because it shows, on a very specific example, it shows a very generic problem. So if you're following a Linux audio mailing list, you might have spotted these conversations and you can search for them, although I don't advise it, it's just very long to read. But so the general argument is that knobs are bad, it's like why would you use knobs? It's not very effective, why would you have to draw this when you just can have a text field? It works everywhere, it's super cross platform and cross laptop and cross PC, whatever, it just works, and you can use it. Why do you want these catchy marketed UIs? However, that is actually a bad argument and many people have pointed this out because if you're actually using this in a live situation, then a knob you can just turn, even in the software you can just turn it, whereas if you need to change a text field, you have to actually type, that's not very good. Also of course, a knob can be put to a MIDI controller and then you can use that to turn the knob. And another practical reasons for all of you who performed with hardware, if you have a hardware and you have a software version here and you have a preset there, you can very quickly look at the preset and do your thing and when you turn it on, it will not have jumping values from what you have in the software and what you have in the hardware. And that's not, it's just visually easier to read if you have values from minus 100 to 100 and it's like it says 73 and you have like, okay, what do you do here? And sometimes you just see it. So in a practical sense, a knob is very important. It's an interface to hardware, it's just simpler to work with in a live situation. And so I believe that a user has very good reason to believe that a knob is important and it's just not just marketing. And finally, well, kind of, that was pointed out to me and I really want to hear everybody's opinion on this because that's something that I wonder if this is true across the board. But one of the opinions that I heard was that code contribution seems to be the central thing and bug reports are not really you contributing to the software. I have experienced some of that. It feels that the motivations that developers might have in the Linux world generally would be that they don't really care about that much users because another user means more problems. It means more bug reports, it means more complaining. And if many people use software, so what? Why? I don't care about that. And definitely not true for all software but could be a tendency. Here I'm not sure because I don't have the statistics. In fact, I'm not sure that I know a lot of situations where I stumbled upon this but neither did I ask about it. Neither did I ask, oh, do you care whether a lot of users is good? I did have a situation where I wrote to one of the developers saying, hey, I'm going to this conference or a meetup. I'm going to promote your software. It kind of crashes all the time. Can you quickly help me? And he's like asked, answered me about two weeks later. Yeah, sure, what's the problem? I'm like, oh, okay. I don't know. Maybe I'm looking to, but still it's interesting that if you have a commercial package that a new user means another order, another potential order, somebody paying money, if you're a developer who's doing just hobbyist software, well, it's okay to have a lot of users but it's also not that important. So I don't know whether that's true or not but that's interesting, I think. And finally, for testing developers almost fully relying users. And this is something that has been a premise of open source development as a methodology for a very long time. And to be honest, I believe that it doesn't really work because first of all, in the end, users are just always left with crippled software that they have to fix basically. At the same time, their contribution does not count that much. So you, okay, you file the bug report good. It would be better if you fixed it, right? That's what I heard a lot of times. And also the process of actually fixing the bugs is very, very slow. It's the priority as we go back to the roadmap thing is not always clear. I had several situations when key features were not present like a video editor would not render audio at all and that feature would not be prioritized in the bug fixing queue at all as well. And then several years later, I tried the software, now it works, okay. So, okay, so I'm almost done. I'm almost done. The final thing that I wanna say is that I find that one of the reasons why I equate hobby software to Linux is again, as I said that because Linux is made basically the domain of hobby software but also because Linux community is a lot about free software community. It's like intersecting communities and free software is basically an ideological movement, so to speak. It is social activism. And a lot of free software development seems to be based on ideology rather on rational discussion about software. Some of the things I feel are done as an answer to commercial development. If a commercial program that is proprietary is, does not have, has beautiful UI, then we'll make geeky UIs. In fact, we'll make it text-based and if you don't learn the text-based UI, we'll screw you. Or sometimes really baffling discussions about UI concepts where it's clear that UI is looked as an ideological tool rather than something practical. Hence my knob example. And of course, a lot of talk about how software should not only be free as in freedom, although Richard Stallman would countless times say you can sell your software. In general, I have seen that the, like the sentiment is that you shouldn't take money for software. One of the discussions that I've seen recently, there is a very interesting game design engine coming up in a community called Godot. It's becoming bigger and bigger and it is very reliable. And you know, I'm kind of, I like reliability. And it seems to be on par with generally unity. I'm not sure that you can like, maybe unity is made in many things is better, but it's really good. It's like has all the physics engine and everything. And so they have a Facebook group where people ask questions. And one of the questions was, how do I integrate this monetization platform into my game? Because you can compile this for iOS, Android. And a person says, you know, I want to show some interstitials. I want to make money on this. And the overwhelming response was, you shouldn't do that to your users. And like, okay, but that is an opinion of course, but I do see that the prevalence is that you shouldn't make money off of it. So that kind of discussion, I think plays a big role in how it shapes the actual end result that you see as a user. So that is it. And that's basically all I want to say. Again, all of these things are not value judgments. So when I, except for reliability, sorry, that's, I'll leave that. But so whenever I say that this is based on ideology, that I don't actually think that this is bad. It's not bad. If somebody thinks that free software ideology is their primary goal of doing software, then this is good for them. If somebody wants to get things done primarily, then that would be bad for him. So it really depends on the context. In fact, even for me, in certain situations, I would prefer sometimes this approach, sometimes that approach. So all of this is basically an analysis of why it works the way it works. And I like these insights because they explain that actually all people generally are very smart and good intentioned people, which find themselves in very different circumstances. So I conclude here and I'm open to questions if you have any. So thank you very much for that inspiring talk. I want to start with a metaphor. Let's think of building construction, building houses. You've basically got two models. You make construction for someone who rents or buys that house and moves in. And the other model is you build for yourself. So the open source community is very much like, now here's a piece of wood, we chop some trees and then we have space and then we build our huts for ourselves. So it's not ideological. I want my house to be the way I like it. So the user isn't, when the user wants to come, yeah, he can chop some further trees and build his house on the side here if he has a free space and then we discuss how to set up the fence. That's quite a different mindset as if you say the user pays for me and I built a house for him that it's useful and that's a process I produce a product and it's for the user. Yeah, yeah. So one of the problems with any nuanced message is it's very difficult to pass across. And so you heard me mention several things that it's hobby, that it has ideology, but I don't say that it's the only thing. I just say that I think that a lot of ideology plays into this, but definitely not the only thing. And so I definitely agree that the reason why Linux has developer-centric communities is because people come over here to just do things for themselves, that's true. It's just that there are a lot of claims as well about software that, oh, you know what? This is a great sequencer and it's great because it's open source and everybody can fix it and and and and and but it never really happens. So in situations where the developer really is doing it for himself with actually, I was surprised to see that it's very rarely the case. Oh, perhaps developer starts a tool for himself. He builds it the way he likes it. It could be very odd, but he likes it and he stops doing it. Then some other people come over and they start working on it and it stops being a tool for one developer. And so while it's good in theory, in reality it has all these many variables and I absolutely agree that these variables cannot be put down to just one situation. Oh, this is ideology, definitely not, definitely not. But another thing, I just had a thought so I was talking about that a person is building it for himself, I forgot it. But anyway, maybe not, they're important. But yeah, so you're, I think, I find your comment to be correct. I just wanted to make sure that everybody understands this is a very complicated situation where I don't say that there's just one reason for it. Huge amount of reasons. It's a question of point of view. If you look at it, I built a house for myself, then it's not an ideology. If you look from the outside, it might look as an ideology. No, I mean, you can argue that everything is an ideology. A person who says that he is building a house for himself is in the ideology that he has to build things for himself. And there's a funny, I don't know if anybody's seen this. The point I want to make is you often get into quarrels with the people because they don't see it as ideological, that they don't see the argument. Oh yeah, I mean, when I talk about ideology, I mean free software, when people say there are these freedoms, people should have them. If they don't, then this is evil. Microsoft is evil, that's ideology. Saying that somebody wants to build something for themselves, I don't consider that to be ideology in this sense. So I was talking only about this political free software movement. No, no, no, you quickly get into the point that the house must be built precisely that way and it must be have a flat roof. And it's absolutely wicked if it doesn't have a flat roof. This kind of quarrels, as a former user perspective, you just can't understand that quarrels. Yeah, perhaps outside it's very difficult to understand, many being impossible. But if you take on the point of view of the people, that's my house and I want it to be absolutely beautiful and it's my vision, then it's the absolute natural, it must be have a flat roof. Definitely, definitely. Yeah, you mentioned the duality between idealism and rationalism, I actually don't see it that way. Like I think the rational thing to do is to be idealistic. And I'm 37 and I have gray hair, so you know. But you know, I see that that might sound like your typical idealist speaking, but no actually, believe it or not, yesterday at about the same time, I was writing down the street and thinking, should I say that phrase or not? Because it's actually inaccurate, so. Whoa, whoa, whoa, whoa. So because if you define rationality, it's doing something that fits your goal. So if your goal is being idealistic, then what you're doing is perfectly rational. So when I say rational discussion about software, I think I mentioned it, rational discussion about software in terms of getting functional result. So definitely, if you're an idealist as a person and that's your goal in life, that's your mission, then what you do is totally rational in the context of your goal. So that was just an inaccurate phrase that kind of. But even in terms of getting functional software, like if your view is to like basically Richard Stallman's view, like software is not functional unless, no, no, no, no. Yes. I think that's perfectly rational. Yeah, yeah, I mean, it's perfectly rational if you take that goal to be your goal and then do things towards that. Definitely, I agree with that. Actually, one of the things that I can mention is that sometimes in discussions about commercial software and free software, it is mentioned that commercial software has competition and competition has these and these things and it's bad and companies hate each other and that kind of stuff. And always in these things remark that actually free software world has a lot of competition, but that competition is based not on selling things but on licenses, on ideological things. Like, hey, my license is better than yours, so let's work open office and make it Libre office and forget about the damn thing and now we're working with this one. And so I think that there's a lot of competition in Linux as well, so it's actually not that different in many respects from any human activity. If I can come in on one point. I describe myself as a user that's got dragged into software development. And I was actually very surprised with your comment about attitude towards bug fixing because my own personal attitude is as soon as someone reports a bug, I'm on it straight away because I don't want any of the software that I'm working on to have any bugs. So I actually think they're doing me a favor. So I don't really understand people. I can see that it happens, but I don't understand people not wanting to get them out of the way as quickly as possible. Well, one of the, so it's great. I definitely, there are people with the same attitude that you have. One of the reasons that I heard, again, talking to developers, so this guy told me so that he really cares about the team that's working on the software. And my feeling was that he is really happy to be doing this great thing and he's not that keen on the end result. Like it's great that people are coming over, they're learning programming, the team is being creative, but I didn't feel that he really cared that the software actually works. So that could be one of the reasons. Probably there are many, many variables in this. But if you're a team lead and you have many, many developers from different countries coming over and you're saying, hey, you know what, try C++, it's not that bad. And then you see them actually adding patches, like, wow, they're growing and you feel that that's your team. That becomes very important. And one of the things that I heard two developers say, and I just don't wanna name any names, just so that it's more or less anonymous and that I ask somebody of you, you know that I will not go personal. But they would say, I would ask them, what do you consider your main achievements? And they would say, well, number one, we have a lot of community events. Number two, our community is growing and strong. Number three, we have a great Facebook, IRC and forum. And in none of these achievements, they would say, oh yeah, and our software works and is actually being used by musicians or by whoever should use it. And that's, I think, very telling. So it really depends on our perspective. And it seems that in larger projects that stem from someone's personal project, it seems to be a tendency. I'd like to add to your words, Will. So of course, Kashimi is one really bright and shiny example of fixing bugs very quickly. Thank you for that. I believe for many other projects and developers, it's just the natural, the human nature to say the exciting part is to write the software, to construct the new parts of the building, to design something new. Once it's somewhat working, then really, as you said, Luigi, the maintenance part, the fixing of ugly, nasty bugs, which are hard to produce and communicate with developers who just supply very washy bug reports. This is far less sexy than the real feature implementation. So I think this is the natural effect if you have no boss behind you to kick your ass when you leave your tickets around for more than a week. This is where commercial world and free software just differs, I guess. So hard to come around this. If you have a reasonably large project, like, say, GIMP with a team of 10 or more developers, where someone can be the project lead and can perhaps really give people kind of orders, please work on this ticket now. It might work out for small one or two human projects, I guess, unless that person kicks his own butt, which is not easy. And then there won't be so quick bug fixing than feature development, which is just more appealing. Yes, yes, totally agree. Okay, anybody else? Well, I guess just someone has to say it. A lot of you guys are fixing bugs really fast and it's really great. And really, in general, I think my experience I've been more often surprised by how quick a book was fixed than the other way around. Like... Well, I had, like, generally, yeah, I also had very good experience with this, but I also had very bad experience. I once wrote one developer. Just, you know, I really loved his software. All I wanted to do is just say, man, such great software. And I just wrote it. I love your software. Thanks very much for it. And he wrote me back online, don't ask for features. Okay. So I haven't. I haven't even, I didn't even want, but I kinda... Okay, everybody, thank you very much.