Hey guys, it's Nate, aka The Foot Accountant. Welcome back to the channel. We went into yesterday with Premier League team in the season, all excited and hyped for the PremTots cards that were going to be released on this game. But EA have released some upgrades and some cards that just don't make sense. I don't understand what EA is doing with some of these cards they've released and some of the stat upgrades that they have given these Premier League team in the season cards. So we're going to talk about that. And of course, how it impacted the market because some cards were lower rated than we thought. That made prices crash, but other cards were really higher rated than we thought and really juiced and that made some prices go up. So there's the market's moving all different directions right now in this game. And I think that's going to continue into Saturday as well. So there's a lot to talk about with the market. We also have to cover yesterday's content that was a big W, especially with that crafting objective that was really cool. And will we see a big SBC or multiple big SBCs today with more player SBCs and maybe an icon pack? Yeah, we'll talk about that in today's video as well. Also down below in the comments, I want to know who you packed because I didn't pack a single Premtense yesterday from 40 Save the Player Picks and a bunch of like 85.5, 81.11, those sorts of packs. I'm in the mud with Premier League team this season. But so make me feel a little bit better. Tell me who you guys were able to pack. If you're excited for the video, drop a thumbs up on it. And of course, subscribe if you are new. Now let's talk about the SBCs first from yesterday. There wasn't a ton. We finally got the Alan St. Maximon, but boy, is he expensive, right? I kind of jokingly said on stream that he felt like an icon SBC, a W dynamic image and albeit a very nice upgrade as well. And I'm doing this card because I know I'm going to have so many upgrade packs throughout this next week that I will be opening. I'll be able to craft just about every SBC. So that's why I started on him right away. But seven hundred and something thousand coins for this card. I really think it's not that terrible value, although we're saying it is expensive because if this card was on the market, he would probably be around this price that he is as an SBC. I really do believe he would be about seven hundred K, maybe six to a hundred K on the market, just because this is a nice boost, right? You take a look at his winter wildcards. We got plus six shooting, plus five passing and five physical. So a W upgrade here for Alan St. Maximon and we finally got the big boy exciting SBC that we were all looking forward to. But when you compare this to the card that is in objectives as one of the rewards for the craft to glory objective, you compare this to metoma. I know metoma does not have the five star skills and he may not look as meta, but statistically metoma is way better. And it's kind of crazy that a 92 rated metoma in objectives for quotes free is almost the same or better than Alan St. Maximon in terms of the stats. So that's kind of crazy there. This, in my opinions, the biggest W or one of the biggest dubbies of Premier League Tots is this craft to glory objective, which some of you guys may be confused with some of these SBCs and how to do this. Now, there's four different SBCs we have to complete to get this kind of craft to glory objective done. The prime bronze upgrade, prime silver upgrade, gold upgrade and the premium Premier League upgrade. And not all of these are available yet, specifically this premium Premier League upgrade pack. This is not going to be out as you've noticed in the Premier League Tots season swaps. The premium Premier League upgrade SBC is not available until Monday, right? That's our kind of upgrade pack. It's going to be coming out so we can't really do this objective all right away. It's not like you can easily breeze through this by doing a bunch of upgrade packs and getting the metoma and the Paulina, which is super cool. You get both Tots cards as kind of the final craft and reward of this objective. That's really dope. Gigi's the EA again. Like I said, I think this is the biggest W objective. It's not that hard to complete. You just kind of have to do the SBCs as we go down the line. So watch out for the SBCs that we need to complete this kind of getting released throughout the week and just kind of keep track of how many times you have to do this. There's some XP, of course, inside of this as well, two different segments where you get 1250 XP, you get a coach at the very end, you get some nice packs in between like an 81 11 Premier League pack for completing the Premier League premium upgrade SBC 10 times, which is going to be so easy to do this next week. So huge W here from EA. Again, like we said, though, it's very similar to everything else that's been dropped in season progress. It takes a little bit of time because EA can kind of control how much XP we get and they control when these SBCs come out. So they can kind of delay the rewards, if you know what I mean. So just kind of keep an eye out for that. But that is the W by the end of the week. We also had a Premier League Cup, which is the same friendly mode as last week for the Air Divisie Cup. But this time it is confirmed, I believe, that you have to actually play with the full Premier League squad. Last week, you didn't have to play with the Air Divisie Squad. But some people have been saying that you need to have a full squad of Premier League players in order for this to count in the objective. So make sure you actually do that. No icon squads, but so Premier League squads are going to be pretty cracked there. And then all the Watkins, I kind of didn't even realize I got two of these done from playing a couple of games of footchamps playoffs. But this is a nice free Premier League striker with 99 sprint speed, grade shooting stats, again, 99 jumping, 98 heading, really high stamina and strength as well. Doesn't have amazing traits, but he's got really nice stats for a free card. He can't complain too much there. So a lot going on in objectives yesterday, not as much going on in SBCs. And of course, as we would have expected, a ton going on in the store as EA released the TOTS team that everybody is going and trying to pack. One of the highlights of the store was this TOTS premium pack. There's two more packs that are going to be coming this week. And there's like an elite TOTS pack and a TOTS Foundations pack, I believe that we have not seen yet. But this pack, a lot of people are opening 60 percent chance of a TOTS player. But let me tell you this. This is the highest percentage chance of a TOTS player in a pack where I see not that many TOTS players being pulled. So just be careful because 60 percent seems super sweet. But 400 K, 2000 FIFA points, it's a big coin drain or it is, you know, 2000 FIFA points that you may not get that good of a TOTS card. Of course, you could you could get something amazing. So that's a gamble pack there that a lot of people are going and doing just because it gives you a really high chance of packing a team in the season. Now, let's talk through the confusion that we have with this Premier League TOTS team. There are some W upgrades inside of here. First of all, it feels like this team is set into two segments, right? You've got the top tier upper echelon players of guys like Holland, Kevin, De Bruyne, Rashford, Salah and Ruben Diaz. Those high rated cars, basically 96 and above 95 and above. Those guys, insane upgrades, right? Katie B is arguably better than his team of the year card being also 97 and rated, but having 85 defense, a plus four defensive upgrade there. Yes, the team of the year does have plus one pace and plus two shooting. But for me, I'd rather have the boost of stats around the rest of the card for the team of the season version of Katie B. And then it's even no comparison for Holland, right? Holland is above the rating of his team of the year card with plus ones, plus twos and a five star week foot, hence the crazy, crazy price. Man, I know we did a price prediction video earlier on in this week. Once we saw the leaks and men, how crazy is it that EA did not do anything close to what we were really expecting for any of these cards? You know, Rashford, I had no idea Rashford was going to be 95 rated and be this cracked and this expensive. In my opinion, Rashford is the most overpriced card in this team for sure. But he is super duper rare. And I mean, guys, he did get a really massive upgrade. So GGs, this is a deserved card for sure and super cracked in game. But I think he is a little bit overpriced. Holland, the price is overpriced too, but it makes sense. The guys that are overpriced, the guys that actually got good upgrades, right? Salah with five star skills, only a three star week foot, bit of a bummer. Ruben Diaz with a massive upgrade plus three overall. And you look on the inside of the card stats here, this is where it starts to get interesting, even though he got a really nice upgrade. Take a look at his foot fantasy over his team of the season, right? He has plus 16 curve and plus seven vision on his foot fantasy. Also plus five balance over his team of the season card. And this is why Premier League team of the season. Makes no sense. If we take a look at a few more cards here, Harry Kane, well, some people are saying this card is absolutely cracked over his team of the year. Honorable mentions, which is a 92 rated a plus three overall upgrade. He got plus four pace, three shooting, four passing, four defense, four physical and three dribbling. But if you look into the end game stats, look at his agility and balance. 75 agility and 78 balance on his team of the season card. That is five less agility and seven less balance than his team of the year. Honorable mentions, his team, their honorable mentions is technically better dribbling in game, although it does have less reactions, ball control, dribbling and that stuff. But with some of these in game stats, it's so confusing why EA went out and did this yesterday. That's confusing point. Number one, why are they reducing some of the in game stats that they had boosted already? The only thought that I have for Harry Kane is maybe they were trying to keep him as a lengthy player. If they would have given him more than 84 agility, he would have no longer been lengthy, right? I guess you could look at that and say, maybe that's the reason why, but it still doesn't quite make sense, especially if you look at, I think it's Veran. Veran got like a balance downgrade as well from his winter wild cards. If you look at the in game stats, he had 48 balance. He has 48 balance on his team in the season moments. But then if you look at the 88 winter wild cards, Veran, he's got 60 balance. So literally a plus 12 difference there. It's just, it's very confusing why they did that on some of the in game stats in these cards. Like Otagard didn't get a composure upgrade on his card. So some of the in game stats are very confusing for these. And then overall, why does EA have something against Arsenal players, man? I mean, how in the world is Hyunmin Son and Rafael Veran just from a rating perspective, 94 rated Sonoldo, 94 rated Veran. But Otagard is 92. The same rating as Matoma and Saka is lower rated than Hyunmin Son. I'm so confused why EA did not boost up some of these Premier League team in the season cards. Now it does make sense in one sense because they don't want every single card in this team in the season to be mega overpriced. Like we were hoping Celeba was going to be like a 95 rated card. Right. Well, here he is as a 92 with such a small upgrade over his fantasy card. Here's another one with some in game stat differences. His fantasy cards got plus nine agility and plus two balance over his team of the season. But maybe that's what EA was going for here. Right. They wanted these cards to be the most used and popular and hype cards in this game. And to do that, I think they knew that if they gave them smaller upgrades, they would be cheaper on the market, more packable. And I think more people would end up having fun on this game, even though the upgrades are less hype, they would be able to use the brand new cards because the upgrades are smaller and that makes the prices cheaper. I really feel like that is one of the reasons why they didn't upgrade these cards that much. We were hoping for a higher rated Saliba, a higher rated Martinelli, Saka and Odegaard, like all of the Arsenal players, they're on the bench. Like it's crazy to see that. And I'm a Spurs fan and I'm just being honest and saying this that like, I think Saka deserved a higher rated card. 95 was necessary. I think Odegaard should have been a 94 as well with Casemiro. So that's where this team of the season for Premier League is just kind of baffling us and not making a whole lot of sense is why did EA choose to do this, specifically with the Arsenal cards, but with some of the team in general is just not boost them up that much. And I really do think it is because they wanted to make the cards more affordable. And in doing that, I mean, look, we've got an Odegaard that is 150,000 coins on the first or second day of team of the season. And that really affected prices yesterday, right? One guy that I invested in a lot, I invested in three Bruno Gamerash foot birthday because I thought, man, this new Bruno Gamerash is going to be like 95 rated. He's going to be very expensive.  So I'm going to go out and buy the old foot birthday. Well, you know how that happened, right? Yesterday, the new one came out and the price range was so low, it's only a plus two. So instead of going up in price, this Bruno Gamerash is down loads. He's 300,000 coins after he was 430K. I'm losing coins here on this card. And I'm sure a lot of you guys are as well because that was a very popular investment. Now the upside to this Bruno Gamerash is he's got five star skills. The new team, the season one does not, but that does not make up for the fact that the new one impacts with the cool design dynamic and better stats overall is impacting this foot birthday's price on the market. So that was kind of the chaos of what this market saw yesterday with those cards being a lot cheaper than expected and also having smaller upgrades and expected on some of the players, it made some prices on this market actually go down like we talked about Bruno Gamerash. Saliba's fantasy went down. There are a number of examples of cards that went lower because the new card that came out was not as good and it was cheaper in price than what we really expected it to be. Right. So as expected as well, these cards did start really low first hour. I bought Saka for 720 and 740 in the first hour. He went all the way up to 900K. I sold a little bit early. Yesterday was a really good day of profits as well. Let's see who else did I make profit on in here. A couple of losses in here, but Nunez was 470. He bought this at 400. I bought this at 325. I bought all these Fofanas at 160. That was a really good flip there. And I still have some of the cards that I bought because, you know, prices went really, really high as expected yesterday as people went out and started to buy teams for their week in the games. Now with these Tots cards being so cheap though, looking forward into today on Saturday, this is a big point that I really want to bring up. Guys, these prices are really going to impact the rest of the market now for the next couple of days. It's going to make a lot of the rest of the market, I think, come down in price because these guys are just so cheap and people are going to want to try these cards.  Now yesterday, some primarily special cards we expected to go back up did. Darwin Nunez was 400,000 coins. He went all the way back up to like 450, 460. But look at him now. He's back down to 400,000 coins because all these new cards came out that are really cheap and people are trying them instead of these out of packed special cards. I bought two Esau yesterday with the release of Alan St. Maxim and right here at 400,000 coins. He went all the way back to 450. I was listening to mine at 470. Look, he's back down to 400k. Not all these guys are just going to keep going down. I do believe today the market on Saturday, people will wake up and want to play games and these prices will go back up on Premier League Tots cards specifically. They've already started to go back up, right? I bought three Rubin Diaz on my transfer list right now for 830, 820,000 coins. He's already up 100k, right? There's going to be some really good flips with these Tots cards today and some of the Premier League out of packed specials that have come down late Friday night into Saturday morning. There's going to be some price rises on these cards again, but take a look at some of these other cards that are not Premier League that are in the bin right now. Marcus Llorente, 565,000 coins yesterday. He was 700k. There are cards everywhere on this game that are down bad from where they were because they are not Premier League. If you look at Kingsley Coman, this is directly affected, of course, by the Allen Saint-Maximin. Kingsley Coman yesterday went down to 480, went all the way back up to 540. He's 452,000 coins right now in a card that just went out of packs. If we go back and kind of look at some other like foot birthday cards even, you can see that Nunez was back down. There was one card I wanted to take a look at here. It was actually Genduzzi. Genduzzi is 360k, a card yesterday that was 400,000 coins. He is dropping down a price. There again, like I said, are a lot of cards from non-Premier League links and non-Premier League players that are down a lot in price because people are building Premier League teams for the Cup and of course to try out some of these brand new cards. Emery Chan's 100,000 coins like he is down horrendous, man. He was 150k yesterday and now he's 100,000 coins. And Bundesliga team this season is coming up next week. That's a card to kind of keep in mind. Oh my goodness. Eden Hazard is 245. He's down like 100k. He was 340 yesterday. So some of these prices are down so much because this Premier League tots is so cheap and a lot of people want to try out these players and at the same time, it's just pushing all of the hype into the Premier League links and that's the cards that people are buying. So that's kind of the story of the market right now. The market is just kind of a mess, right? It was really easy to make coins yesterday. Like we expected, these tots cards were very cheap in the first hour. As we mentioned, like I bought soccer for was it the 740,000 coins? He went to 900k. He did, of course, come back down into the late nine hours. And right now he's 750 coming back up again into Saturday morning. So watch out for these Prem tots cards. There's going to be fluctuations, but they'll probably be just like we see every single week. These Prem tots cards will probably drop down further into the night tonight and Saturday. So if you're going to try them out today, just don't hold on to them for long. Their prices will probably continue dropping into the latter part of tonight. Now let's talk more about today on Saturday. What else is going to go on in this game? First of all, we have got to check out the challenge SPC that's going to be dropping today. Remember what happened last Saturday? We had the Prem challenge to SPC that dropped that five rare Dutch gold players pack that crashed all of the Dutch player prices on this game inside of this game today. We are going to see Tots season swap challenge number four. And what this pack or what this SPC could give us, it's not a guarantee, but what it could give us is that eight players Premier League player pack SPC that they dropped with Tots challenge. I think it was three or I don't even know which one it was, but whatever Tots challenge we get today, watch out for that eight Premier League players pack tradable. If they do that, which I think is maybe even one of the rewards inside of the craft of glory. Yeah, the eight Premier League players pack, if they do that and it is tradable, that could mean some supply heading on to the game for those team of the season cards that are right now in the Premier League Tots. So watch out for that. That's an SPC we know is coming today. And then guys, we have to look at SPC fodder, man, because these prices are some of the lowest prices we have ever seen on this game. 85 rated cards are 6000 coins. That is legit the lowest. I think they've just about ever been since the beginning of the game when 85 and nobody had coins at the beginning of the game.  But the entire fodder market is so low, it's wild. Now, if I were telling you to buy any rating of fodder right now, what would I tell you? I'd say 83s, 84s and 85s because once again, if we have some sort of SPC come out today, I don't think it's out of question, by the way, to have an icon pack dropped on the game today because one common theme that we have had recently is EA has been going back and forth between icon upgrade pack and a hero player pick. And we have this hero player pick that's expiring tomorrow. But they've been after a hero player pick. Sometimes they've come back with a really quick Saturday release of an icon pack. So watch out for an icon pack today. If that does happen, that could make some fodder finally move. But guys, basically anything that is 83 to 86, if you want to do a quick club stock, be my guest because these prices are crazy. Even 91s. I know we got team of the season cards that are impacts and that's really hurting the supply and the prices of these higher rated Tots cards. And we're probably going to have EFL team of the season cards coming into this game tomorrow on Sunday, or maybe on Monday, that could bring some more higher rated Tots cards to bring the fodder market down a little bit even more. But if I were you guys, I would club stock 83s to 86s just because they're going to be needed in this upcoming week, whether it's player SBCs, whether it's an icon pack that comes today tomorrow on Monday, they're going to be needed at least a little bit, specifically the 83s to the 85s. And man, 84s, I think have the best ROI potential if there's going to be anything that makes them go up. I mean, the gap between 84s to 85s is still about 3000 coins. That's a really good profit range there. I mean, 85s and 86s are so close in price. That could mean they don't go up as much. But then you've got 87s or 12k, 88s or 18k. It's crazy right now for fodder. So at the very least, I think these are going to be some of the cheapest fodder prices that we see for the rest of the year on this game. It's not going to get too much cheaper than this because think about it. All you had yesterday was pack supply, pack supply, pack supply, people opening packs for Premier League team this season. And now it's time for EA to start releasing SBCs to try to drain that away, drain coins out of this game once again, to get people to keep opening packs. And I think they're going to do that today. So whether it's an icon SBC, or whether we see one of those flashback player SBCs, or Ali Sun, this is one toss card we have no news about yet. He could be an SBC, he could be an objective. Don't know about Ali Sun yet. That's something to keep in mind. But last Saturday, we also had a flashback to Lofei, I think today could be a Havertz day or La Porte day since we didn't have Havertz yesterday. I kind of thought he might have been then. But looks like EA are maybe going with the Saturday flashback trend with Havertz and or La Porte today. That would of course be a big SBC depending on the price, depending on the stats. We've talked about it already. But watch out for your Prem Center backs or Prem strikers slash attackers and links to that SBC. If either of those were to drop on this game today. So club stock fodder. And if you really want to go in crazy, get on the gold rares, gold rares at 650 are a very easy club stock their minimum price. Fill up your club if you want to go on assigned do it because these cards are going to go up probably to like 850 900 maybe even 1000 coins plus later on this week when the Premier League upgrade packs get dropped because it's going to be a coin drain span. Everybody do an upgrade packs to try to pack team this season cards. So that's kind of what's going on in this game. If you enjoy the video today, drop a thumbs up on a comment level if you have any questions and subscribe if you're new. I'll see you guys on a twitch stream today. Yeah, you heard it today on a Saturday. We're playing weekend league watching prices and just seeing what EA dropped today on a Saturday. So if you're excited for that drop through, come through link is down below in the description. But I'll see you guys there. It's been named for the counter. Catch you guys later. Peace out.


Good afternoon. Good evening, everyone. Welcome to the last session of Automotive Linux Summit. This is the one you've all been waiting for, the AGL developer, Birds of a Feather session. Quack, quack, quack. Okay. So who is this guy? Hope maybe you already know me, but I've been the Linux Foundation Community and Development Manager since 2014. That's me when I rode my motorcycle from Chicago to San Diego for Open Source Summit North America. And also recently, I have achieved Junior Sushi Chef Certification. And I have an official, I have a certificate. Okay. And then there's another guy who's doing this. Scott, don't worry about him. He's right here. Let's segue here. So Scott Murray, I work for a Invented Linux Consulting Company called Consolco Group. We've had a contract for many years now to help with AGL. I'm a developer that's sort of responsible for a variety of things in AGL. You might have seen me doing connectivity stuff recently with Cookset.File and VSS and VIS and things like the networking and Bluetooth, all that stuff. Also help out with the Yachto maintenance. So like the sort of upgrade process to take us from Dunfeld to Kirkstone and, you know, sort of some ongoing stuff in that space. I do a lot of the CES demo integration. So it's been interesting this year because I'm out of practice basically. I haven't done it for two and a half years. So we were, you know, picking up the pieces this year and moving forward to CES in a couple of weeks. And, you know, Walt's been generous and said much, much more. So I am kind of a jack of all trades. If you jump on most of the expert group calls, I'm on them the same way that Walt and Yen Simone are. So if you have a generic question about AGL, you know, I'm also one of the people that can probably help you. And Scott is not a budding sushi chef. They invited me, but I didn't go. He refused to become a sushi chef. So look for that on LinkedIn. So just a couple of slides of introduction. Some of these, if you were at my session the other day, will be familiar. Basically, really quickly, we had, you know, we've got all of our releases are named after fishes. Lamprey release 12 is our first kind of LTS version. We're now tracking along with the Yachto LTS. Dunfell releases. And we'll continue to update every two months or so as Dunfell releases come out at least until 2024, which is when they're scheduled to end. They extended it. It was originally two years. They extended it two years. Lamprey is also the final release with the legacy AGL app framework included. We removed, we deprecated all that after Lamprey. And now in Needlefish, we have basically replaced the previous, the old AGL app, reference apps and service binders and bindings with something new. We replaced the vehicle signal manager that was really heavily intertwined with the old, the old app framework. And now we've replaced that with Cuxa.Val, which uses the vehicle, VSS from Covisa. We're now tracking the new Yachto LTS, which is Dunfell. Kirkstone. Sorry. And we're now using system D units for app management. That's really the quick overview of where we are. And then I just wanted to show a couple slides in 23. So we're going to do Optimistic Octopus after CES. Basically, that should include all of our CES reference app updates and service updates. And whatever the latest Yachto is on Dunfell, on Kirkstone. And then so this is the schedule for the rest of the year. I know people get excited to learn what the new fish are. So the new fish are going to be prickly pike after Optimistic Octopus. And I'll bet you didn't know there was a fish that started with the letter Q, but there are some. And so we will have the quirky quillback coming in early 2024. So I'm going to put these slides up that you don't have to worry about basically a few more schedule slides, the schedules on the wiki page. And as usual, we have our weekly developer call on Tuesdays. Anybody is free to join. We're all on IRC. And we have our community mailing list. You can mail any questions or thoughts or whatever. You'll also get information, notice about releases and meeting updates and what not. All on that mailing list. So. And I'll point out the list.automotive.com. When you use the web interface like this, there's also a link to the calendar. Yes. That's the most up to date source of the calendar for meetings. Yeah. The calendar here is canonical, I guess, is the best way to put it. So with that, birds of a feather session, I'll open it up to any questions or great thoughts or anything else. Yeah. We have a mic here. Very quick question. Can you say a little more about how you're incorporating VSS? Step in since I've done all the work for it. So when we replaced or removed the old application framework, it had a couple of bindings with APIs for, you know, there's like a can interface and it had its, you know, it was derived from OpenXC, which forwarded release some stuff. And the issue that was partially that was there was no community revolved around OpenXC and all the XML can definitions with it. And we were the only people that I'm aware of that were really using it in open source. And it was really difficult for anybody jumping in to do can stuff in AGL that wanted to demo or experiment to use that because there's, you know, like we're the only people using it. And so that was one of the motivations when we did sort of remove the app framework that said, you know, instead of just taking that code and beating it into some new form to use it in the new, you know, post app framework world is maybe we rethink things. And it happened to me at the time I was looking around and I saw that, you know, Covisa had engaged W3C to start to standardize the VSS and VIS. So for maybe just high level a couple of minutes here, the VIS is Vehicle Information Service. So that's a server that exposes the data and VSS is Vehicle Signaling Specification if I have those right. And so it basically you think of it as a tree, a hierarchy of signal definitions. So you have vehicle cabin, you know, vehicle powertrain. And so you can build down and it's, you know, there is an open source project on GitHub where they basically have a metadata description that they generate the hierarchy of signals and they do regular releases. So in the last, I don't know, I guess a few months they've gone from VSS 2.0 to VSS 3.0, which is based on various community members submitting new signal things and going through the review process. So there's been changes like in 3.0 and it actually affected us a little bit was one example thing was they simplified the powertrain. It had some redundant levels of nesting and they sort of simplified. So that's the kind of community aspect of that. It's an open source project which meshes well with us in AGL.  So that is the specification where we have this schema. Here's all the sort of signals. But then the VI asked the server to expose that. So to feed data in from sensors or, you know, can, for example, and actually have apps able to subscribe and do notifications, you need a server. So there is a reference implementation that's maintained, but it's almost a little less interesting to us.  It's very comprehensive and it is like, you know, it's a reference implementation. So it isn't quite as usable as what we did pick. So there's a project called Cooks.Val that Walt mentioned is another implementation of the IS specification. And so it's, you'll see Bosch are sort of the primary visible developers on that. There's a couple of different teams of Bosch contributing things to it. But there are other companies also contributing. When you go and look on the GitHub of it, there's, I think, Volkswagen and a few other, like Jaguar Land Rover and people like that. But, you know, we'll see a lot of development from Bosch. And we've spoken to the maintainer a couple of times. I join now the W3C calls for these things. And it's definitely, I would say, a good time for us to take it into AGL, because it's not just like a Kavusa project. It's a bigger thing that has a growing community. And we're able to demonstrate using it and integrating it into, you know, a product. And so at this point where I've, you know, done a couple of updates for now on a pretty recent version of Cookset.Val and AGL, and most like, I think pretty much all of our demo applications now have been converted to use it. And there's still work to be done there because the specification is WebSocket based, but Cookset.Val has gone a little bit beyond that and are using ProtoBuffers and GRPC, which is more interesting to us in AGL because it meshes better with a story of using, like, modern IPC in the vehicle. And ProtoBuffs by their nature are lend themselves to writing more robust code than WebSockets.  And the support for ProtoBuffs for things like Rust and Go and stuff is very good. And that's, I think, sees us into being able to have maybe down the road, maybe later in 2023 or maybe even in 2020 or start doing some more demos of things with, you know, these memory safe languages like Rust and, you know, work with some of the members. There are a number of companies that have started investing heavily and using things like Rust. And ProtoBuffs, I think, are a better story there because it's a first class citizen, you know, language for GRPC and ProtoBuffs. And it's, you know, much more secure by nature than WebSockets. So that's a bit of an evolution we will still continue on. And we'll keep enhancing the demos, wiring up more signals. There are a few things that I probably need to sit down and probably engage with the VSS folks a bit. There are signals that I think would probably be useful. So I have to actually find the time to actually maybe do a pull request or two against a spec and engage the community, which as anybody can do. So that's the beauty of it. Is anybody, you know, anybody who's interested in using this stuff, you can engage, you know, they have weekly calls, they have a mailing list and stuff as well. And it's, I think, I think it's going places and we'll see a lot more usage in the industry. So it's really become a big thing. And I think it's a good time, you know, we're maybe ahead of the curve actually, being able to demo using it. So I think that's great. So for whatever is worth in our project, we'll be collecting can traces and we'll, at least for the can traces we have DVCs, we'll convert them to VSS. And then potentially some of these traces might be used. Yeah, I mean, that's another application is that there are I think one of the demo feeder applications with Cuxa is essentially a replay tool. So you can feed just canned data in this one of the things that's what we're doing. But there's also a because they have a Python library to simplify using Cuxa from the client side. They also have that you can just record a set of signal updates and then play it back. So would be you would do that. But I think for new users, the VSS representation will be a lot easier to deal with. Yeah, yeah, it's the can signals are painful. Especially, I mean, I had to convert our stuff from open XC ish type of format that we were using with the old app framework to, you know, DVC. And there's some really interesting like bit position numbering stuff with DVC that, I mean, it wasn't entirely obvious in our old stuff, but it took me a few tries to get some of the signals right in with the DVC. So yeah, it's a little easier with just signal definitions. Quick question. So say I'm writing a survey, well, it's in the context of the removal of the application framework. If I'm writing a service that needs to expose capabilities to multiple applications or parts of the system. Is there a standard or recommended way to do this now from the previous conversation? I would kind of guess gRPC. Yeah, I mean, all the new stuff we're, you know, that I'm building for to sort of get us back to where we were with respect to the demo I'm doing with gRPC. I mean, we have just started on that. But it would be highly preferred this way. But I mean, we will take contributions if people are willing to maintain them. But it is, to some degree, there's some things that I think if we stay consistent and with, you know, things that are, you know, people intend to push as, you know, maybe demos or things that are appealing to people to pick up and use in production. There's some of the security stuff that we are, you know, at least hand wavy stages of how we would manage the credential stuff around gRPC. And I think if we can stay consistent and not have to worry about managing a bunch of different types of IPC mechanisms, then it'll be easier to make that, at least have a good story that is a starting point for people that want to pick it up. But ultimately, I guess people can do whatever they want. Oh, yeah, I mean, there is the Toyota based system code that's in Tree, which we don't use in the demo. It has all its own IPC mechanism. And there's a handful of libraries in there that leverage their IPC. But I mean, we're, you know, since we stepped back from the old app framework and we're trying to leverage as much open source that's out there, I mean, using things that are, you know, have big ecosystems like gRPC and have good stories around how do you secure these things, you know, and they're heavily used in the cloud, right? So we know that they're, you know, they're tested, right? So I think the best way to put it is we're moving from WebSockets being mandatory to gRPC and Protobufs being recommended. But you can bring in anything you want. But we're really intending to write everything in gRPC.  Because in five years, it's much more likely that even if it's not gRPC, the vast majority of things are probably going to be something like Protobufs or, you know, maybe one of the things that have evolved out of that, like flat buffers or something. Because if you're going to sit down and write something today and start running a new project in Rust or something using WebSockets, which just JSON doesn't make a lot of sense in my opinion, like you're going to use something that has inherent typing and stuff to make it as robust as possible. And so that's we're hoping to get that into people's minds, right, like by doing this. Any other questions? As long as we can ask you questions back. Yeah. So it is, okay. Very simple question. So what kind of another, how to collaborate with a different foundation project? For example, today and for the future. For example, CIP has a super long time support kernel. So how to collaborate with one extension. Another viewpoint, PyTorch is a very good project, the newest. So it's a machine learning project for that. So how about how to collaborate for the automotive industry areas. It's just an example, sorry. So I mean, in general, in general, once our members or advisory board, I mean, they're all, of course, free to join. Since we're all Linux Foundation members, you're all free to join any of the subprojects. Our advisory board has approved and we funded joining Alisa and Yachto. I think those are the only two at this point. But certainly, if the membership wanted us to join other projects, we could do that. I think the biggest thing is that the members have to commit to participating. Right now, with Yachto, definitely, we have a lot of good participation between Jan Simon and Scott and Renaissance and other people. Alisa, I would say our participation started off pretty strong and now it's kind of weakened. Our member companies aren't really participating so much. So definitely, but if there was another project like CIP or MicroPython or any of those other ones that we wanted to join where we felt that there was clear synergy with the automotive industry, we would do that. So yeah. I can comment on the two examples if you want a little bit. Well, I mean, both of them have some technical challenges where you need to be investment. It's not like we could just take the super LTS kernel and easily integrate it per se, at least I think, because as far as I know, it's very specific hardware support in it. So it would be a thing we could probably have as an option, but we would like to see member companies either contribute that or specifically ask the advisory board for it. And the PyTorch, as far as I know, it's non-trivial to build that, right? There's people in the OpticFeeding that regularly mention it. To build that in a way that you have a reproducible build of PyTorch is a complicated thing. So us doing that, even having it available for members to pick up out of the AGL tree, it would be a maintenance effort. So it's another thing when we like, if members want that, they really need to get engaged, I think. It's not just going to be the handsome owner. I just do it on a whim. It's going to be something that requires some investment time. Yeah. Thank you. Anybody else have a question? So AGL, you've got like 100 odd members or something, right? About 150? Yeah. So what kind of proportion of contributors do you actually get from those member companies? Like a lot of them putting forward developers to help on the project or a lot of these people just kind of give you a point? A lot of members are consuming and not upstreaming code. Quite frankly, I used to show a chart. I probably have the data somewhere on how many individuals were participating in any given year. Let's say typically 50 contributors a year. 50 individuals a year contribute code to AGL. And that's from maybe 20 companies. So there's a lot of companies that are consuming. It's always interesting, especially at a larger trade show like CES or Embedded World. We'll walk around and we'll see companies are clearly using the AGL demo.  Which is a problem with a lot of open source projects. It's one thing to be, it's like some dev board that's $50,000 or something that's fine. That's your project. But if it's something that, here it's on our dev board that we give out to our semiconductor customers, having that upstream in AGL is much better for everybody. But it's painful at times. You see this where some of these semiconductor companies are doing the work, but they don't contribute back. Generally in the automotive industry, there's the problem with the automotive OEMs and the tier ones don't know how to contribute back. And it's not that their individual developers don't know how. It's that their legal departments or their management doesn't allow them to because they don't understand the value and the benefit. And part of AGL's mission is, or part of my mission and Young Simon's mission, is to educate those companies as to what the value is to contributing back. So sometimes it's a legal battle. But some of our member companies have done a really good job of overcoming that. Panasonic, Toyota, Denso and a few others have really done a good job of figuring out how to how to contribute some of their code back to us. Anything else? Well, everybody enjoy ALS. Was it a good time? Everybody have a good time getting back together again after almost three years? I think we had fun. Don't forget there's the AGL face to face workshop tomorrow and Thursday if you're still in town and you want to join us we'll be in room 502 I think tomorrow. So before we wrap up one last call for questions. Thanks everybody and that's a wrap for ALS 2022.


morning. Let's roll. My name is Justin. A fun fact, I get paid by the tweet. So if you follow me on Twitter and say hello, I'd love that. Or if you want to drop me a long form line, you can reach me hello at testdouble.com. Open source is good, right? Companies working with competitors, other companies on common tools, and then turning around and sharing that for free. Startups, now they can stand on the shoulders of giants and build great new things with just adding a little code on top. Companies that couldn't exist otherwise. And then never before in the history of the universe has an individual that's not state sponsored or company sponsored been able to just do a little work of their own and then literally change how the world works. But is open source good really? I mean, companies love consuming open source, but if you ever want to share an upstream patch, much less open source library, they suddenly are very stingy and skeptical of this open source thing. And then a lot of startups keep falling into the same trap of hoovering up all of this free stuff without understanding how it works and building maintainability nightmares right as they get successful. They can't add new features anymore. And most of the maintainers I know are pretty burnt out, right? Like, they don't like the fact that they're doing something for fun and they're free time, companies are running on that stuff and then expecting customer support, you know, on nights and weekends. So today my goal is just to bring to light a handful of issues affecting open source. And my only objective here is to encourage you to do the same thing. Because maybe if we can start to build a broader awareness of some of the systemic issues in open source, we can start to have ideas of how to fix them. And then maybe somebody will come along, start to create new creative solutions for those things and then we can, you know, start to live and realize the promise of true openness, whatever that means. And then we're done. But again, today, very little minor, just looking at a handful of things. Topics, such as dependencies. Pulling back the curtain a little bit to show what it's like to be a maintainer. Issues of trust, adoption, security. And then some deep thoughts about how we interact with each other as humans, as well as where I think the future is heading. I like to start off with term definition, the word ideology. Most of us think of the word ideology as like a political subscription or affiliation, what you believe. But I like this definition more. They do not know it, what they are doing it. Ideology as the negative space that's driving our actions without us even realizing it. It's a quote from a dude named Karl Marx.  That comes from the book Capital. And Capital is an interesting book because as a work it sits at the intersection between philosophy and economics. I think it's an interesting subject to start with today because so does open source, right? We share all this code altruistically as if to earn karma from people we don't know. And yet there's all these companies out there making a bucketloads of money off of open source and every company that even doesn't contribute open source needs it to get by. So thinking of capital and traditional economies I want to look, chart the march of progress of economics. In the beginning, everything was shitty. Everyone was just trying to get by, survival day to day. But then as groups of people started to form, specialization emerged. You could go to one market for your veggies and another person for your meats and through efficiency is this opened the door to the development of human culture. Recreation and art emerged. Industrialization further optimized this because now we could go to one place and get all kinds of goods. The internet totally inverted that. So now from my bed on my iPad I can order things from anywhere in the world and have it all shipped to my door. This is progress. But where does it lead us? You know this year there were rumors that Amazon is actually using big data to predict what they're going to buy before you click one click and they're actually shipping it to distribution centers near you in advance so that they can send it to you the same day or the next day. And some people are starting to ask questions like is this march of progress actually somehow taking away something about that's been core to the human experience? So it's an unintended consequence. Another example of unintended consequences in the like progress of economics, food ink, right? This documentary was a big hit and look at that aggressive tagline. You'll never look at it again or the same way. But I think it would be more honest if that said for like at least a month. Because we can't change these. These are systemic issues. When you chart progress over time there's a natural accretion of awfulness. It just mounts up until it gets to a point where we all freak out about it. And when we freak out about it we think we're going to fix this, right? But we can't just turn on a dime. Nothing stops this strain. It's going to keep on getting worse before it gets better and maybe we can rein it into current panic levels layer. Speaking of awfulness, let's chart the same march of progress about all of the tools that we use to suck in new dependencies from the open source world. So charting open source is progress over time. In the beginning there was just files out there on the internet. And so if I wanted to like build a system and pull in some open source I'd have to go find it first, download it, and then literally like check it into my version control, depend on it. And then logically it kind of continued on as part of my application. If it broke I had to fix it. And that was a guard against pulling in too much because I didn't understand it. And it was just more and more for me to maintain. Make files and common build system tools emerged as a great way to depend on stuff logically. So now I could build an application and depend on something like libxml. And it could be built on each of the systems that needed to be able to compile. But it existed as a separate entity. I could upgrade it separately and I could view it as apart from my application code. Java and its jar files were another great innovation because now instead of having all these build systems configured appropriately a single compiled byte code could be distributed and then run anywhere. So with Java I could literally go to a website, download a jar, put it on my class path and it would work. And this was so convenient that it actually opened the door to those same sites saying oh and by the way we depend on this third thing. That's what we call a transitive dependency. And what that allowed was really all of these libraries that we depend on to become small, more focused. And even you know when you think of transitive dependencies like Apache Commons emerged as almost an alternative language stack within a language ecosystem. It was extremely novel. Ruby you guys have done great work making this even easier with Ruby gems and bundler. Now when I'm writing my gem file I only say the things that I explicitly depend on and those transitive dependencies are discovered for me and their version resolution is handled for me automatically without me even knowing. And I can have arbitrarily deep dependency graphs only really thinking about the stuff that I directly depend on. NPM has just taken this a step further because the Node.js runtime doesn't require it allows you to load the same library multiple times in a single process which means I declare my dependencies and then it just naively sucks up all the dependencies of my dependencies and so on and so forth to these gigantic trees and it gets really broad and really deep. Up to the point where a very common thing for a Node.js library to run into is support ticket saying hey I can't install this because it's literally longer than the Windows Max file path limit of 256 characters. Wish that was a joke. This march of progress is optimizing for convenience. Getting somewhere more quickly. It's short term progress and it's available to us for the low low price of long term fragility. The comedian Louis CK talked about this recently. It's true everything that makes you happy is going to end at some point and nothing good ends well. It's like if you buy a puppy you're bringing it home to your family saying hey look everyone we're all going to cry soon look at what I brought home. I brought home us crying in a few years. Here we go. Count down to sorrow with a puppy Our community's Louis CK a guy named Gary he told me to build a small but non-trivial Rails app. An empty app will have 50 gems but yours will end up with 75 to 100. Now go away for six months come back update all your dependencies. Your app no longer works. I know from experience in the Ruby community that this is true. But it's easy to start a Jekyll blog. It's easy to install SaaS. It's easy to generate a Rails app. It's always easy right now never in a year. The reason I think is that when somebody asks us what our application is we think of the code that we write as being our application even though upon inspection all of us would agree that our app is really the full stack of everything that we ship into production. It's never been easier to ship something to production but the things that we're shipping to production have never been more complex. I'm guilty of this all the time. I say oh it's a Rails app because it conveys a lot of information all at once. I never think to say oh when Rails depends on Thor this very specific I don't even notice that. I didn't even know it until I made that slide. Even though 272 gems can no longer be installed in the same project because of version resolution complex. So Bundler it hides some of this from us. I think it could actually promote some of this information. It could tell us hey we just installed 10 direct dependencies and that conferred 43 transitive ones. Or I could say the version specifiers and all those gems preclude the installation of 1,300 other gems out of our ecosystem of 88,000. It could tell us hey and by the way if you were to run Bundle update right now it would be unable to update 5 gems to their latest version. I'd love to know that proactively. Of course if you're an NPM, a Node.js fan you might point out haha, version resolution doesn't affect NPM and you're right. But there's other issues. I can depend directly like so let's pretend orange triangle is a dependency. I might directly depend on version C of it. One of my dependencies might depend on version B and one of its dependencies might depend on version A all at the same time. This is all well and good until I start to think about it. What if I call my triangle and it gives me back a domain model object at version C's library understanding and I foolishly admittedly I pass that into my dependency who passes that into version B of the same dependency. As a library author did I think about that when I was writing the library that that was possible? Probably not.  The answer is nobody knows. And that's not great for understanding the software that we're building. Another issue is that as a library author I can specify the exact version that I want of something but I can't control the specification underneath. So if orange triangle depends on a very loose specifier of like red square for example at version star which means that the users install time they're just going to get the latest and greatest version. Things could potentially break. In fact one day we just started to get issues that every new installation was failing and we hadn't changed anything for like a month. What had happened was one of our direct dependencies broke because it had too loose of a version specifier on something else and so there was a breaking API change and then to fix it we realized that because the maintainer was out to lunch we actually had to fork that dependency and then specify explicitly I want version D the last compatible version of this thing and then push up a new version of lineman to NPM and now we're saddled with the maintenance and ownership of this NPM module that we don't understand that we'll never look at that if there's a security thing or whatever we're just it's just baggage now. Here's a video that the team took in me that weekend I feel like that a lot. So we all understand that the code that we write for applications is the code that we need and the code that we depend on directly is there for convenience to help us get started and so I think that's why I think a lot of people have been lampooning the phrase full stack developer this year because nobody knows everything that they're shipping anymore. So this makes me long for the good old days sometimes of like make files. Sure they were pretty good. So I think that's why a lot of people don't know what to do. They don't know what to do. They don't know what to do. They don't know what to do. So I think that's why a lot of people are like multi-file developers when we're doing an application like make files. Sure they were painful but maybe that was a healthy pain. 30 years later a lot of these old C projects still build correctly. Now who's confident that when I run npm install on my project 30 years from now it's still going to work. Let's talk a little bit about all these people ruining everything like me open source maintainers. way I envision it is that a maintainer is on Google looking for the thing that they need and then realize, oh, it doesn't exist yet. I'll turn around and go make this thing and work in the open and share it. An early adopter, and slightly less so, might just Google the same thing the next day and then find it. And then their reaction might be, oh, sweet, I found this cool brand new thing. I'm going to go share it on Hacker News and talk about it because it's still hip and underground. It's like finding a cool indie band that you want to share with people. And this starts putting the maintainer up on a pedestal, right?  But because they're on that pedestal, other people on Hacker News don't mind at all pointing out, oh, it doesn't do X or Y or Z. And now the maintainer realizes their ego is all wrapped up in the adoption of their tool. But because early adopters are usually just as competent as maintainers at building stuff, maybe they'll send in pull requests that fix those issues. And now the maintainer is really happy again. It's super up and down. The initial release of any new library, new open source stuff is usually just scratching the itch of a person who has a need. So there's going to be rough edges. And early adopters are great because they, as developers, often will send in pull requests or submit issues to help round things out. And what emerges is usually like something that's pretty ready to be consumed by the masses. Maybe you call that a version 1.0 candidate. Or if you're like afraid of the implications of what 1.0 means in semantic versioning like I am, that's your version 08040. So at this point, I'd love for the conversation to happen between maintainers and early adopters. You know, sharing ownership, hey, let's own this thing together so that the early adopter can broaden the contribution base of this project. That typically doesn't happen. I'd even settle for just a maintainer saying, hey, let's make you a committer. That way you get notification of issues and stuff. And early adopter agrees that they'll help sometimes. But because those conversations don't happen at this point, the maintainer may as well be saying, hey, let's never communicate again. Sounds good. Bye forever. And then they're off to the next thing. Because early adopters are always after the new shiny. So why don't maintainers just share control? Well, I think the reason is that they misjudge how much happiness this library is going to bring them. Because up until now, they got to scratch their own itch and build a thing, and that was fun. And then they started to get acknowledgment for it, and that was great. Then they got to version 1, and now they can only imagine the skies of the limit. This thing's going to make me super happy. I'm going to be like DHH, and people are going to start holding conferences after me. Fear not, because late adopters will disabuse them of this happiness. So from the maintainer's perspective, if it scratched their itch initially, version 1 is probably mature enough to do what they need. So they might go a week without any commits or activity. They might go a month. And because they're also like early adopters, some new shiny thing's going to come along, and that might distract them and then whisk them away. And they're off into the next thing. A late adopter sees that, and then their response is usually excitement to say, oh, look, no recent commits. This must be stable. 800 stars. This sounds like a safe bet. Open source, that's free, that's good. And so they're very often, from years old projects, I'll get an email being like, oh, we're so glad we found this, thanks. So maintainers' needs start small, but then we layer them on, round things out. And if we conceive of each library as a thing, and then we layer on top of it what a user needs, what I need out of that library, it's never a perfect fit. There's going to be some things I wish that library did that it doesn't do. And in that gap becomes a negotiation. I have to ask the question, well, do I submit a PR for this? Do I work around it? Do I open an issue and ask them to implement a feature for me? And so a lot of those late adopters, like literally two days later, will come to the project, put a stern look on their face, and then start saying, wait a second, this thing doesn't enterprise my enterprise thing at all. How could they ignore such an obvious and important use case? And so this is where like entitled GitHub issues come from. Missing obvious and important feature, well, you know, our team thought this was a real written and good library, except that it doesn't do this crazy nonsense. And so I try to be polite and I respond like, I didn't know it had to do crazy nonsense. Could you please explain? But instead of a real reason to conversation, all their coworkers just jump in and start plus oneing it. And the implication is that I'm bad and I should feel bad for not doing this stuff for them and having anticipated their needs. So odds are it's a weekend, I'm at the park with my wife, I'm having a beautiful day, and now I'm glued to my phone getting really nervous and feeling inadequate. So I run home real quick and I start working, hacking, hacking, hacking and the stuff. I come back and I'm like, Hey guys, I just spent all weekend building this thing. Can somebody please just verify it works? So I can close out the issue. And now what happens at this step? I never hear from them again. And now I have a sad because I just did all this work for free for strangers that they didn't appreciate that they might not ever use. And now I'm saddled with it forever. And I'm gonna have to work around that little edge case in my code going forward and make the thing that I love less maintainable. So this is how the, you know, projects tend to bring me less happiness as a maintainer over time to the point where I hate most of my projects after they're three years old or more. So late adopters, you know, because these well rounded version one things do the happy path well enough late adopters typically are when they're asking for something they're asking for more niche features than early adopters. This leads a lot of people in our community to assume that late adopters make better customers than users. And that's why you see things like donate buttons, people talking about dual licensing, GPL plus commercial pro feature add-on packs that they can pay for maybe paid support contracts or consulting hours. All of this I think kind of misses the point because it's a motivation impedance mismatch here. People are building open source out of intrinsic motivation and drive that they have and money isn't going to solve that problem. And so if you want an open source library to do something and the other person doesn't just throwing money out isn't going to make them any more motivated to do it necessarily. I would much rather if culturally we all got in the habit of letting maintainers feel free to say no. I feel like a jerk when I say no I can't do this feature for free for you. But even now like when I ask for a pull request or something like that what I really want to say often is like I don't think that this is a good idea for the curation of this library long term I'm sorry.  But I think that we'd be all a lot healthier if we were a little bit less entitled when we opened an issue we were more complimentary and asking for advice on how they might approach the same problem instead of assuming that the library needs more code in it. Trolls are a totally different category of people who make us unhappy.  And so remember maintainers they're not rock stars. But because of the asymmetry right like a lot of famous maintainers have 15,000 followers on Twitter we assume that they have their stuff together and we might even understand like well if they got that many followers there's probably a couple of trolls in the room but it's not that big of a deal. But because the asymmetric nature of communication we don't see the fact if those trolls are the overwhelming majority of who's interacting with them on the internet. And they have an outsized impact on a lot of open source developer psyche. So when the maintainer quits we're all like whoa that's weird that's what happened I didn't see any of that. Seth Varga recently left the chef project he was a great contributor did a lot of awesome stuff but just a handful of trolls in the community were able to sap all the joy that he had from that project. Further making us sad and so maintainers at this point this is where I often see the cries for help saying hey I'm burnt out can somebody please help me maintain this thing that has all these features that nobody wants anymore. Hello anybody and at this point no one's there right the late the early adopters who might have helped you know are long gone at this point and this is exactly how a lot of projects stagnate and die. But even well maintained projects up until you know by maintainers who do all the things right no maintainer lasts forever big invisible one this year was TJ Holloway Chuck left no JS for go and in the process he handed off a lot of his like infinity billion npm modules to other maintainers but he actually sold express JS to strong loop even though he wasn't the primary maintainer on anymore and he didn't tell any of the maintainers so it's really easy to screw this up why of course you know beloved in our community he left and he had every right to close down all of the stuff and leave and because he was highly visible we all had forks of his stuff and we're able to put it all back together again but that's not true of most maintainers so I like to think like what if there was an application for this that recognize that it's very human very natural for people to leave and stop contributing at a certain point and I think it would be need to be able to broaden the base of people are contributing so like what if I had a service where I could authorize Ruby jams and npm and github and it would like aggregate all of my projects and I could actually like explicitly say I need help on this one and here's the type of help that I need that way when somebody goes and logs in there's like a dashboard where they can see all the projects that they use that have asked for help in specific ways and then a call to action to say yes I'll offer to do that that's a lot strikes me is way more successful than just sending off an email in the dark to a maintainer being like I like your thing can I help you the reason that I did this talk today the reason that I thought to put it together was because our our our friend and beloved colleague Jim Wyrick passed away and when Jim died I thought a lot of things and it was very hard on me but one of the things I thought about was like he's got this tremendous legacy and I want to see if I can help in particular I have a favorite gem of his is our spec given and I wanted to see if I could go about helping adopt it and that process was very complex and difficult and I made me realize that when people go to their lawyer to do a state planning very few people ask like well what's going to happen to my github repositories when I die and even if they had the law hasn't really caught up to technology and it never will but maybe we can work around this so an application like this that already has all of our authorizations could effectively serve as a dead man's switch that is like if you fall off the pedal the train stops so maybe I could list beneficiaries like Todd and Brandon and after you know I go absent for a certain amount of time maybe it sends me little tickler emails every month and if I go away for 60 days it knows to add Todd and Brandon as owners on all of the projects that I that I've authorized it to I by the way I like to come up with a name for a thing before I build the thing I'm not going to build this but I like to call it somebody please make this dot IO really somebody please make this I would be very appreciative so that's all that's just about dependencies that are like you know binary dependencies or runtime dependencies that we package with our applications what about all these cloud services that we use right this slide is a slide of services that are going to shut down someday next slide can any centralized service probably written volunteer on on less money you know the if the corporate ones are all going to shut down what about the the purportedly open ones and can they be truly open like a maximally open system is rife for abuse but if you make it too curated then it could exclude people and limit the amount of contribution and I ask this of course because almost all open source infrastructure is entirely centralized out of convenience right because the march of progress just wants to make easier and easier to adopt stuff it's a hard question to answer how do we decentralize this you know a lot of people in the room contribute to ruby gems and I think they do great work and I think they're underappreciated but what if ruby gems were to disappear how many businesses with that effect do the businesses relying on ruby gems realize that as liability what if npm were to fail and lose a month of backups how many things would no longer be able to install and work I ask the question because I want to know like what would a decentralized dependency service maybe look like we have bit torrent apparently right we have cryptography it seems like the sort of thing that we'd be able to figure out without having a single point of failure speaking of single points of failure one of my favorite things to do is wait until the next time GitHub goes down because people freak out on Twitter and then they make the kind of snarky joke of like well you know it's distributed so why do you guys care because I can still work locally and in fact I can SSH to my buddy and we can still collaborate good thing that's all we use GitHub for right it's not like we use GitHub to pull down our dependencies or we use GitHub to test all of our code or we use services that get that depend on GitHub to analyze all of our code we even have most of the continuous delivery services that ship our code also depend on GitHub being up and even if you finish your work your next issue is in GitHub issues because that runs on GitHub and you can't find the next thing to do because now it was also co-opted all of our project management so how can we connect numerous services to our code which is admittedly the source of record the thing that everyone's going to want to integrate with but still avoiding that single point of failure well fortunately Git is very fast and very portable and it seems to me like a distributed transport layer or mechanism that would let these people hook into it without having a single company needing to be up for everything that we do to work seems possible somebody please build this let's talk about trust so open source requires adoption obviously it's optimized for it and in order to adopt something people have to trust it's good now there's explicit trust which is the dependencies that we directly depend on but there's also implicit trust the stuff that they depend on we just sort of trust that the people we trust are trusting the right people etc it's a big web but as a maintainer how do I get people to trust me and use my thing the answer of course is marketing let's look at marketing over time in open source so consider linus twervold 1991 announcement of linux he did it on the minix mailing list here it is and look at it got a few paragraphs but no catchy name he makes a self-deprecating remark in the first line and then he goes totally off message and talks about how to work on his niche particular hard drive this is bad marketing linux if it were announced today this thing runs most of the servers in the world it wouldn't even make the front page of hacker news if it came out today I think that's reason for pause a decade later the the ant project for Java this is trying to get into a lot of big corporate environments that don't trust open source look at all the things they had to do they had a fancy logo look at all this website stuff they had a mission statement and then of course the apache they had a foundation affiliation to try to confer trust but the more dependencies that were hoovering up over time the less we less time we have to vet them and so nowadays the standard github markdown read me is expected and here you know you expect a quick catchy intro a whole bunch of real easy steps to get started and then some mostly green badges up at the top to tell you things are working and it's gotten even further because now there's all these corporate backed sponsored projects this one is a yeoman where a diverse group of engineers are building a rocket with gradients and an authoritative tagline and they even have like a one liner install with a wizard that walks you through how to generate a thousand different types of projects it's a bad idea separate talk everything in open sources optimized for adoption it's the natural selective pressure that we're under as maintainers you know so we have all these like rock stars people in the community we look up to you like when Aaron Patterson releases a new gem I trust Aaron I know he's you know good at programming codes and so I trust that his gems are gonna work I could look at how many stars or how many forks a project has I could look at how much activity there is how many open issues I can see how many times that projects been downloaded now even though 90% of those are Travis see I downloading them over and over again my lizard brain tells me it's still important semantic versioning we went like 40 years without any sort of like you know like proper formal way of versioning software but why did we need one now the answer is we have so little time to like that our dependencies that we need to know at a glance like is this ready for use or is this safe to update and who's got time to vet transitive dependencies nobody the more people that you explicitly trust the more people you don't even realize that you're trusting I encourage everyone to recognize to that all these projects are marketing to you like I write open source and I want people to use it because I love it and I'm passionate about I want you to engage with my brand and use my stuff but I hope that you have ahead of discernment on and you realize that every new thing you pull in it adds complexity to what you're doing and more stuff can fail speaking of failures let's talk about security I actually have been for a long time a believer that you can do worse than security through obscurity you could have a whole bunch of stuff up in the open and nobody working to secure it cross the free software foundation point out well open source code is accessible to everyone right the cathedral in the bizarre argument of like many eyes and shallow bugs but that's only technically true people have to read the code for that to be true so who reads the source code first of all there's the people who claim to read the source code and then there's tiny minority of them who actually do there's people who fork projects but so few people who fork do anything there's the people with commit rights but then the actual committers are usually only a handful of that there's people who send a pull request but only a handful of pull requests or anything more than just drive by single tactical things and then there's the people who are hunting for exploits this is the only community where a hundred percent of them you can rely on reading the code so in absolute terms an uncomfortable proportion of people reading the source code are actually out to exploit it bash is a computer program it's in everything and the internet of things all those things run bash like your smart fridge etc so it's kind of unfortunate that bash had a terribly big security exploit because a lot of those things are not upgradable and patchable somebody went and looked at that code and what they saw was shocked to them it was global variables everywhere there was all these void methods that took no arguments basically that means that all that method could possibly do is A nothing or B muck with global state and then here's the vulnerable function I'll give you a second if this looks like nonsense to you I agree let's just read we're going to read a line of open source as a group this is the beginning of a for loop and I look at this and I'm a ruby so I don't spend a lot of time with for loops but I look at this I'm like why does that called string index why are they doing assignment in the second thing instead of a Boolean operation why are they incrementing in the second clause instead of the third clause surely they did that for a reason I think because I would write that like this and so I always trust I always assume that the person who wrote some other codes as smart or smarter than me so clearly they must have done that for a reason until I can prove that they didn't and so the amount of cognitive depletion that occurs as I read this method was so great I only got like halfway through it so the free software foundation who maintains bash says the solution is not proprietary software the solution is to put energy and resources into auditing and improving free programs and I think that's a pretty agreeable thing so who here wants to audit the quality of code that literally everybody depends on none of you right why is that it's because as a as a library becomes more popular the importance that we audit that it works and that it's safe and that it's secure goes way up but our motivation at an individual level to audit it goes way down if I use a gem and only three people are using it I'm probably not going to trust that it works so I'm going to read the source code but if I'm using bash I'm not going to think I should probably read this I'm going to assume somebody else did the downside is that everyone else is assuming the same thing and no one's actually reading it this is an example of tragedy of the commons and in this case this is an example that it's it's nobody's problem until it becomes everybody's problem and at that point it's too late so my hope is there's this recent group together I think the companies can solve this by investing because they have the money and if they collaborate you know the to-do group is an example that they came together they want they want to form some norms about open source governance one of the things I hope they look into is sharing notes when they're auditing the security of stuff working together to patch exploits I don't know if that's one of their goals but I think that's probably where the solution lies if you work in a smaller company it's your responsibility I think it used to be the case that we were trying to get open source into the door at wherever we worked and so we didn't want to say anything negative about it but now everyone needs open source and I think it's our responsibility to tell our bosses that open source is not a free lunch it's not some altruistic thing to make sure that it's working right it's a massive source of potential liability and it's worth vetting it out I want to share some thoughts about our interactions as people as well as where I think the future is heading so unfortunately all of these stick figures that I drew painstakingly were a lie because what they intimate is that open source is a thing that happens between people face to face in human interaction but it's not like that how we actually communicate is email github issues twitter almost all of it is just asynchronous text you know we're all no more than an avatar a username some emoji now and then and text on a screen that means that when you get riled up about open source no one can hear you scream I'm screaming all the time and none of you ever come to say hi and that's a big part of the problem Evie had a tweet recently I liked a lot she said it's effed up that a lot of modern discourse is optimized for whoever has the fewest feelings in the most free time who would design that system us apparently so when there's uncertainty ambiguity or disagreement in a team and if that leads to simmering disdain is email the right use the right communication channel probably not I think that it makes more sense to escalate to a higher fidelity form of communication so if there's ambiguity maybe real time text makes sense I could clear things up if you're having a voice conversation you can emote and empathize with the other person if you're making somebody cry you can see it on a video chat and if all else fails you can always meet up in person and there's something about human biology that when two people get in a room they tend to walk out with some kind of compromise and that doesn't seem to be true on Twitter I don't know why also the strategy can be great troll repellent right trolls get their power through anonymity and the perceived lack of consequences for their action but if you level up the fidelity of the communication and the discourse that means that their anonymity is also going to a road and they lose that and so when you like if somebody's trolling you're like alright cool let's have a hang out suddenly they go away so what I'd love to do is like make opting into these higher forms of communication easier so if I'm in a GitHub thread I'd love a button that would open a new chat in Gitter which is a tool for chatting on GitHub or build a live example in place like through JS bin or schedule a pairing session with screen hero or air pair or hop onto my nitrous IO box right in place I think anything to encourage us to have those more real communications the better I also want to think about where the future is heading because I showed a graph that it's going to get worse so on that graph I said no okay we're here and you know it's going to get worse before it gets better so what does this look like and I was stewing on this while Gogarucco was happening and I was thinking like if we extrapolate from our current culture of dependence where would that take us and I didn't come up with a lot of great answers but then I saw this tweet Yehuda was giving a talk about the Rust programming language and he says Rust enables a whole new generation of high level programmers us to write systems level code and my initial reaction was ehh these were the huge pyramid of stuff we don't understand that's scary but as I explored it and started working on this I actually realized I'm okay with this there actually might be some benefits to this and let's talk about those so if you think of innovation over time low level system innovations happened before high level ones naturally you need low level systems before you can have high level ones and then they crept up in the last 20 years most of this open source innovation that we've experienced has happened in high level programming languages now only very recently have we started reinvesting in low level systems like Go and Rust but today's like open source dependency culture really is steeped in a lot of assumptions about high level code and so the question is if we were just a cargo call that down to low level systems engineering how would that translate how would it work when I think of my systems programming friends they tend to be very conservative and cautious and that's because there are a mix of isolated from innovation and just curmudgens put it in slightly nicer way that means that there's a certain amount of accidental or incidental cautiousness a certain amount of intentional learned cautiousness and maybe I can learn from that cautiousness too embedded in real time failures have very grave consequences in some cases and that's probably where that cautiousness comes from so if you think of a high level system what's the worst that could possibly happen healthcare.gov starts failing and people can't get their insurance that's really bad that's like 60 night lines in a row of drama for our nation so let's take the same technology and put it in charge of this thing and see how that works right like low level systems there's way more rigor required in terms of fault tolerance because people can literally die if you don't get it right my systems friends have a different perspective on dependencies than we do they view adopting a dependency as outsourcing our understanding of how to do something that means that like if we have an application responsibility that orange blob over there and some particular dependency we can view that dependency as solving part of our application's problems for us we still know what like what it's doing and why but we might not know how and that represents what I call understanding debt understanding debt is typically paid down by iterating any dependency we have we learn about it through usage and through changing you know how it works and what it's what we need to work around and what's not great about it but if iterative releases aren't possible then you shouldn't outsource that understanding like if we think of high level systems versus low level systems a high level system is highly centralized might only run one instance low level systems tend to be built fabricated shipped and then they're out the door high level systems have very short life spans typically low level systems might have to live and be rated for very long periods of time high level systems usually have a full staff maintaining the thing for its entire life but low level systems might just have a support chain high level systems usually have way more than enough overhead in terms of memory and CPU in order to like you know absorb the impact of some inefficient dependencies but low level systems have very hard and real caps high level systems are highly connected we have all these tools to automatically deploy patches and new stuff but low level systems might have intermittent connectivity or no ability to be patched at all so clearly we've made it very easy to iterate high level systems but at this point it's still very hard to iterate low level ones so these concerns require that systems engineers have a deeper up front understanding of what they're building if you consider like if we were to graph out the depth of understanding necessary to be successful in a high level web app versus say like a low level plane control like a landing gear or something you only really need to know how browsers work HTTP a little bit of JavaScript the request response lifecycle but you might need to know a lot up front about how planes work and everything that can go wrong and everything that you're going to be plugged into and you need to count for that on day zero so this traditional like you know we write a handful of little tiny domain objects on top of this mountain of open source stuff that we don't understand that might be an appropriate level of depth for a high level app but if we were to simply cargo call that over to a low level system there's this danger zone in the middle right of stuff that we don't understand and it's inappropriate and might put us at risk and so systems engineers have a couple of options they could either build more richer deeper domain stuff or they can go through a process of qualifying those tools and literally rigorously proving that they work this reflection caused me to realize that modern tooling is just a product of high level web development you know if we look at this chart again this represents just today's perspective on how dependencies work and if we were to do the same thing at low level rather than worry about cargo culting ruining systems code I'm pretty sure they're going to still make sure that stuff works maybe together collectively we can have a new and broader perspective on what is currently our culture of dependence in fact I'm hopeful now that systems innovations you know bringing the same convenience that we have in open source to low level systems they might reciprocate some cautiousness desperately needed cautiousness as well as emphasize the importance of understanding the things that we're shipping so we covered a lot of ground in these four areas today but I want to part with the message that I think that the open source world can be a lot better and there's a lot of room to improve and it's all actionable and most of it's fixable you know companies I think that we need to do our job of convincing companies that they have a responsibility to be contributing back and to be auditing the security of stuff I think startups you know need to be cautioned that there's no such thing as building a real app in a weekend and being done maybe that means that like they should invest the time in understanding the things that they're standing on top of or if they have to get out the door in 30 or 60 days or whatever understanding that you probably want to throw away version one when you go back to rebuild version two after you've validated it after you've been successful I like to call this the slow code movement individual maintainers I think that they can learn a human lesson from this that is aggressively try to pull in new owners and contributors as early as possible while there's still excitement to do that and then I think we can solve with tools make it easier for people who want to participate and get involved in open source make it very explicit and invite them as opposed to just waiting for them to work up the courage to email somebody so once again my name is Justin you know please say hello where I come from test double we're an agency of really terrific software developers and so if your company needs developers and some help please let me know and I'd love for our great people to work with your great people like everyone else we're hiring too so feel free just to drop a line join at test double I'd love to chat with you during a break today and if you're too shy for that and you just want a free sticker I got stickers too and most importantly I just want to thank you all for your time and thank the organizers for having me I'm really really humbled and privileged to be here thanks


It's definitely been a while since the last issue video, but it's been quite a while since the last issue with the AIDA community video. But I said there were others, and I promised I would do more, and I think it's time. The AIDA standard. This has to do with the community, I promise. The AIDA standard is a major selling point behind why people should use AIDA. It's standardized language. You can use the same code across compilers, and it just works.  Or AIDA 95. No 2005 and no 2012 processors, as the AIDA auth calls them, are conforming. I mean, they might be, but nobody bothered to validate that they are conforming. So they're not standards compliant.  That's kind of a problem, guys. You should probably stop using that standards conformance as a selling point, and should probably stop bashing other languages for not doing that. Or even better yet, stop bashing the languages for having fake standards when they're actually validated against the standard still, because it is not, and it can't really get more fake than that. In fact, this is a level of fake that if you were to bring that up in a sales pitch, would get you in trouble, at least in the US. Probably in Canada, too, because the laws tend to be similar there, I don't want to comment on Europe.  And when you consider that certain processors, as it calls it, aren't actually capable of compiling the ACATs, it looks even worse. See, the ACATs, the EDIC conformacy assessment test suite, that's not exactly an acronym I have memorized, but it's something like that. It's the test for validating that a processor is conforming to the EDIC standard. Basically, if you have a compiler or anything that processes EDIC sources and want to say it is actually standards compliant, it needs to pass that.  What I'm talking about there is NAT. See, NAT has a hard requirement that the package spec and package body be in separate files, that each compilation unit be in its own file. That's not part of the ADIC standard. And it's fine to implement that if it was an implementation allowance, but considering the ACATs has multiple of these compilation units inside the same file, your processor should be able to read, to process that. Now the ACATs does do something that is sensible in this regards, where the package spec and package body that are in the same file are for the same unit. That makes sense, that is a sensible file organization. I will say personally, I do agree with NAT's approach a little bit more, that separating those fully makes sense, but I see where the ACATs is doing, where it does make sense to not duplicate the files, to have them all there. Both things are valid. You should be able to separate them, and the ACATs doesn't have any reason why you can't separate them, but I can see why it's a good idea to process them together in the same file. I'm not sure how ADICOR got them passing before. I'm not sure if there's a special build flag that's not documented that enables that to work. I'm not sure if they used one of their tools to separate things out into different files so that it could work. I know the ACATs uses some very unique file extensions that are not what is normally used at all. You have to be able to process that too. NAT runs into problems on that part as well, because of course it does. I'll get this out of the way now. I can't comment on Janus or Object Ida or anything else that still exists, because I don't use them really. It's my understanding that Janus has done a fine job with the ACATs, and Object Ida, but definitely the 95 compatibility is there. I don't use them. I don't know what pitfalls they have with it, anything like that. I'm just speaking about NAT here, but considering most of the Ida community uses NAT, that's where I'm coming from. It's mind-blowing to me that they didn't check this. You just go to Ida Auth and look at the list of conforming processors, and there's nothing from past 95. In fact, there's even a statement on the website that there's no registered conforming processors for 2005 and 2012. If I can remember, I'll add that in, but it says right there that they're not conforming. You really can't say that these are standards compliant. You can't say that there's a standard that ensures that code written for NAT will work on Object Ida or on Janus, but they keep bringing that up, and there are hostile about it.


Hey First Coast students, the Mr. Roger's Sweater Drive is here. All this month until November 30th, add your contribution of new and gently used men's women's and children's sweaters, jackets, socks, and blankets. The top Duvall County Public School, who collects the most items, will receive a special prize from WJCT and the Duvall County Public Schools PTA. Go to wjct.org to download the participation form.