Present: Pranav Salunke, Matthias Larisch, Douglas Webb, Philip Engelbutzeder

Notary: Janina Abels

Proofreading: Matthias Larisch

Location: Kirchheim unter Teck

Link to original pad: https://pad.riseup.net/p/productqa

[Meeting starts 14:40]

PS: Did i fail to see how the platform would scale out?

We should be expecting a lot of users, it could be 50k or 100k users joining over a weekend in case of an event. This is something i'm not able to visualize with the platform and i don't see any planning on how to handle this in the specs or the trello cards.

ML: we might need a complete rewrite of the backend if we hit a billion users, because there's no planning for that atm. as it seems we will start with one server and see how long that will suffice, i think it will suffice at least for some months. after that we need to scale up and out, meaning bigger servers and more of them.

PS: (regarding storing multiple terabytes of data in a clustered, relational database) This will be really expensive to do i think

ML: We are not thinking about terabytes of data, we don't design this system to manage millions of users, you're completetly right on this.

DW: You seem to be on the same page, only

PS: (regarding Migrating to some other / No-SQL Database at a later stage) migration live would be very difficult and expensive to do.

ML: I completely agree.

PS: So how would you handle that situation when it arises.

ML: I'd say we don't even think about that now. if we were to think about that already it would make everything much more difficult.

PS: Even 100k users with the scope of yunity is quite heavy load on the database.

ML: I don't see the point of saving binary user data stuff (like images etc.) in any kind of database as there are already things available.

ML: Datastorage backend vs database backend is completely different, wouldn't you agree?

PS: Not completely

DW: Why can't people who write code atm write code atm and other people who want to think about future architecture do that at the same time?

DW: The mvp is unidirectional foodtransfer basically

ML: If we find someone who is ready to think about that question already, that's fine. we just don't want to use resources on that right now.

PS: Why do we have to create everything from scratch in the backend development?

PS: Have you done research on existing solutions and their usability for the project?

PE: I did research on existing organizations and we found quite a bit, but nothing that fit perfectly.

PS: I found an open source one, i got a link.

ML: You mean diaspora? yes we had a look at that and we now already have more in yunity than all of diaspora had. They don't have a permissions-system and it's a very basic application that is not sophisticated enough for our needs. We did some research in malo already but there was nothing coming up. maybe we didn't look deep enough, though.

PS: We could also use the bitcoin sourcecode to not only upload (didn't get it sorry)

ML: Like a decentral solution?

PS: We could use it in differet ways.

ML: Would you care to elaborate on that, maybe also in written form, so that we can come back to it later? right now i don't really see where you're getting at.

PS: We could evaluate the code and see if we can make use of it.

PS: We could take a lot of time to write the most beautiful code ever, but will take 50 years, or we take a closer look at what is already out there.

ML: I just don't think it's relevant right now.

PS: Why is it not relevant?

ML: Because of the amount of users I guess..?

DW: We could have been researching for the past 7 months but people also wanted to jump rigt in. we could build cases to examine further, with blockchain as well.

ML: Oh you didn't even suggest using blockchain?

PS: No.

ML: Oh sorry I got that wrong.

PS: I'm not pointing towards a particular solution, I'm talking on the conceptual level. I never questioned the programming language or the framework, I question the way you are using it.

ML: Curtis also noticed some things and said 'oh that would be easily parallelisable' and we just didn't notice before. When we are at a point were we have things running we can still have a closer look and fix issues like that, but we first want to get to that point.

The current developers have experience with relational databases and thats why we use them.

PS: Again, migration would be very very cost expensive.

ML: Again, i totally agree.

DW: Yes we go a little circular here, I think matthias totally gets your concerns.

ML: I actually agree.

PS: I see a communication gap between dreamers and devs.

ML: We only have hard data of foodsharing, and even if I multiply it by 10 it will still be managable for a while.

PS: But who defined the 10? it could be 1 or 1000.

ML: Well, maybe we should do some scietific research on how many people potentially would use yunity.

DW: Data on foodsharing could maybe be put onto the wiki somewhere by Matthias and maybe Pranav also could write something to make his concerns regarding relational databases more clear.

PS: Concerning the licence: how does it support the vision of yunity if the licence used forces people to ?? (Regarding copyleft in (A)GPL)

ML: We wanted to have a licence in malo, so that we don't have none, knowing that we can always change it again. for sure, it's not completely unconditional if we force people to contribute all their modifications back to us.

PS: Even companies often have more free licences on code which is running on their million dollar deals. We are much better in terms of these things but the licence doesn't reflect it.

DW: Do you think this is philosophical or practical or both?

PS: I think it's very practical, because it has an impact when it comes to funding or developers who don't want to work under copyleft licences. GPL would be much more permissive and less controversial, because there are not only a few devs who really hate copyleft.

ML: We chose the AGPL because we wanted to be protected from the scenario that some big business comes, forks our code, makes some nice contributions and publishes a premium version were you have to pay money to register for example.

DW: we had this discussion for the non-code licencing and it all boiled down to the question of trust vs. fear. I think this also applies here.

PS: I would not call it fear, I completely get what Matthias is saying, but it is a bit irrelevant. Making money out of code which is exactly like yunity is difficult, because it's not exactly a tool or a backend technology. In fact, most of the big companies are open sourcing all of their most valuable code, because the value is not in the code anymore, it's in the users.

ML: I agree.

ML: I didn't have a look at the non-code stuff, but I see that it would be strange to go cc0 and then have AGPL, but i'm still in favor of that, because I really don't like the idea of someone taking our code and just benefitting from it for themselves. But then again, I don't have strong objections on a completely free licence either, it's not that it's not possible with me.

DW: Tilmann pointed out that contributor agreements would be a good idea to be able to change the licenses later without having to ask every contributor again.

PS: If we don't have the permission of only one she could screw us all over, so the longer we wait the more complicated it would get.

ML: I also think we'd need a legal entity for that.

PS: For me it's not clear how we're planning to run this code, whatever code it will be. A global scale software would require public clouds, funding, an admin on call.

ML: I agree in general. It will start the same as with foodsharing, we will have one server which we will administrate ourselves.

PS: So the scale is not really planned.

ML: In the beginning stages we would not invite the whole world to use our software.

PS: I heard different things from other people.

ML: Yeah well, for me it's hard to imagine running a lightly tested software with thousands of users straight from the start. I'd say we start with some people and have a beta phase before thinking in larger scales.

PS: I know that it's not feasible to use cloud systems from the start but there definitely is a lack of communication within the yunity team about what the MVP and the software in general should or will look like.

PE: Coming back to the research question, could you tell us what exactly to research, Pranav? I mean, it would take ages to register on all the websites we already found and figure them out. How to start?

PS: My approach would be to have a look at these sites from a developer's perspective, but you added onto that that somebody should also actually use them to see, if it could fit. It definitely would be a very big task.

[Meeting ends 15:50]

Holger: we should modularize, as soon as we have a stable core we can add functionalities. I think of yunity as the platform on which different modules - like foodsharing - are running. and everything else can be added then

ML: That's what we're doing at the moment. We're still at the core.

H: But there are already functionalities that don't really belong into the core in the specs for the MVP. we are too focused on foodsharing. We should stop writing foodsharing 2 into the core.