Johnny Boursiquot: [00:48:20.17] Consistency over new patterns, unless there’s a demonstrable 10x return on that investment. If we’re using a library to access data, maybe it’s not the best one, but if I’m going to introduce a new way to do things, I need to, one, have a proof of concept that shows “Hey, if we do this, we’re going to get a 10x return on that investment, and we’re going to need to apply this across the board.” That way, there’s no two or three or four or five different ways of doing the same thing, there’s just one. If I can’t get the time and resources and the room within the engineering budget, time-wise, to make this happen, then I will consistently keep doing it the old way, until an opportunity presents itself for me to change it across the board. So I pick consistency every time.

Paul Vixie: And we got rapid adoption. We got way beyond how many queries per second we could tolerate on current structure in a matter of months, because there was nothing else like this, and commercialization and privatization meant that all of a sudden the internet was going to include everybody, not just people with a government contract. So right place, right time, right technology… But this is not what the DNS was made to do. But it did what you’ve said - traverse [unintelligible 00:55:18.23] it was completely transparent; you didn’t have to do anything at the far end in order to be able to [unintelligible 00:55:27.03] these lookups. So by using DNS to convey reputation data, we could just say “Hey, the address that you asked me about - that has sent a lot of spam lately. We have it in hand. We have proof of this.” And that meant you could just reject it. And spammers took a while trying to figure out how they were going work around this. And they did, [unintelligible 00:55:47.16] But that was maybe the first wide-scale use of DNS for something that had nothing to do with [unintelligible 00:55:56.10]

The second one that I saw a couple of years later was license key lookups. And I think this was Symantec; I don’t know who it was. But what they wanted to do is be able to give away antivirus software with every PC that was sold, and then have it be that you get 60 days for free, and then after that you’d have to pay money… And so they would have it be that every one of these PCs would create a random-looking license key, and when you paid, you were essentially paying down to allow that license key to operate. And what they would do is use that license key as part of their DNS lookups for their antivirus signatures. And it worked perfectly. And it let them build a global antivirus empire without having to sort of have every PC reach out to the mothership in the way that we all see today.

The third way - and this is maybe the best - was Dan Kaminsky. Now, Dan has since passed, and I miss him a lot, but he used to have a tradition where he would go to DEFCON in Las Vegas, and they would just put him on the schedule. He didn’t even have to file a proposal. They’d put him on there, and it would be something involving DNS. And then we’d all go there and see what it was, without knowing any more than that.

[00:57:26.12] One year it was DNS tunneling, where he was using the query direction as a way to transmit data, and the response direction as a way to receive it. And so if you had a DNS tunnel endpoint on your laptop - which is how he demoed this - and it was talking to some DNS tunnel gateway somewhere that would turn your DNS tunnel data back into normal packets, then you could for example use a hotel room WiFi without paying for it. Because they had to allow DNS to work, otherwise, they couldn’t make their paywall work. Same thing for coffee shops, and everywhere else. So they just used the fact that DNS was open by default, and this demo was Skype. And he held a full motion video conversation on the big screen with somebody somewhere using DNS tunneling. And all of us were just mind-blown. We didn’t think that it would ever be fast enough to do that. But it was just huge. So yes, DNS turns out to have lot of room to grow.

Jerod Santo: What up, nerds? I’m Jerod and this is Changelog News for the week of Monday, March 4th 2024

March the 4th be with you, is that right? That’s not right…

So, we’re dreaming up a new landing page for Changelog News and I’d love to feature some nice words from actual readers and/or listeners on it. I hear social proof is a compelling thing…

Do me a solid and drop one or two lines of high praise into the form linked in the show notes (only if you dig my work, of course) and I’ll happily link back to a URL of your choosing if we end up using your quote.

If my math is correct, which is admittedly rare, that’s a win-win-win.

Ok, let’s get into the news.

Samuel Goff: So a couple of things. First of all, when it comes to blockchain, specifically Bitcoin and others that are based on proof of work, not proof of stake, I have a real issue with… Because the energy intensity of the computation is so high that you could power multiple countries now. Right? And so what’s happening is a lot of dirty energy sources such as natural gas, coal, oil, things that, where increasingly, it is economically unsustainable, because grid-powered solar and wind have completely leapfrogged them in terms of cost efficiency. If you’re building brand new energy sources right now, by far, you can build anywhere from six to nine times more grid-scale, solar or wind, compared to nuclear, which is the second cheapest, or third cheapest, I should say… But everything else is more expensive by comparison. But the problem is, you go to an oilfield where they have these toxic gases, and they set fire to those toxic gases as a way of making it safe. Well, that’s wasted energy.

So what’s happening here in Texas is a bunch of Bitcoin miners set up in the oil fields, and they’ve harvested that heat energy, what would normally be just waste heat. And that becomes an additional revenue stream for those oil extractors, those oil companies. And so it basically takes what was a dying revenue model, a dying, industry, and it breathes new life into it, and it slows down our adoption of renewables. And it takes – basically, it vastly increases our risk of transforming our environment to a place where it’s going to kill people to go outside, whether it’s due to the extreme heat and humidity, or the extreme cold, because the natural conveyor belt that used to exist has kind of collapsed, or it’s sometimes collapsing.

José Valim: So I think that’s a very good question. I gave a whole talk at Elixir Conference Europe, in 2022 perhaps, on this topic. And what I said - and usually, when I go give a conference talk, I usually give Elixir updates when I’m at Elixir events. “Hey, here are the things that we have been working on.” Or I usually talk about a project that I’m involved, Livebook, or stuff with machine learning… And then I started the talk saying “Oh, these are the things that I’m excited about in the future of Elixir machine learning, and stuff. But before I talk about those things, I need to address what I call the elephant in the room.” Because if you go to an Elixir event, or I think if you do a poll in a forum or something that, if you ask “What is missing in Elixir?”, most people are going to say it’s types. A type system is the thing that is missing in Elixir.

So if a lot of people feel that’s the thing that is missing, I have to understand that. I have to understand why they feel it’s missing, what do they think they’re going to gain… And one of the things that I say in this talk - I don’t remember precisely the arguments precisely I used at the time, so I may butcher my own presentation… But one of the things that I mentioned in the talk is that usually discussions about types, they tend to get so polarized very quickly. And it’s very common for you to hear things that I don’t believe to be true, if you try to look at it.

I remember seeing people saying “Well, if I was using a type system in this particular language, it would have caught 80% of my bugs.” And then I’m “I don’t think that’s –” I feel what the type system can do for you in that particular scenario was being overvalued. I don’t think it’s 80% of the bugs. And then when you go look at it, when there are some studies trying to find a correlation with that, they can’t find something that precise or that clear, that says “Yes, a type system is going to lead to a program with fewer bugs.” I don’t think we have found the universal proof of that. And I even think this discussion as a whole can be harmful… Because you’ve probably heard people saying “Hey, well, if you have types, you don’t have to write documentation”, and I don’t agree with that. [unintelligible 00:19:55.05] That doesn’t tell me how that things behaves.

So then people say “Oh, if you have types, you can write fewer tests.” And I also think that’s very harmful. I like to say “Well, if you have types, you can write fewer bad tests”, because I don’t think types would replace 99% of the tests that I actually write and I find important. For example, going back to the same logical or. The types are not going to find bugs in the implementation of logical or if you make it always return false.

So I gave this whole presentation which was kind of preparing people why we may need a type system in Elixir, but the presentation was much “Well, types are not all these things that you think they are.” So very good salesman here, right?

Cory Doctorow: Well, unconstrained needs, right? It’s not just capitalism, because capitalism usually – when people talk about it, they think about competition as well. It’s about a little more like feudalism. The idea here is not to build a service that other people use, but to build something that other people have to use to build their services. Right? That’s what a platform really is. It’s like “I’m not providing the value, I’m capturing the value.” And as a tech worker, if you’re listening to this and thinking about where you sit in this world, think about how your world has shrunk. When I entered the tech industry, the dream everyone had was “I’m going to work for this big dumb tech company for three years, and then I’m going to start my own tech company and I’m going to bankrupt them.” And then Compaq buying DEC. Or SGI buying Cray, right? And then it was like “Okay, well, that’s not gonna happen… But I’m gonna work for this big dumb company for three years, I’m going to do a fake startup, we’re going to make a proof of concept product, then we’re going to get acquihired by the same company again… It’s a super-inefficient way of getting a promotion and a bonus, but I’ll get to call myself a founder.”

Marcin Kulik: Exactly. So I was playing with it, and then it just felt so magical when I replayed it in my terminal without touching the keyboard… And it was just like everything was like a ghost would be typing. And it felt really cool, and I thought, “Well, not many people know about this. How can I share my recordings with my colleagues?” The immediate thing was “Well, I can send the TypeScript file over email, ask them to replay it in the terminal”, and then it felt like “Yeah, that’s just too much to ask.” And I thought, “Well, there should be a way to share this on the internet, on a website somewhere, so I can just send a link to someone, so they can watch it.

And then I started experimenting on how would I replay such a file in a browser, on a website? And yeah, it was just me experimenting, but it was kind of my initial prototype was jQuery-based, replay inside a div element on a page; a div element with some span elements inside, with some styling etc. It was a proof of concept, it worked… So I thought, “Yeah, that sounds cool.” And yeah, fast-forward 12 years, and it’s kinda bigger than I thought, and a lot of people use it.

There has been many phases in this project; the early stages, and then the recent developments… It’s been growing consistently, gradually. So it was just like a fun side project initially. I didn’t even know if it would work, but I saw that it can work, so I just persisted.

Daniel Thompson: And for me, one of the interesting side effects about working with Tauri is that – Lucas and I started way back in the day, and we thought we were going to make a better Electron. We haven’t gotten there yet. Electron is better in a number of ways, I’ll say it here. Tauri is better in a number of ways… It’s a different thing. But that’s what we started out to do. And along the way, we built a community, we made a ton of friends, we started a company, and then we realized, “Actually, maybe we should expand our reach a little bit. This updater and bundler that we’ve built, it’s tightly coupled to Tauri.” And then at CrabNebula we go to conferences, we went to four this year, or we will have gone to four this year… At one of the conferences, somebody rushed the table and was like “Guys, hey, can you please upstream the bundler? Because I’m using Dioxus, and it would be great if I could just bundle and ship that way.” And we backburnered it because we had to get the 2.0, we had to make that push to beta… But internally at CrabNebula we are working on the proof of concept research to upstream it, and make it available to other projects outside of just pure Tauri.

The most exciting one is Slint, because we’ve found out meeting with Slint they have a different target audience, but they are building desktop apps, and they’re using our low-level libraries, TAO and WRY. So all of a sudden – the reason why Tauri became so popular in the first place, in my opinion, is because anybody could use the frontend stack. If you’re React, or if you’re Svelte, or if you’re Solid, or Vue, or Angular, or choose any one of the hundreds… Or even Rust-based ones, like Yew and Dominator, and all that, you could use this thing that we made for you; we gave everybody a gift, and it was like “This is great.” And then we were still in this issue bubble, where we were seeing problems and comparing ourselves to others, and feeling like “Oh, there’s competition out there.” And by reframing it from “Hey, we don’t have to compete with Dioxus, or Slint, or Electron”, we can help them do better things. Do things better. And by moving out of that tight coupling to Tauri core, we are doing just that.

I haven’t had the opportunity to speak to Cory Doctorow personally, but I think that this mode of deciding for cooperation instead of competition is really rare in – I mean, in open source maybe, but in venture capital type companies, very likely.

Adrian Hesketh: [10:05] Yes, I guess – you know, I can’t remember how I actually started the project. I’m gonna have to look back at the first commit and see what that actually looked like. But I’d already worked on a parser library. So I had already written the HTML parser in the past, in a different programming language. Because I used to work in the language translation industry, so I had this experience of parsing in HTML. Actually, my job was to try and parse invalid HTML and XML, get the text out of it, and then put it back in its completely broken form, as it was, without messing anything up. So I did a lot of work around parsing broken HTML and XML. So I knew I could write it. So I started out with the kind of parser elements of it.

And initially, really, I was aiming at building a cut-down version of quicktemplate. So the syntax in the first version was basically a ripoff of quicktemplate, with the objective of trying to put the LSP functionality in, and do a proof of concept around “Could I add the LSP functionality to quicktemplate?” So when I realized that quicktemplate doesn’t really have an internal object model, so it doesn’t parse the template into sort of in-memory representation, which then allows you to sort of interact with it, it’s very sort of - the generator, as it’s working through, just spits out Go code as it goes. So there’s no sort of intermediary step that would make it possible to build a language server that could kind of look at what was going on… So I realized I would have to make a parser for it again. So I started out building the parser, and then as a cut-down version of the project.

So I built that out pretty quickly, and then I had to learn how to build language servers… Because I actually didn’t know, I’d never tried it before. And so that was the second part, was “Okay, how would you go around building a language server?”

V Körbes: Yeah, this reminds me of something that I was thinking not long ago, that sometimes we have an issue when doing things as a team, that we’re not aware of the team we have… Because teams change really fast; especially in tech, everybody’s changing jobs all the time. You didn’t even change your job, but this year you have one team, [00:42:17.10] your team is completely different.

I was thinking back to a time when I had a team where basically everybody was a genius, and you could just tell them “Hey, just do this thing”, and they would figure it out, and they would go and study the possibilities, blah, blah… But you could give them a one-liner and they would build you the entire thing. But often you don’t have that team. Often you have to go talk to people and be like “What is missing here? How much information do I need to tell you to make sure you understand what’s needed?” And I’m speaking from a PM point of view, but this applies to all levels, let’s say. If you want to prototype something and it works for you, maybe you hand that prototype off to somebody later, and they’re gonna have no clue what to do with that, because they just don’t have the assumptions that you do, and they won’t understand the point you’re trying to make when they see that proof of concept, let’s say.

But yeah, this is not a prototyping question, it’s an environmental, social question, of how we communicate with our teams… But I think especially in a team setting, you have a prototype, the prototype does X, you think the fact that it runs communicates something to other people, but it likely won’t communicate everything you think it does… Was this too abstract? Did it make sense?

Josh Padnick: Yeah, that’s a great point. So one of the – there are a few kind of core tenants of our vision, and one of them is, of course, a clear, unambiguous open source license. Another one is backward compatibility. And what that specifically means for us is that any bug fixes that are reported, either to us, or that we see to TerraForm, we would like to implement fixes for. I should also say, it’s extremely important to the group to remain compliant with HashiCorp’s license. So we cannot just go to their repo and copy code improvements, just because they’re available. We are still working with our lawyers to figure out what information can we legally glean from what happens there, and where do we need to just not even look. So legal compliance is something that’s really important to us.

Anyway, to your point about compatibility… So that’s bug fixes. Then for new features that Hashi TerraForm releases, like I just said, we cannot just copy their implementation. But our understanding is that we can copy the interface, and we can do our own implementation, and make it interface-compatible. So to the greatest extent possible, we want to make OpenTF a drop-in replacement for Hashi TerraForm. And then once we feel like we’ve really achieved that expectation, where people feel like “Hey, this project is pretty stable. I can use this, I’m happy with it”, the other kind of big thread that we have is a community-driven RFC process for whatever improvements people want to see in OpenTF that could never make their way into HashiCorp. One example would be those encrypted state files, like I mentioned before. HashiCorp never wanted to merge that PR, and now this is an opportunity for OpenTF to figure out the right way to do encryption on state files, what all the potential pitfalls could be, go through a proper RFC process, get that merged, and now it’s a superset of what HashiTF would be.

Another example would be better importing from the Go codebase. So HashiCorp also made this sort of pivotal decision a while ago to lock down a lot of the internal libraries of TerraForm under a specific package in Go, so that they were difficult to access… And that meant that you couldn’t really use TerraForm as a library, you could really only use it as a CLI tool. And for those of us who are building things like pipeline solutions that operate TerraForm, or TerraGrunt, or whatever, we have to go through this awkwardness of using the CLI tool, when what we’d really like to do is just access the Go library directly.

[38:20] Another example would be downloading providers from any registry. So right now, HashiCorp forces you to download providers from their registry. And if you’ve written a custom provider, like maybe you’ve got some custom API, and you want people to be able to write TerraForm code for your custom thing - this understanding I need to check, but my understanding is that you can’t host that provider except with HashiCorp’s paid services. I might be wrong on that, so I definitely need to check on that. But in either case, with a community-driven process, we can now allow users to download their providers from any registry. In fact, someone from our consortium released a proof of concept video just a couple days ago showing how they were able to download TerraForm providers from Docker Hub, or ECR, or GitHub Container Registry.

So our first priority is compatibility, so that you can just do a drop-in replacement for Hashi TerraForm. But once we feel like we’ve really met that expectation, then we want to start focusing on our own set of innovations around this community-driven RFC process.

Adam Stacoviak: [07:33] You had the idea. It was like “Hey, we have this idea.” And we love that. We love capturing the initial stages. We don’t do this all the time, but I think in this case, because the terminal is so near and dear to our hearts, why not speak to somebody who can boldly think they’re going to do the future, the future of where this terminal is gonna go? And so I think that’s what attracted us to the conversation. Because you really hadn’t put a lot of proof out there yet. You had an application, you had, I think, some working things… Jerod and I both tried it out, but it didn’t stick for us necessarily; certain things – we pushed back on the open source nature of it… There’s a lot of good things and bad things about that launch. I wanna say positive things or negative things. I think open source has a good vehicle, you probably thought about that… Who knows? But when somebody says they think they’re going to be the future of where the terminal is gonna go, we have to have that conversation, you have to capture that initial launch, and think “Okay, here’s where they’re at”, and then just over a year later, now you’re here on Founders Talk; not the Changelog. But we’re gonna go deep into Warp, we’re gonna go deep into product-market fit, your personal journey as a founder, some of the struggles it takes to run a company, maybe what it might be to grow to six-figure user base, what it is to manage that… All those things. We wanna talk about all that stuff.

Mike Basios: Very good question. So it depends on the programming language and the existing tools that you can also use. So if you go for a programming language like Haskell, and functional programming, in theory, you can have a bit more proofs about code before and code after, it works the same. NASA, for example, would want this proof. You cannot have the code. The second mechanism is ideally we would like applications to have unit tests and test all the scenarios. So when you do a change… Ideally. But not all codebases have that.

Leslie Lamport: I discovered it when I wrote the proof.

Kevin Ball: Well, and often the projects that you’re doing are different. When I’ve worked as a staff engineer, oftentimes the coding that I’m doing is one of probably three different things. It’s either prototyping - basically, proof of concept; can we go in this direction? Is there a chance this will work? Let me show you, let me use this to convince you. Second one is glue work, right? This thing has been working terribly; it’s nobody’s responsibility, it’s slowing all people down… I’m just going to rock it out, because I can do it fast, I understand all the different pieces. I will make it work. And the third one is like really tricky refactors, or architecture stuff, or things where it’s like – oftentimes, these are almost rescue jobs. Somebody’s working on it for a while, and it’s just not coming together. It’s not working, and they’re frustrated, and they’re ready to give up or whatever, and you say “Okay, you know what? We could keep going back and forth, and I can try to coach you through this, and it will be here for the next two or three weeks. But also, I could just take this and rock it out. Are you okay with me doing that?” And you do it, and it unblocks a whole bunch of other stuff. But it’s rarely the day in, day out work shipping towards this next product.

Jerod Santo: I can’t believe this could possibly be the case… Is TypeScript the most popular programming language amongst JS Party listeners? [win alert] It absolutely is. Number one spot, TypeScript… Which to me is just proof that Nick Nisi stuffed the ballots, and answered the majority of these responses were all Nick, with different names, like Rick Nisi, Chick Nisi, Flick Nisi… Stuff like that.

[05:56] Nonetheless, the Whatnots have it. So one and two are gone. Chuck and Robbie will be playing this round… And we have three, four and five left on the board. Fellas, you’ve got to match all three of those, and you take home all of round one’s point. Let’s go down to Robbie, it’s your turn. What is our listeners’ most favorite programming language?

Darcy Clarke: So about a few months later, because unfortunately we had such a backlog of issues with npm and the npm CLI team, we really went through it… But one of my team members, Michael Garvin, actually triaged the issue on October 22nd, and initially thought the person was sort of referencing just the fact that they can ignore scripts, or sort of turned on and off the ability to actually run lifecycle scripts, which are typical within the process of installing a package. We run a bunch of scripts very similar to the publish process, where we run a bunch of scripts that users can define and do certain things pre and post-publishing.

[30:20] And so he brought that actually up to the team, and we also all looked at it independently… And what I realized pretty quickly on my own - that this likely was an issue, a more broader-scoped issue; that there seemed to be problems with how we were caching, or essentially rehydrating the state of the metadata, the manifest that we were holding around in memory… So the problem seemed to be if you had flushed your cache, you didn’t hold on to that context, the metadata that you had gotten from the registry, and instead, we were hydrating it from the local pkg.json. Now, we thought those two things should be the same. And we were making the same mistake that I think a lot of people make, and we were all under the assumption that those two things would be the same. So that’s where I saw some inconsistency.

So on November 2nd, so about a week later, I actually wrote the first POC, our proof of concept, and published it to the registry. So there’s a package in the registry called darcyclarke-testing-malformed, and you actually can see that that was published on November 4th, and that’s actually the same day – or sorry, November 2nd; and then a few days later after publishing that I internally wrote up a post about how I thought this might be a significant issue, we should probably look into this, and let the rest of GitHub know. Unfortunately, I decided to quit GitHub shortly after filing that internally. I left GitHub December 2nd, so that was my last day, for a number of reasons…

Jerod Santo: Can you trust ChatGPT’s package recommendations? Maybe not so much. The team at Vulcan have published a new security threat vector they’re calling AI package hallucination. It relies on the fact that ChatGPT (et al) sometimes answers questions with hallucinated sources, links, blogs and statistics. It’ll even generate questionable fixes to CVEs and offer links to libraries that don’t actually exist!

“When the attacker finds a recommendation for an unpublished package, they can publish their own malicious package in its place. The next time a user asks a similar question they may receive a recommendation from ChatGPT to use the now-existing malicious package. We recreated this scenario in the proof of concept below using ChatGPT 3.5.”

Be careful out there…

Adam Stacoviak: There’s scientific proof about caffeine, inhibitors, and stuff like that with your brain.

Mike McQuaid: So I think that’s the thing. I think if you’re targeting as a game developer, you would need to be targeting either multiple platforms, in which case you’re somewhat limited in being able to do really intriguing things just for the Vision alone… Or you’re targeting it thinking this is going to become a mass market device when they bring the cost down, or whatever it may be. Or you’re doing it as some interesting proof of concept that kind of buys into another platform, whatever. But actually how it is right now, where it’s – say like Sony has announced the PS 6, or whatever, and they’re gonna release in 2024, and it’s going to cost you $3,500, and you can only buy it in North America, people would probably not be rushing out to build stuff for that, and really excited about that. And that’s the opposite of the direction that console gaming seems to have gone, where it’s more and more commodity hardware, it’s more and more kind of incremental changes, and not these kind of Big Bang revolutions, and stuff.

Jeffrey Sica: 160. And right now, as of whatever today is – the 10th, May 10th… I think there’s 12. So there’s some number above like seven or eight that are currently getting voted on to be adopted into what’s called the CNCF sandbox. Think of it proof of concept projects, projects that don’t necessarily have a large community, and they’re looking to build a community - they apply to the CNCF sandbox, and then those get voted in. Yeah, I talk with my hands as well. I’m somewhat Italian.

Kate Bradley Chernis: Thinking, anticipation… That’s right. People turn up the radio, is what they do also. And thinking about how we’re writing - and you’ve seen this tactic on LinkedIn as well, is like people leaving different space, putting in enter-enter-enter, or whatever… There’s something about – and it goes to your point, Chris, of doing the unexpected. What I learned about making fans, which are more valuable than just listeners, or customers versus evangelists… And by the way, let me put the proof in the pudding - not a day has passed in four years where someone hasn’t spontaneously written on social media about Lately. Not one day. You don’t want to be the megaphone, you want to be the magnet. And when you are the magnet, in order to truly be that kind of magnet, you let other people be the light. You show them how to be the megaphone; you put them on the pedestal.

Bram Adams: Yeah, I think that’s a really good way of looking at it. Well, for one, I do think specificity helps, depending on – the pace is also really large. So Google is a really good example of that, I agree, where it’s like Google is kind of this insurmountably large amount of data on the web, and you have to ask very specific questions to almost get Google to surface the things that you’re interested in finding. Like, pizza places near me; you’re not looking for pizza places everywhere, but near me. Because that’s technically in the set too, right? And I think the latent space is something similar with ChatGPT, and just GPT models in general, where the idea is that you’re trying to surface data in the latent space that’s useful to you. But I don’t necessarily agree that it’s all just about relevance.

[14:05] I’ve had this conversation a number of times with people, where if you compare it to a search engine, the idea is that you’re looking for the closest thing to the thing that you’re looking for, whereas I see these generative transformer models as like word calculators, that allow you to do reasoning calculations, too.

So I’ve built an app that I call Birds of a Feather that I use on my own device; I use Obsidian, which is a knowledge store software, and I have all these individual notes. So let’s say, for example, that you’re searching for a sentence, and you would expect it to return a list of the top five notes – or the top three notes. Let’s do the top three. So I actually think that if you’re going to go the extra mile to do embedded search, and you’re going to do semantic search, it makes more sense to return the top thing, the middle thing and the bottom thing. Because the middle thing and the bottom thing from your dataset aren’t worse data. They’re literally the opposite of the cosine similarity match. And to me, that is more data value proof, in terms of like kind of like profit that you get from your dataset, than just returning the three most similar things.

So I think the way that I’m trying to say this is that the specificity of your question matters if you’re trying to get like a search engine result, but when you realize that the cost of being creative has gone down immensely, you can get really weird with it. So it’s not necessarily about saying, “Oh, give me the most similar thing that I’m looking for, so that I can get on with my life.” You know, since I’m not typing this out anyway, and doing a bunch of research, give me the opposite thing. And I just want to see where I end up.

Kris Brandow: Yeah, if you’re building something that’s production-level, then you might want to have more of the – just to get some more testing, or ease the testing of it. But yeah, if you’re just doing a proof of concept, or a prototype, you can just shove everything into a main function if you want. Don’t get fancy before you need to get fancy.

Break: [32:54]

Denny Lee: But the context is like, well, as much as I want to just provide an answer that, the reality is no, obviously we can’t train [unintelligible 00:59:54.23] We actually need verbosity to provide context, to provide proof, if you want to put it that way. Because there’s going to be other people putting other answers, too. So for example, in this case I’m just gonna call a buddy of mine, Rob Reid; he’s a fellow cyclist, he’s also a fellow coffee addict… I know he also put some coffee answers inside there as well. So between everybody that put coffee answers in there, that’s actually literally you’re getting data from myself, from Rob, and a few other folks. From, well, Databricks.

Michael Grinich: So WorkOS is designed so that anybody can just go sign up, get an API key, integrate, go do it all on your own, without having to talk to anyone. So if you wanted to go add SSL to your app today, you can literally sign up and you’d be off to the races. And it’s really fast to integrate, too; so you don’t have to talk to anyone.

We find that a lot of developers do have questions. And when they do have questions, they can be a variety of different topics, and they want to talk to somebody technical. And so the first step that we introduced is something called our Developers Success team. Developers Success engineering. And these are really technical people, that are just there to answer questions and help people integrate and use the product and succeed. And it’s not just the integration, it’s actually later on down the line too, when you do different things with it, or add customers.

So these are the first group of people that folks usually talk to. They say, “Hey, I have a question about your API in this way.” Or “My app is built using this framework. Do you have an Elixir SDK? Let’s talk about that.” That sort of ends up being pre-sales for a lot of companies, in a way. And then you put in the credit card and you go, later on.

For relatively small companies, say, I don’t know, under 30 or 40 employees, usually they just do that; they just get started. They might have questions around pricing, or kind of want to talk about security, but it’s not really a big sales process. They’re just plugging it in.

It’s a bit different for bigger organizations. If you’re a company with let’s say like 2,000 employees, there’s going to be many other stakeholders from a security perspective, the financial side, or on what the business contract is going to be… Maybe they’re going to budget a lot more for it, or they want to see if it works in production with a customer first, like do a proof of concept… If they’re using a lot of capacity, they’re probably not just going to put it on a credit card. They might want to pay for it through other means, or like a purchase order (PO).

So the way that those bigger companies buy software is just a lot more complicated. And you might need to talk to the head of engineering, and head of product, and maybe the head of security, and then engineers that build the stuff, and then the support people have questions… So there’s just many other people that need to get around the table to know what’s going on. That ends up leading to a longer sales process, because you have to talk to more folks, right? But the upside is they’re going to have a bigger contract, right? They’re gonna use more of it out of the gate.

So who are the people that go do those conversations? Who are the people that talk to that company, and they say, “Hey, here’s the 12 people that are sort of weighing in on this decision, and they all play a different part. They’re kind of playing different instruments in the orchestra.” How do we map those out and make sure we talk to everyone and just get them all the information they need, so they can make an informed decision? And that might be pricing, that could be functionality and features, it could be security. It turns out the people who do that, their job is called sales. That’s what those folks do.

Jon Calhoun: I’m pretty sure I can think of an old social network that is pretty much living proof as to why you can’t do that.

Jerod Santo: Yeah. Well, it’s cool to see you leading the way, it’s cool to have the proof of concept, right? It can work, at least for one person, in this one way… And let’s see if it can work for more people in this same way, or maybe similar ways. Maybe the three things that you offer turn into four for somebody else, or maybe they find out nobody really wants their advice, but they really want that risk aversion, and so it may be like different iterations on this same idea.

And time will tell. I mean, you’re still in your first year as well. So one of the things that will be a big testing ground for you next year, and prove to you how much value you’re bringing is “Will these companies do it again next year?”

Jerod Santo: You’ve gotta love that moment with an open source project where you start to get significant contributions. Not drive-by readme fixes, or docs - which are helpful, but not like… Like, this is a significant contribution of a new way of doing something, or a proof of concept. That’s pretty exciting. It seems like your two projects now, especially Whisper, because it’s been around a lot longer, has had a lot of very smart coder types not afraid of hopping in and really helping out. Did you do anything to cultivate that, or was it just the nature of the project, that it brings a certain kind of contributor?

Bonaventure Dossou: Before leaving the floor to the ladies, I would like to just second what Just said. I also had the same struggle with Fon, because I started and nobody was working on Fon, nobody knew about the language… And that was also something interesting and exciting, going into a direction where nobody is looking at, and inventing it.

Not to show off, but a lot of people nowadays just quote me as the Fon guy. When someone is talking about Fon and there’s doubt, they just tag me on a tweet, or whatever. And yeah, I envision Just to be the same for Sranan Tongo.

The moral of the story is that you need to get started, because there’s always going to be a point where there’s no data, and someone has to do some little effort. For instance, we have JW300, but what if those people didn’t do anything? We would not even have a starting point.

So I started with JW300, and then I tried to manually scrape with my friends, through Google Forms, and created something like 25,000 sentences, and then out of that, then I’ve been able to bring some proof of concept… And it grew up, and people are now more knowing about the language. It still is not – I mean, I’ve built FFRTranslate with Chris, and people are using it, people aren’t saying anything bad, they are happy. It helps them. Artists, and other people… There’s more awareness, people willing to be more contributing, creating more content. It’s not yet on something like a Google Translate or a centralized translation for those African low-resource languages, or low-resource languages in general, but I hope that’s something that’s going to be coming. So I would just say just start.

Honestly, like my name says, I like adventures. And I like good adventures. So I just like to go where nobody is focusing, and [unintelligible 00:25:24.23] is exciting… Bring something that people haven’t been focusing on to light. I don’t think I would have had the same maybe impact if I for instance started with [unintelligible 00:25:36.12] because that project, the first FFR project that then went on [unintelligible 00:25:40.19] this type of thing, we were doubting whether we should use for [unintelligible 00:25:43.22] So finally, Chris and I, we decided to go for Fon, because [unintelligible 00:25:47.22] has at least some effort done already, but nobody heard about Fon. Nothing was on Fon.

[25:55] Today, there are a lot of papers, people citing the work… It’s been cited in the paper that led to the extension of Google Translate to 20 more African languages, or 24; it’s been cited, and no language left behind of [unintelligible 00:26:08.15]

Also, being part of Masakhane, you collaborate with people like Sebastian, with Julia, with Angela Fan, who work on NLP… So just get started. People will know about it, and then it will just keep supporting. If you don’t have support, just be yourself a supporter, and at some point – you know, when people are seeing the effort, they will definitely then join, and pick it up from there.