What is the ancient genetic history of Britain and Ireland? In one of my previous videos on the genetic history of Britain, I looked at the impact of migrations and invasions, from the likes of the Vikings, the Normans, the Romans and the Anglo-Saxons. But what about the migrations and invasions that took place thousands of years prior to this? If we were to go way back for a second, species of humans, Homo neanderthal lensis and Homo hydel burgensis were in Britain from 800,000 years ago, living by hunting wild animals and gathering plant foods. Our species, Homo sapiens, are thought to have entered Britain around 44,000 years ago, during the last Ice Age, which itself existed from around 115,000 years ago to 11,700 years ago. Rapid changes of climate caused humans to move in and out of Britain during the last Ice Age. The ice was at its greatest extent during the last glacial maximum, a period during the last Ice Age where the glaciers, the ice was essentially at its greatest point, around 26,000 to 20,000 years ago. At this time, Britain was pretty much uninhabitable. Somewhere around 12,000 years ago, after the younger dryus period, which was a brief return to glacial conditions, the ice gradually melted and began to rapidly melt. Sea levels rose around this time as well, given the melting of ice. But what are some of the main migrations into Britain and Ireland in the 10,000 years or so between the end of the Ice Age and the Romans invading Britain, beginning with Julius Caesar's invasions or Britain in the 1st century BC? This 10,000-year stretch between the Ice Age and the Romans, what were the main migrations that had a profound impact on the genetic makeup of Britain and Ireland today? Small groups of Homo sapiens would have started moving back into Britain and Ireland after the last Ice Age, quite soon after the Ice Age. And one of the main mechanisms by which they would have crossed from Europe into Britain was through Doggerland, which was a land bridge that connected Britain and continental Europe, and was swallowed up by the sea around 8,000 years ago or so. When Doggerland was swallowed up by the sea, Britain became an island as we know it today. Very early settlers of Britain moved across from West Germany and the Atlantic coast of Europe, and these first settlers spread across England, Scotland, Wales and Ireland. What is interesting is that after these earliest settlers of Britain and Ireland arrived in these lands, future migrations and invasions into these lands, would have affected the populations of England, Scotland and Ireland far more than they would have affected Wales. Wales, therefore, is the most genetically similar to the earliest settlers of Britain and Ireland. A little later, between 6,000 to 3,000 years ago, or around 4000 BC to around 1000 BC, as the people of the British Isles study found, there was a large movement of people from Northern France into England and Scotland, at about the same time that agriculture began to be widespread. The genetic study revealed a pattern of DNA dated to around this time that is shared by people now living in Northern France and those in England, the North of Ireland, as only the North of Ireland was studied in this particular study, and also Scotland, but none of those in Wales. The study noted that these people may have included the first farmers at the start of the Neolithic age, or there may have been some of the beaker people who introduced characteristic, decorated pottery, developed copper working and traded metal with other parts of Europe. This leads nicely on to another people that had a profound impact on the ancient genetic makeup of Britain and Ireland. They are known as beaker people. I made a full video on the bell beaker culture and beaker people in general, that I will link above and you can watch in a little more detail. But these were fascinating people. They arose around 5,000 years ago in Iberia, present-day Spain and Portugal, and they soon spread across much of Europe and into Britain. They were known for bell-shaped pottery vessels, and that is how they get their name. They were often decorated in really nice patterns, in kind of tooth-snap patterns. A 2018 study published in Nature found that the beaker people replaced 90% of Britain's gene pool in only a few hundred years and introduced high levels of step-related ancestry into Britain. It is clear that the bell beaker people are profound ancient ancestors of people in both Britain and Ireland. Another study from 2019 looks specifically at how farming was introduced into Britain. Farming in general was introduced into Britain and Ireland somewhere around 4,000 BC or around 6,000 years ago, and most studies have now shown that this was due to a large migration from people from Europe into Britain and Ireland. There was initially a bit of a debate about whether hunter-gallarers, like an indigenous hunter-gallarers of Britain and Ireland, played a significant role themselves in developing and evolving into a more agricultural society. But a lot of studies now, although there is still some debate, seem to point to a migration of people coming from Europe with the skills, the knowledge, the technology and brought farming with them, as opposed to it being an indigenous feature that developed within Britain and Ireland itself. There was some mixture there, but there was a profound migration into Britain and Ireland that brought farming with them. These farmers are thought to have travelled along the Mediterranean route, but they probably originated around a G&C, a sea which sits between Turkey and Greece today. Another study that looks specifically at Ireland found similar results, i.e. that farming was introduced by migration from European farmers from the Near East region, essentially modern Turkey Middle East region. The found us by analysing the genetic ancestry of an Irish female farmer from a megalithic tomb near Belfast dated just over 3000 BC. This study in general analysed three Bronze Age individuals found in Ireland, and the research has noted the presence of step-related ancestry in all three individuals. The authors write that it is clear that the great wave of genomic change which spet from above the Black Sea into Europe around 3000 BC washed all the way to the northeast shore of its most westerly island. At present, the beaker culture is the most probable archaeological vector of this step ancestry into Ireland from the continent. Although further sampling from beaker burials across western Europe will be necessary to confirm this, the extent of this change which may estimate at roughly a third of Irish Bronze Age ancestry opens the possibility of accompanying language change, perhaps the first introduction of Indo-European language ancestral to Irish. It is interesting that lots of studies that looked at Britain and those that looked specifically at Ireland seemed to find quite similar results, that there was large migrations from Europe into Britain, and they also reached Ireland. These migrations did not just stop at Britain, they made the leap to Ireland to a large extent. Another study from 2021 found that there was another sizable movement of people from continental Europe into Britain between 1400 and 870 BC. The study estimated that around half the ancestry of later populations in England and Wales comes from these migrants. There are numerous interesting aspects of this study. First up is the fact that many point to this migration and the timing of this migration is potentially being a vector by which Celtic limeges were introduced into Britain and Ireland. Probably fraught from south-western France or southern France. The study pointed to, if memory serves at least. This interesting feature, there is a debate about how Celtic limeges were introduced into Britain and Ireland, or if they were introduced. Some argue like Barry Cunliff, who's the Emirates Professor of European Archaeology at the University of Oxford, that potentially Celtic limeges originated as a lingua franca, essentially a trading language in the Atlantic zone. And basically originated, the proto-Celtic limeg anyway originated in Britain and Ireland, and then dispersed from there, and then moved into Europe easterly. Where is the other argument? Essentially argues that Celtic limeges originated in central-western Europe, and then migrated west into Britain and Ireland. There is obviously a debate and it's not like the debate is closed at all. This study was obviously interesting, however, the fact it noted that there was a migration around the time that would make sense for Celtic limeges to be introduced, if they were indeed introduced, from Europe into Britain and Ireland. Another interesting point to note is that lack taste tolerance, essentially the ability to digest milk, seemed to spike the tolerance of people that were able to digest milk in Britain and Ireland, seemed to increase rapidly around this time of the migration. Potentially signalling that these migrations had their part to play in this, although it is debated by experts exactly why this happened, exactly why more people were able to digest milk around this general timescale and the period after this timescale. I am actually going to explore this in a little more detail as there seems to be a relationship between ancient Celtic cultures and the ability to digest milk, but like I say, I'll explore in more detail in a future video. Obviously, as a quick caveat, the further back you go in time, the more complicated things get and the harder it is to trace migrations and the increase there is an increase in the margin of error, just given the timescales we're talking about. So bear that in mind given this research, but hopefully I've given a good overview of the ancient history, genetic history of Britain and Ireland. But what about the genetic history of Britain in the north of Ireland in more recent times? The Romans, the Vikings, the Anglo-Saxons and the Normans. What impact did they have on the genetic makeup of Britain in the north of Ireland? To find out, please click here. Thanks for watching. Please subscribe and hit the bell and tell your friends and family about this channel for ways to support this channel, sorry. They will be in the description below as well as all the sources used in this video. Thanks again for watching and I'll see you next time.


We're coming to our presentation today with Dr. Barnes. Dr. Barnes is the chairman of the Department of Sociology and Criminal Justice at the University of Incarnate Word, where he teaches a course on social history of holocaust and has visited numerous holocaust sites in Poland and Germany and will soon be visiting the holocaust site in Latvia and Lithuania. And I'd also like to thank the holocaust museum, learn and remember programming committee for the library as well as the library foundation for their support this presentation tonight. So without further ado, Dr. Barnes. Thank you. Welcome. Thank you.  It's nice to see everybody here. I especially want to extend a greeting to my good colleague on the back row, Dr. Gilberto Hinajosa, professor emeritus of history at Incarnate Thanks, Gilberto, for coming. The theme for this year is learn and remember, is resistance. And so I thought it might be a good time to make a presentation on the largest, and obviously the most important of the revolts, the uprisings, and that's what happened in Warsaw. So this is on the uprising. Before I get started, I just want to say hi to my good buddy, Howie Nestel. Howie is one of the co-sponsors of learn and remember. That's a pleasure to have you here. So first we locate Warsaw. Warsaw is kind of in the north central part of Poland, right here. It's just straight north of Radom, a little bit northwest of Lublin. And Krakow is down here. This is the map of Poland as it looks in 1933. This map has changed. The boundaries of Poland today are different than what they were then. Warsaw was indeed the major center in Poland of Jewish life and Jewish culture. Its population of about 350,000 Jews. So about 30% of Warsaw's overall total population. Today, sadly, there are very few Jewish residents in Warsaw. Indeed, Poland itself.  And by four weeks' time, the German army was in Warsaw. They entered Warsaw on the 29th of September. Immediately put into operation a youth and rat by Jewish council under the leadership of an engineer named Adam Schoeneikoff. And within about two months, it was dictated that the Jews must wear white armbands with a blue star data. Jewish schools were closed, property confiscated. Jewish men put into forced labor. There's a picture of Schoeneikoff. If you look closely, you see that there's an SS officer in the back. Warsaw ghetto was established after about one year of Nazi occupation in Warsaw. It was established in October of 1940. All Jews residing in Warsaw and adjacent areas were forced into the ghetto. So the ghetto population swelled to about 450,000 people and all. The ghetto was surrounded by a 10-foot tall wall with barbed wire on the top of it. It was a very, very crowded, 1.3 square miles total for these hundreds of thousands of people. And that meant that on average, an apartment might have seven, eight, maybe as many as 10, people crammed into one room.  It was horror. Starvation, disease, death on the streets was a common thing, unfortunately. By mid-1942, roughly about 83,000 people in the ghetto had already died because of starvation. This is a map of the ghetto. And if you allow me for just a second here, I want to kind of just alert you to a couple of things here. First of all, you'll notice that the ghetto was separated into what was referred to as the larger ghetto and the smaller ghetto. And the two were connected by a footbridge on Chodna Street, which enabled then the inhabitants of the ghetto to move from one side to the other as they needed to by going over the footbridge. But with a terrible sense of irony, it also allowed non-Jewish Poles to pass through on Chodna Street and to look into the faces, look into the homes of Jews who were crammed into the ghetto. The Umschod Plaza is up here at the very top. That's the assembly point adjacent to the railroad, from which the trains would leave to Treblinka, one of the six extermination camps in Poland. Very importantly, almost all of Warsaw's Jews when shipped to extermination camp were shipped to Treblinka. I have students that ask me, why were all six of the extermination camps in Poland and not in Germany? But Germany had thousands of concentration camps, war camps, and the like. But the answer is that a Jew in Germany had a better chance of surviving the war, surviving the Holocaust than did a Jew in Poland. At the outbreak of the war, about 3.3 million Jews resided in Poland total by the time the war was over with, that population was down to 300,000. In other words, 3 million of the 3.3 million Polish Jews were killed. The answer is why the extermination camps, Auschwitz, Treblinka, Kiel, Nostlvogor, why they were located in Poland is that's where the bulk of Eastern European Jew relived in Poland. So you put the ghetto adjacent to the trains, trains go into the extermination camps. This is a street called Miele Street. One of the resistance organizations had a bunker on Miele Street. We'll come back to that in a little bit. The great synagogue is actually located right here, just outside of the wall proper. Down in this corner of the small ghetto was an orphanage for over 200 children that was run by Janusz Korsak, an educator, pediatrician, writer of fiction, humanitarian. This is where the Ringelblum archives were actually hidden. More on that in just a little bit, too. And Pabiat Prison, which was the head of the Gestapo, was housed right there. So that's the lay of the 1.3 square months of the Warsaw Ghetto. Here's a picture of the ghetto walls. It's taken from inside the ghetto looking out. So all the buses and trailers are in the non-ghetto part. And here's a picture of the bridge over Shladow Street where workers would often have to pass from their apartments or their homes to wherever it was that they were working. Some fair amount of people were employed, at least early on in 1941, in the ghetto. And they were employed doing different kinds of things. I'll show you a picture of that in just a second. This bridge became somewhat important. This is a picture of Janusz Korsak. Quick story about Korsak. He was a brilliant man, and a very kind pediatrician, and writer and filmmaker. And when German soldiers came from Korsak's children, about 195 of them, when they finally got there, they were going to take the children. And legend has it that one of the SS officers made an offer to Korsak that he could smoke him away. He would smoke Korsak away. And Korsak said, no, I'm going with my children. I will not abandon my children. And so he dressed the children up along with his staff, his nurses, and dressed the children up in very nice clothes, gave them toys, and this caravan took off to the train. Korsak and all the children were killed in Treblinka. As time went by in the ghetto, it became apparent that there needed to be some sort of a record of what was going on in the ghetto. And so Emmanuel Ringelblum decided that they would create an archive. And this became known as the Ringelblum Archives. Milk cans and crates were used. And in all, probably about 35,000 pieces of material, diaries, firsthand accounts, just a wide array of material was stuffed into these and other cans and hidden. There are still, the Ringelblum Archives were uncovered in 1946, but not all of them. There is still a set that has never been found. Speculation is that it resides under what is today the Chinese embassy in Warsaw. But so far, it still is in hiding. This is a picture of the great synagogue, really beautiful, beautiful place. Pavia prison, the head of the Gestapo, offices there. Pavia, there's what Pavia looked like on the left earlier today, what remains of Pavia. In 1944, the Germans destroyed the prison entirely, reduced it to rubble. There's only just a little bit of sections of Pavia that exist today. This is a scene from the Umeshak Plaza, the assembly point, where people would be loaded on the trains to Treblinka. I want to show you a set of photographs that I think, in some ways, don't even need any direction. William York was a German soldier ordered to take pictures of ghetto life, and he spent one day in the ghetto and took a lot of photographs, about 160 in all, and what follows are some of these pictures. I don't know, make one commentary here. This is just a market scene in the ghetto. You see a lot of children in this picture. Some of them, like a little girl over on the right, smiling, a little boy smiling at the camera. It is entirely conceivable that every single person in that picture, every man, woman, child, was exterminated at Treblinka if they didn't die, first of all, from starvation, disease, and the like. Here's a scene of some men selling rope, another one. It's kind of interesting about this. This is a man who is selling armbands, only for just a small amount of money. But what's kind of striking about this is that some of the status distinctions that existed in the Jewish community between the haves and the have-nots is evident even here in the ghetto, as you can see the young woman dressed nicely behind the vendor. And it was the case that some people in the ghetto simply lived better than others, unfortunately. But these kinds of scenes were what Willie York stumbled onto in his one day. Disease, death on the streets, starvation, sickness, dysentery, an older gentleman, armband. You see the children looking at her, she's looking at the photographer, some sense of. And here we see a couple of young women. The speculation is that these two women were sisters, death on the streets. As I said, some of the lucky ones were able to work. By that they were able to make just a little bit better in terms of food rations. And at least while they were working and doing something that the Germans considered useful, they were not going to be subject to extermination right then and there. So they got to live a little bit longer. Here's working a boiler factory, a man-making dowels, men and women both, a sewing factory, making things for German soldiers. And then here's a large picture of workers in a textile factory. I'm using an idea of the kind of labor that people in the ghetto were put into. This is big. The Grosjeckion Warsaw 1942 starts in the summer, in July, with the SS communicating to Schernykoff and the Judenrath that the Jewish population was going to be resettled to the east. That was the big groups. They were going to be moved out of the ghetto and moved away from military confrontation. We moved to the east. Schernykoff knew that probably wasn't a kid. He's a community suicide four days after this announcement. And the great action, Grosjeckion, goes from July 23 to September 21. People could be crammed, about 100 people in a cattle car, roughly 5,000 to 6,000 people every day, shipped out to Treblinka. Treblinka was not a concentration camp. It was an extermination camp, which meant that upon arrival, everybody who was there was exterminated or gassed. And in total, during the great action, probably about estimates run around 250,000 or 265,000. But maybe some scholars say maybe as many as 300,000 died in this short period of time. In all, at Treblinka, estimates vary. But the United States Holocaust Museum estimates that at Treblinka, about 835,000 people perished. Of course, that's about 1.1 million at Auschwitz, so you can see that Treblinka has a very high death toll. This is an announcement, a notice that was posted in the ghetto, prominently displayed everywhere. Yes, sir? Have you been to Treblinka? Yes. Is it still here? Huh? It's still here. Well, yes and no. Auschwitz, most certainly, still is physical space, especially at Auschwitz 1. There were three Auschwitzes, 1, 2, 3. And the one that we're most familiar with is actually Birkenau, which is Auschwitz 2. Auschwitz 1 was an old Polish military encampment.  Birkenau got its name from the white birch trees at the back of Birkenau. And those white birch trees still stand today. They look very beautiful in such a horrible place. The last time I was in Auschwitz, I got up under the train station. Maybe you've seen pictures of the famous train station at Birkenau. And at the top of it is a room about this big with windows all the way around. And it looks out.  It is so large. You can't see the back wall, the back section. It's just absolutely huge. This gives you an idea. Is the Warsaw ghetto destroyed? Oh, yeah, it's been completely destroyed. And there's remnants of the wall in Warsaw that still stand today. But you've got to know where they are. Go find them. And there's not that much left there. But the entire ghetto was raised during the revolt. And the Treblinka, I should back up and answer your question as regards Treblinka and what's there today. There was a monument. I'll show you a picture of it in a little bit. And there was about 18,000 stones, markers, memorial markers, scattered around the grounds where the crematorium actually once was. At Treblinka today, when the Germans moved out of Treblinka, literally because they had exterminated all the Jews in that particular district. And Treblinka had done its job. So when Treblinka was shut down in 1944, they literally bulldozed the entire place. They destroyed everything at Treblinka. Every building, every post, every barbed wire fence, every watch tower, they didn't really, they had barracks. But not big barracks like at Auschwitz, which was a combination concentration camp and extermination center. So then after they destroyed everything at Treblinka, they brought dirt up from another Treblinka camp, Treblinka 1. And they simply buried the entire area under four feet of dirt. So the archeological excavations that are going on now are digging down and finding what remains of the crematorium and the gas chambers. But you've got to go down four feet and work your excavation from there. Did the people there still remind you of that? Did they what? Did they want to be reminded of it or did they want to forget about it? I'm sorry, I'm still not hearing you. Did the people there in the areas want to be reminded of it or is it just not true? First of all, Treblinka was not in a major population area like Maidaniq. Maidaniq is in Lublin. It's like right in the middle of the city almost. But Treblinka is in a very remote spot far away from villages, towns, and shettles, communities. And so there was nothing around Treblinka. It existed all by itself. So once the Germans moved out of Treblinka and blew up what remained and buried it under dirt, the forest is reclaiming it. And that is true of major sections of Treblinka today. The forest is just plain reclaiming it. This gives you an idea of some of the actions and the numbers of people who were shipped to Treblinka. The shipments began, of course, with the most vulnerable, those who were homeless, those who were destitute, those without any money, no means of escape. People would be brought up by the hundreds or thousands every day, paraded through the streets to the Umashuk plots, to the transfer point at the railroad, and loaded onto the trains to Treblinka. And it's about 50 miles away. So it took an afternoon or a morning to get there. And this is an outline of what Treblinka looked like. We've had to go back and kind of re-figure and reconstruct based on some memories of what the camp actually looked like. Two very important things here. The extermination part of the camp was right here. These are pits where bodies would be buried and burned. Trains would drop people off here. There's an assembly point here and an assembly point here. And this would lead out into the gas chamber. And the Nazis called this the path of heaven. That was in fact the name that they gave to those places that led into the gas chamber. Not just at Treblinka, but at Sobibor, Khyomno, other extermination camps. The path. The big action in Warsaw. About 50 to 55,000 Jews still remain in the ghetto. And it was pretty evident by the fall of 1942 that extermination was in the cars for everybody. Despair began to give way to resistance. Resistance organizations were formed. And there were two main ones. But there weren't a lot that Jews in the ghetto had with respect to firearms. Mostly they had to do with homemade grenades or homemade bombs, what we would think of as Molotov contents. But they had very few small arms. And no real, no machine guns or anything like that. So the resistance was going to be very, very weakly armed. But what became evident, though, during the Warsaw revolt was that these fighters were going to determine the time and the nature of their own death rather than be dragged to the trains and shipped off to Treblinka. And it was, from the very outset, it was pretty clear that this was going to be a doomed revolt in Warsaw. In January of 1943, Henry Kimber, the head of the SS, made a visit to Warsaw and ordered that 8,000 Jews on the 9th of January be sent immediately. And then if the Jews fought back, the residents of the ghetto fought back. Only about 4,500 to 5,000 of that day's shipments of a planned 8,000, in fact, were shipped to Treblinka. And then following the very brief revolt in January, the decision was made by the SS to just suspend deportations until April. And two resistance organizations that took shape in the Warsaw Ghetto. There's the Bowska Organizanka Vova, which translates into Jewish combat organization with the initial ZOB. That organization was comprised of younger-aged people, a lot of students, probably totaled somewhere around 220 fighters in all, no more. And Mordecai and Levitz was the head of the ZOB. The Dziowsky Dzizwak was a Kawi, translates into Jewish military union. It was comprised of a lot of former World War I soldiers, Polish soldiers. And was the larger of the two main resistance organizations, about twice as many people, 400 in that organization, the ZZW. And the head of that was a relatively young man named Paweł Prankl. So those are the two resistance organizations. And this is a picture of Anna Levitz. He dies in the bunker at Mila 18, along with other ZOB fighters in the next month. As you'll see here in a little bit, the Yorovalt and the Warsaw Ghetto lasts a grand total of one month. Starts to finish. And that's a picture of Paweł Prankl. We don't have any photographs of Prankl, so we have to rely on artists' kinds of go-back and draw a picture. So here's the timeline, OK? Jürgen Strupp, the commander of the SS in Warsaw, replaced the previous head, who Hemler had considered to be weak and inefficient. Strupp arrives in Warsaw on 17 April. And the SS enters the ghetto in mass on April 19. They begin a massive burning, a raising of the ghetto. Eventually, they will destroy every building in the ghetto. In one act of defiance on the 19th of April, the Polish national flag and the banner of the ZZW is raised on a building, plainly seen by people in the ghetto and people on the other side of the wall, infuriating to Strupp and to Hemler. But it was up there for four days before the SS finally succeeded in having it come down. That picture, and we don't really have a picture of it, but that image of the two flags flying together is a very powerful one today in the State of Israel. It means a lot to Israeli citizens. However, in 10 days, all the ZZW, the Jewish Military Union, they're all gone. Commanders have all been killed. And what few fighters are left, flee to the forest. And then the SS discovers this bunker at Miele 18. And that's where Anna Levitz and some other ZOP fighters make their final statements.  And then Strupp personally sent the dynamite to blow up the great synagogue. And shortly after that, sends a report to Hemler about the success. And in the report, famous line is, the Warsaw ghetto is no more. That literally was the case. So there are four copies of the Strupp document, four sets. They were used, or this one was used at the Nuremberg trials after the war as evidence for the Nazi atrocities against Jewish residents in the ghetto. And what I'm going to show you now is a set of about 25 or so pictures, strictly out of the Strupp report. These were taken by documentary units that were connected to the SS. And they simply photographed the destruction of the Warsaw ghetto. We start with Strupp himself. That's the general, actually a major general, in the middle, looking upwards. You can see the buildings are already ablaze. Here's Strupp reviewing his troops. And a radio command post that allowed Strupp to communicate to those he needed to communicate to. The resistance fighters were hungered down in bunkers. It might have been as many as 600 bunkers that had been built by the Warsaw ghetto residents. This was a scene of a typical bunker. Here's another, and this one you see, a resistance fighter down even lower, another bunker. So they were hiding out on the bunkers. They were sniping as best they could at German soldiers. Of course, this was doomed to failure. Every resistance fighter knew that. They knew that they weren't going to succeed. But it was symbolically a great deal. Did the Germans take those pictures? Yeah, sure did. This was taken by German documentary teams that just followed right along with Strupp's soldiers. This traipsed right along with them into photographs of the entire raising of the ghetto. And this is what the raising of the ghetto looked like. Building by building, apartment by apartment, brick by brick, every building in the ghetto. The place was a blaze, clearly could be seen by people beyond the wall by Polish citizens. Smoke fire pouring out of windows as just one day after another, routing out to resistance fighters. Sometimes rounding them up and marching them to the Umshog class for shipment to Blinkett other times, just shooting them out of the spot. Here's a picture taken on the other side, the Polish side of the wall, with smoke pouring out of a ghetto building, which is the destruction of the ghetto and of course thousands of people. You can see a set of pictures now of men, fighters, leaking to their death, trying to escape the fires, the smoke, or the simply opting for suicide. And here's a man falling from an upper window. Another picture here, a woman. Many of the resistance fighters were women. Many of them that you're going to see here are some upcoming photos. People who have left to their death on the sidewalk, SS soldiers in the foreground. And then a series of pictures of people who were captured. Of course, this picture. I'm sure some of you will recognize this picture. It's a very famous picture, very iconic picture. We really do not know who the little boy is. Nobody knows who's certain. But that's a pretty powerful image. Resistance fighters, men and women both lined up against a wall to be searched for weapons. So what happens to these folks is one of two things. They're either marched to the trains and shipped off to Treblinka, or they're simply shot. It's an interesting picture. Free women who have been captured. The woman who's kind of cut in half on the far left, she perishes at Treblinka, as is the woman who's in the center. But the woman on our right survived the war. Fighters who have been captured. This, too, is one of the really somewhat famous pictures of the war-solvable. I've got two photographs here that were taken within just seconds of one another. This is one of resistance fighters who surrendered and are being marched. And then this is a little closer up picture. It's not the same one. But we know who the people are in this photograph. They've been identified. And the two women in the front and the little girl and the man over the left shoulder of the center woman were all members of the same family. This picture is a very important picture. These are resistance fighters being pulled out of a bunker, one of the many hundreds of bunkers. And I guess it doesn't mean much emphasis to say, you know, it strikes me, maybe you, too, is this picture of the man and the woman over here? These are SS soldiers in the background. These people have just been pulled out of a bunker. And here is a shot of people being marched to the train station to be deported.  Another shot. Now you see the destruction, the physical destruction of the ghetto begins to take a little shape in this photograph. You see the rubble, the bombed-out buildings, the destruction of the woman and a couple of men who were in custody. And another couple of resistance fighters and then another small group. So what you're looking at is what was given to Himmler by Jordan's troop as evidence of what they had done in Warsaw. And the reports are that Henry Kimmler was very satisfied when he saw the evidence of how the ghetto was no more. Fighters who had been killed, these are Ukrainian soldiers who were working with the SS in conjunction with the SS. So they're there. And they're looking at the bodies of the seized resistance fighters. And yes, please. I was wondering, how did they find some of these bunkers? Because with that much destruction, and then some of the buildings were blown up, it looked like they were still able to go into some of those dugouts. How were they able to find some of those hidden bunkers or if people were alive in them? They just went down the street and looked into every building, every nook, every cranny, every hole. And even at that, they didn't find everybody. But it was just a systematic, literally room by room by room. Every building, every bunker, until you just dragged everybody out or almost everybody. I didn't see any dogs, so I just wondered how did they actually find some of it? There were plenty of dogs. Well, yeah, I think we maybe don't have pictures of them, but there were plenty of dogs. Yeah, plenty of dogs. And you fire into the bunkers. You have flame throwers, a sheet down into the bunkers. And so there's ways of chasing the people out. Some of those pictures were staged because they had vicious dogs when they were getting on the trains. Yeah. And I thought, oh, it's got a lot of pictures. By this time, the ghetto had been depopulated or where people still in the buildings while they're. People were still in the buildings. I mean, non-combat. Oh, yeah. Yeah. Yeah, with the population after the big action, the great action, with about 50 to 55,000 people who were in the ghetto, you really only had in total about 600 to 700 armed resistance fires. So only a small percentage of ghetto residents. What was the objective of the resistance? I mean, were they going to stop the loading of people? No. No, they knew they weren't going to stop the loading of people. But literally, the fighters said, we control our own destiny now. We will determine the circumstances, the situation, the timing of our deaths. We're going to put up resistance. And we're going to fight back.  With our coordination. That was inevitable. Was there coordination between the two groups? There was. There was coordination. And then there were ideological differences between the two groups as well. The Zob faction, the younger faction, many of those fighters had Marxist leanings in the Jewish combat in the military union, rather. That organization, the ZZW, they didn't share the kind of left-leaning outlook that the Zob fighters had. But in the end, there was at least some measure of coordination. And just that they didn't have too much to coordinate with. There just wasn't a whole lot. ZZW maintained some contacts with the Polish underground outside of the ghetto. But even that was very limited and very sketchy. Some other street scenes here. That's what the ghetto looked like. Upstaination. That's cool. Where did the remaining population go? Or why is there any remaining population? Let me just go down through all of this. Where did the remaining population go? Yeah, right. Or why is there any left? Not the end. Not the end. OK, you've seen these. I don't know what our computer is doing here. We caught back up to where we were. Aftermath, bombed-out buildings. And there we go. And with this, that's the dome of the Great synagogue. And that was blown up. And it became the last act of Nazi aggression against the Jews. And strut... Is there anything left of the Jews in here? Is there anything left of the Jews in here? No. I'll show you what sits on the side of the own group of the Great Synagogues in a minute. Oops. Let's go here. This is how Stu defined Wayne. After prolonging the suspense for a moment, I shuttered how Hitler impressed the button. With a thunderous deafening bang and a rabble verse of colors and fiery explosions soared toward the clouds. An unforgettable tribute to our triumph over the Jews. The Warsaw ghetto is no more. And at the war's end, if this shot was taken in the spring of 1945, that's what the ghetto looked like. And of course, Warsaw itself was almost bombed, totally out of existence. Hitler unleashed the German bombardment against Warsaw. And 97% of buildings in Warsaw were destroyed in the latter days of the war. Warsaw has been rebuilt today. And if you go there, you might be struck by what a remarkably modern-looking city it is, although many of the buildings have been rebuilt according to their original architectural designs. So you're looking at buildings that you think were built in the 1800s sometime or the early 1900s and they were all post-war. They're all post-war, but they look like their original buildings. Same thing in Berlin. So here's the total. It's estimated that around 13,000 were killed during the uprising. Half of that number died from smoke inhalation or burned alive. The 50,000, roughly, that remained in the ghetto, they were all shipped to Treblinka or Maidanik. Most of them to Treblinka. And of course, all of them were killed. Although I should say the revolt in Treblinka happens after this, so some of the resistance fighters who survived the battle in Warsaw, when they were sent to Treblinka, they participate in the revolt in Treblinka. And out of that number, about 100, maybe, lived to the end of the war. And there were thousands that participated in the revolt in Treblinka. The ones who actually escaped, about 400 to 500 of them, most of them were routed up and killed by the Germans. So in one of his last letters out of Mila 18, this was an 11th, said, wrote a letter to a friend. And my life's dream has now been realized. Jewish self-defense in the ghetto is now an accomplished fact. I have been witness to the magnificent heroic struggle of the Jewish fighters. And I think that captures, in part, the essence of the revolt, knowing that they were doomed, but knowing that they were going to leave a legacy, very important. This was the largest revolt by Jews during World War II. It was larger than the revolt at Treblinka, larger than the revolt at Sobibor, or the many, many other smaller, isolated revolts across Eastern Europe. Our Holocaust Museum in Washington, D.C., has marked this simply by saying, this is one of the most significant occurrences in the history of the Jewish people. And in fact, April 19th, the day for the start of the revolt is a national memorial day in Israel now. And it's very, very famous. The revolt at Treblinka, or excuse me, the revolt in the ghetto was the subject of John Hershey's novel, The Wall, featured in Leon Eurice's novel, Mila 18. And more recently, in Roland Polanski's film, The Penis. So in the years that followed, this is a shot, a picture, that was taken in the summer after the fighting in Europe had stopped, when the E-day had been realized. The man on the far left here is named Sincha Rotem. And that's a picture of him with some other, mostly unidentifiable women. We don't know if they were resistance fighters that had survived, but he certainly was. And I'll come back to Mr. Rotem in just a second. This is a picture of Jürgen Struth, the SS commander. He was tried in a Dachau US military tribunal and was sentenced to death. And then four years later, we did the military, didn't execute him. Then, even though he was under sentence of death, and then the Poles put him on trial in a Polish court and sentenced him to death and hanged him the next year, March of 1952. This is called the Janey Flexion of Warsaw. When Willy Brandt was the chancellor for West Germany in 1970, he made a very important visit to Poland. And he was at Warsaw, and he's gathered at this memorial to the fighters, the resistance fighters.  I didn't say anything. So this becomes a very, the Warsaw Janey Flexion, a very famous picture. And as Brandt observed, and they stood on the edge of Germany's historical abyss, being in the burden of millions of murders, I did what people do, if one war is failed. That is what sits on the site of where the great synagogue was in that life. It's a blue building. No one across Warsaw and then many other parts of Poland is the blue skyscraper. What's the name on the top? Metlite, insurance. This is the Bunker Memorial at Mila 18, where Annie Levitz and the other Zab fighters committed suicide, about two dozen of them, as the SS was closing in on them. And this is what Trablika looks like today. As I said, Trablika is pretty darn remote. But this big marker in the middle here stands where the crematorium was. And you see these stone markers around this? There's about 18,000 of those stone markers. Very few of them have any words on them, although one of the most prominent that does have some writing on it is Janusz Korsak, a marker in honor of Korsak and the children of the church. Most don't have any working on them. And there's two possible explanations as to why there's 18,000 of these stone markers at Trablika scattered around like that. One is that that is probably about the total number of villages, towns, cities, places where the victims of Trablika came from. They might have numbered as many as 18,000 different places. The other explanation is that when Trablika was operating at full capacity, they could execute 18,000 people a day. And since you wrote it, last surviving fighter dies at age 94. You see the date on his death? It's two weeks ago. I share this with my students that we take an event like the Holocaust and we once are relegated to ancient history. We went to say, oh, that was a long time ago and in a different place. The last ghetto fighter just died two weeks ago. Wasn't that long ago? So wasn't that long ago? That's why to come back to this event that Hawi has helped establish. That's why it's so important that we learn and we remember so that it doesn't happen again. And that's it. Thank you. The Holocaust, the year after the war ended in Poland. The Poland, yeah. So when you say it'll never happen again, one year after they killed, how many people? In all of us? Six million Jews? Six million Jews and 11 million in total. It happened one year after. And of course we've had other gemsites in Cambodia that we want to correct, it's absolutely true. I'll tell you something about that name. Simpa in Hebrew means have your joyous occasion. And 18, the numerical value 18 in Judaism means life, I brought it in. So in any derivative, you know, 1,000 you can still do right up in the slide. It's very good. For the two letters that make up. Yeah, I'll tell you a quick, just to blank a story. I went with the human rights group three years ago at Christmas time. I'll be going back to Poland again this coming Christmas. This group travels to the extermination camps in a couple other places between 18 December, 30 December. So you're not home for Christmas. And you go at that time of the year and keep your fingers crossed that the weather is cold and nasty and cloudy and dark. Remember that Treblinka? We had about 20 students with us and one girl was dressed in a red jacket. And she wandered off where all those stones were in that area. She wandered off by herself and she positions herself looking into the forest and didn't move for five minutes. For 10 minutes. And so I talked to my friend, Dr. Rick Halpern, who kind of coordinates these trips. And I said, Rick, you can one of us on a go over and tap her on the shoulder and see if she's okay. And he said, no, I've seen this before. We grew up. And after another couple of minutes, looked up again and she was back with her student colleagues.  That these are very powerful, very moving experiences to actually go to the places and put your feet on the ground where these atrocities took place and they impact people in a variety of different ways. I don't know whether that girl was thinking or what she was processing. You can all imagine all sorts of scenarios for her. But there was something about her to just separate momentarily, stare into the forest and then return.  Thank you very much. Have a good time. I appreciate your coming. Learn and remember is a powerful set of events. So we thank you for your leadership on this. And so, any other, any questions or comments? Or do you have some of these bright political parties in Europe or re-emerging in China? Poland, certainly, because, yeah. France. France. All over, yeah. So, right here at home. Well, you know, the right here at home thing is kind of interesting because we, when taking students on these trips, have found that you don't have to do a lot of explaining. And while the parallels don't work perfectly, we're saying they don't work easily at all. But still, the nationalist movement that is occurring in the Western world, the United States included, it's interesting how quickly students pick up on this kind of stuff. And say, yeah, yeah, I get it. I see it too. So, other questions or thoughts? Well, I said to myself, I'm gonna keep this to one hour. And I'm looking at the clock, and I think we succeed. We'll see.


Hey everyone, my name is Andrew Gaul, today I'll be talking about maintaining an open source project while sustaining your sanity. If you'd like to follow along with the slides, you can see them at gaul.org slash talks. A little bit about me. I'm a maintainer of several small and medium sized projects. What these projects do in particular is not important, they're cloud related. But I've been working on them for five and 10 years now. And it has some thoughts on how we've sustained those over a long period of time. These projects have only a few maintainers, a larger number of contributors, and a much larger number of users. More than the maintainers can really satisfy all the issues. The virtual format makes this difficult, but I do live in Tokyo. Okay, let's define what project maintenance means. So there's a lot of different tasks in here, more than just programming or generally software engineering. So it's working with users, triaging issues, cutting releases, scoping the project, coordinating contributors, working with external projects, improving quality, and writing new code sometimes. And as the commit strip comment suggests users believe that there's a lot of different individuals doing all this. But there's usually just one or two people that are actually working on these projects. And so it's pretty difficult to do everything. So you will burn yourself out if you try to do everything, try to all of these maintainer tasks and all the programming and all these are interaction. And so to sustain your sanity, I'm going to recommend that you consider your project from different vantage points. I'm going to map these onto functional roles at companies, but it's kind of a series of values about different people in the process. And to do this, you have to try to do less work, but different work over longer periods of time to sustain the project. And this may allow you to keep the project going for years. But you'll have to make a deal with the devil. You'll have to get into management, which is challenging for ICs like me. So the project maintainers wear many hats. The first of which is the product manager hat, where you advocate for the user. The second is engineering manager we advocate for the team. Third is technical lead we advocate for the code. And so this talk explores these three roles and what you can do with few resources and lack of corporate sponsorship. The first role is doing only a product manager. And this, this role is really advocating for the user. And so the first thing you want to do is evaluate the project against the ecosystem. And there's a lot of different sources of information from hacker news to stack or workflow on Twitter. But you're trying to see what people are saying about the project that may not be reflected in your issues. And so this, these could be compatibility with other software. It's the incompatibility in another piece of software that the bugs found there. But it's actually related to your project that maybe you can do something to help them, or maybe people are complaining about performance or some other use case they don't think scopes in, and there's just not an issue for it. The second important thing pms do is they think about how users interact with the project. And this could be configuration right like how do you actually set this up or they're saying ways to do this or is required a bunch of fiddling with different bits doesn't work at a box. Are the releases regular releases that users are consuming or they have to compile it themselves. Packaging, are you in the, are you in Linux distributions are you in on Docker hub. It is easy to start using your project documentation is important. In one sense just to tell people what's going on, but also to protect your time so they're not constantly asking you how do you use the software scaling trick. And backwards compatibility is an important thing as well. In the real world people mix and match software versions and data formats, do you fail cleanly when you try to use an unsported configuration you corrupt your data. How does it actually work in these mixed environments. The third thing that pms do that you're probably more familiar with is prioritizing the features and critical fixes. And so if you have to evaluate the project. You can, you can kind of determine what's most important and say that hey this this is something we want to address sooner rather than later. There are other tricks here, but not everything requires like a code solution or even a clean code solution. If there's an easy immediate workaround for a user, either, you know, avoiding a certain configuration or turning off a feature, or something that works around things in the short term that that's oftentimes more impactful. Immediately, then saying hey can you wait six months or maybe never to get a proper fix. The second thing I would say is that pms like a competing projects competing some of a nebulous term in the open source world, but there's essentially things that we can coordinate on so that it doesn't stress out users as much, whether it's similar terminology or sharing between different projects. Maybe if you think with the SQL ecosystem from my SQL to SQLite, trying to have code run on all three is pretty difficult and if they had used similar, similar words and sounds that would have been better. Okay issues, issues everywhere. So most projects are drowning and issues, things that are not able to be immediately addressed. But these can be the highest quality feedback from your users. Some people really go out of their way to minimize a test case or tell you exactly what's going on or test the latest version and the development branch. And so issues can be super, super valuable. Or they can be a junkyard of vague unresolved symptoms and peace. Usually a little bit of both in my, my experience. And so the way that you can improve your issues is that you want to groom them. And so this is to help you understand the state of the project, you know, what are the most critical issues, you know, what's, what's still pending. But also to help your users understand the project. If you attach the right kind of metadata, you can tell them, you know, nobody's working on this right what help or something like that. You can, you can say like hey this is really your responsibility to move forward on this. And so the three things that will improve the average quality of your issues are clarifying the issue, you know, how does this happen. You know what configuration are using which version do duplicating issues. Oftentimes a popular should be open several times because people don't understand that the commonality between that and the previous issue. I'm finding closing stale issues. Somebody's not working on. If it's not actionable. If there's not enough information it's been stale just disclose it. It's okay. Somebody will open another issue again someday maybe higher quality one. And the two bits I really want to emphasize here is I like to mark issues with the help wanted label and the need for label. The help wanted means that users that no one's going to work on this and it's requiring a user to step up as a contributor and to fix it for the project. And in this kind of avoid some silly comments like when is this going to be fixed. They see the help wanted they will hopefully they understand need info is a good one as well. If you can't act on an issue if you're waiting for something just swap that need info, they blow on it and this this avoids ambiguity and misunderstandings. Sometimes the bug reporter is waiting on the maintainer and maintainer's been bug reporter and things just stalemate accidentally. So try avoid that. I'm going to do a couple case studies as we go through here. I'll talk about some of the projects and the problems and successes we've had. The first is S3FS. This mounts S3 bucket as a file system. It's a very old project. I came into it. It's not seven or eight years ago. It's hard to remember when. And there were tons of issues and I was just trying to understand what's what's going on in this project. And the grooming process revealed that there were two major themes that I thought were actionable. The first was a small issue where POSIX or Linux permissions those kind of 644 and 755 bits. They mapped poorly onto S3 objects and created an interoperability problem with using other S3 apps. And there was a workaround for this that someone had contributed that you just needed a flag with the compliment of the bits or something like that. And it was super unintuitive to do this workaround. This was actually a really satisfying and 20-line pull request that fixed multiple issues, both in GitHub and on Stack Overflow simultaneously. And it was so little effort that I felt bad that we hadn't identified this earlier in the project. The second major theme that grooming revealed was that there were multiple symptoms of data corruption. And this is kind of the most important thing for a file system, like do not lose data, you must return the data that user wrote into it. So this was not simple. We iterated for years with users trying to understand the symptoms, things that couldn't be reproduced. We had to improve testing and kind of evaluate new tooling to find some kinds of race conditions. And there were several bug fixes, more than several actually. It was a long campaign, but over the years we were able to improve the reliability and I don't believe there's any open issues today. The downside of this grooming was that there were hundreds of other issues. There was good information in there, but we couldn't act on it. There wasn't enough contributor or maintainer engineer hours in the day to work on this stuff. So I beautifully categorized these and tried to see what they were and then promptly ignored them in the short term. But then we've been making slow progress on these. And so the issue count kind of trickles up, it kind of slowly increases over time and then as we groom things over three months it'll dark down. And it's generally speaking that this variety of issues is going down over time, even with a larger user base. Okay, working with users. I love users.  They are some of the most helpful people you'll meet that are logically part of your team, even though they don't write code. They're neutral. Many users are just neutral. They're reporting bugs and they're kind of doing an okay job and thank you for your effort. There's a third class of people that are less pleasant, break the standard to two categories. There's just angry people in the world and they find their place on the internet and they make some noise and just recommend ignoring them and not getting bummed out about it. There are abusive situations and please do report those if needed. The second class of kind of annoying users are entitled people. And these people keep asking, you know, when's the fix or, you know, where's the progress in this and you can usually see this more on client, client end user software than back in infrastructure stuff. But these people, they're not bad people. I don't think I think they just, they misunderstand their relationship to the project. You can educate these people. The phrase I like to use is this is a volunteer project. Pull requests are welcome. Just making it clear that your time is not their time, right? They don't have any control of you. And in fact, I would flip the script when you think about your users. Users should work for the maintainers. The maintainers are fewer than users. Users have, there's more of them and they have more time. So if you work in the clarify users, clarify issues and to test proposed PRs, investigate workarounds, improve documentation and wikis, sometimes you just have to ask them, hey, can you look into this? And it's just kind of increasing your team, which we'll talk about later. Okay, putting your PM hat on, I would say that releases are important. Some projects, especially older projects that don't run releases very often. Maybe every couple of years, even when they're merging commits, and at least the kind of forks and kind of duplication and confusion. And so I just emphasize that most users consume release versions, not development branch. So you really want to have regular kind of time based releases, this is pioneered by Chrome, but I think that you don't need such an aggressive four week schedule that can be exhausting for users. But I think even every six months is valuable. And so I plan to run a release of most of my software every six months, even if there's not a huge number of changes. Still people are waiting for some of those those fixes. And of course, if there's an immediate critical bug fix, you try to run a release sooner. In terms of sustaining your sanity, you want to avoid buggy releases. And so this is twofold. One is which is it's bad for your users if they're having buggy code and it creates work for them. The other thing is it actually creates work for you when they file an issue saying hey this this release doesn't work and there's kind of a long tail of people using old versions of the moment that you will essentially be re diagnosed in the same bugs for until those older code filter out of the ecosystem. So to avoid buggy releases I open a tracking issue. I ask some of the users to test it like people are waiting for these releases they're usually happy to test it in their environment. You have to you have to slow down changes during this time. I've had some situations where I had to open PR. I said, you know what this is too risky for the next release we're just getting it next time in six months. And that's okay. You want to be aware of users reporting new bugs against old versions. So this, a lot of people let people run older versions of software and it's worth understanding why there's oftentimes stale Linux distribution packages or API breakers to prevent upgrading important regressions. But these these new bugs against old versions you're basically making more work for yourself. If people are using the old code. So if you can measure them onto the new code, especially mentioned in your issue template, you know, please report against the latest version, and repent to free up some time for yourself. Okay, part two thinking like an engineering manager. So again this is advocating for the team. And maybe the most important thing to do to advocate for the team is to manage the project scope against the goals of the project and the volunteer effort you have available. The second thing that an manager can do is, they can bring more people and resources on to the project is kind of a couple of hacks for that we'll talk about. Third is coordination with extra projects. So you're upstream and downstream dependencies independence and finally dealing with forks kind of a quirk of open source. We have a lot of different conditions of the same thing. Okay management the team. So this, this differs from your normal manager kind of mindset, because usually you can't help people with to do. You can't ask them for help. And you shouldn't feel shy about doing this, just at mentioned people on GitHub. Hey, could you, could you look at this PR you worked on on a similar feature before. And this this is important because people, people don't watch the repositories and times where there's a flood of email or they're kind of batch processing, whatever it is. So the manager should try to identify, are there any blockers to new contributors to bringing these new people onto the team. And so the most important one is, do you have a bad environment.  There's there's projects I choose not to contribute with because there's one or more people that are just not a lot of fun. And I like, like this you're short. So build issues is maybe the second and more easily addressable thing. Can can users build your software out of out of a clean environment. So there's been a lot of progress with containers and other kind of mechanisms to deal with this. But generally is this project easy to run the unit tests on is kind of a metric that you should strive for. And to some extent, you know, there's the continuous integration you set up will have a configuration and figure this out, but you might need some documentation as well. So there's technical debt. If the projects to this was too rotten. If people don't want to contribute. It's just, it's difficult and it's not fun. If you're using older dependencies or older versions of software. It's, it's just exhausting to kind of go back in time and these things that are kind of semi broken. So if you're using license, my employer doesn't allow me to contribute to projects that only have an open source license. So please add one. And lastly, a clear code formatting can block people contributing. Especially in the review process if if you're having to comment on a lot of things and the user has to iterate with you on PRs to have your perfect code formatting. It's usually a bad time and annoying to the reviewer and contributor. So if you use anything that's automated like go format or the equivalence and see if I've lost the job. That tends to be a better experience for users instead of trying to guess what you're thinking. Okay, managing team, you can you can actually nudge issue reporters into becoming contributors. A lot of people are reluctant to, to try to contribute because they don't know where to start code is big, right. Most projects have tens of thousands or hundreds of thousands of lines of code and we're potentially much larger for big projects, but people don't know where to start. So if you just tell them, hey, can you go look at this, this file, right, you probably want to write a test in this other file that can kind of overcome some friction and get you a free fix sometimes. This is an outsource testing of PRs to issue reporters. They tend to be pretty motivated to test these things if it resolves their symptom. So, you know, don't test it yourself outsource it to them.  So do you have a good relationship with your upstream projects, but do you report issues, you know, do you tell them like how the software is working or not working for you. Okay, managers should aggressively manage the project scope. And so there's a common anti pattern in open source software. We try to be everything to everyone. It's just really compelling that somebody comes by with a pull request passes the unit tests, you know, why not add this feature. And I, there's a lot of good reasons not to your maintenance burden will increase. And all those changes need to be merged upstream, even well written ones. And so look at, look at the, the contribution to say, you know, does this make my burden heavier lighter, if it's heavier. Can I ask the contributor to maintain that code. So came willing to merge this but you need to deal with all these issues that's my expectation. It's very easy to, to widen the project scope and take on new tasks. It's very hard to shed them. This is because there comes constituency within your, your project and one noisy contributor will say like hey I contributed that and I'll fix it, fix any bugs, even when they maybe they don't. I'm keeping practice of saying no or not yet, early and often. It's actually fine. You want for people's feelings just be clear with them about what you're doing. I have a kind of a negative case study for this. So jClouds is a Java cross project structure. This project was very popular 10 years ago. I had a lot of activity, both from contributors and users. The containers have shrunk over time. And this despite their, they're being a kind of stable user base and downloads that we can observe. And what's happened is, is a bad situation where there's more work being done by the fewer remaining containers. And so we take on a bunch of scope that we couldn't manage people that advocate to their feature that disappeared, or people that wanted kind of infinite backwards compatibility. So we just shrink the scope of the project. Kind of right size it. And there were a couple of people we tossed out a bunch of code that was, was unmaintained that there was no one that would maintain it and, you know, get you can always bring things back in later, just revert to commit it's fine. So we remove that stuff that was at flaky tests and that kind of thing. We outsource some difficult features to separate projects, things that we didn't have the expertise for we couldn't maintain. So we just jettison them. We did find other maintenance to them in this, this case, that's not always possible. We dropped a lot of backwards compatibility. This, this was really painful because they're, they're getting interesting hard to run both the newer and older versions of Java. And so we, we had preferred the old versions for reasons that are kind of related to the Java system, but that was the wrong choice for us. So we had preferred dependencies. This the sounds benign but it really wasn't some of these dependencies are really tough, where they have incompatibilities between versions and it breaks other people's downstream software. And so we had to make tough choices there to go forward. And finally we're optimizing the release process. We had many repositories to begin with, and now we're down to four, and that really should be one, just to make things as push button as possible for making a release. It's currently like 100 different steps to run a release and so you end up running releases less often, which is bad for users. And some of the sad thing here was a lot of these changes should have made years ago. We just made their own choices, and not that we're bad people. I don't think, but we just didn't think about our maintenance burden in a very rigorous way. We just kept saying yes. So moving to the forks. Forks and kind of re-implementation have several causes. The most benign of which is users just they need to fix now, they cherry pick a fix into their repo, and they will rejoin you in that release. So don't worry about those people, unless there's a lot of them for some reason go and release them. Or just local functionality that's inappropriate or not ready for mainline. Maybe it hasn't been made high quality enough or doesn't address all the use cases that you want to see done. But the last kind of fork is a kind of hardware fork, and that's when there's a difference of opinion, either in what the project scope is, you really want to expand it and do some different things, or licensing sometimes that can separate people. Interpersonal disagreement people that just can't get along and shouldn't be working together because they're hurting each other. It's actually, you know, some of these are good reasons to fork and don't worry too much about the presence of forks. I will say that reintegrating forks can unify the users and development effort. And this is to reduce user pain users can switch between different implementations sometimes, and that's fine too. We'll say that most forks will just die of neglect. But it's worth understanding their motivations. You know that these really do address pain points for users. But in the long run, whichever whichever the forks has more developers and maintainers will essentially live longer. There's just, it's just too hard. It's too much work to sustain things yourself. All right, part three thinking like a technical lead. This is probably the most familiar role to many of you. This is advocating for the technology. So the first thing you're doing when you're advocating technology is trying to protect the existing code. This tends to be more important than you could discuss a moment. Second, think about the project evolution over the long term. And long term could be one year, maybe maybe 10 years that we'll talk about later. Technically can make proactive technical investments in the project. And these are bigger than a single issue. And these might be using new tooling or rather than set increased the quality or make the project easier to maintain. And lastly, as a lead, you need to lead people need to communicate with your contributors and tell them what you're thinking, and maybe ask them about their thinking, try to understand what's going on with them. Okay, again, existing code is more important than new code. The cost of regression is actually much higher than you think things. It's not just fixing the initial problem, but this kind of echoes through time with with duplicate issues of people using old code. Or other other kinds of interactions in the ecosystem where people start depending on broken behavior or something like that. And so the most important way, more impactful way to to prevent this is to write writes and tests and use continuous integration. People always tell you that it's always true. There's just kind of a limit to what you can do in a volunteer project. But if I had to pick between unit tests or integration tests, I would probably pick integration tests. While a unit test has a high accuracy of telling you, you know, exactly where a problem is, it's low coverage, right, versus an integration test, maybe it does 100 different things, and one of them fails and you don't know which one, you can you can still gate a PR on that one failure and say hey, you figure it out and by the way, can you write me a unit test that for instance in the future. So code review is a great process. It really does increase quality of the project. It's also important to share kind of tribal knowledge about how how to work with the project. So this is really labor intensive open source projects we have a lot of new contributors or drive by contributors. And so you want to be, you want to kind of give the right amount of feedback there and don't don't overdo it. You want to automate things with with either linting or other static analysis tools that that can be good tends to be a false positive rain on some of those, you know, be careful about your time there as well. So one kind of trick for protecting code is that you want to take these giant 2009 PR is that users contribute and try to try to break those up. So once a big change goes in, it's usually pretty hard to figure out where exactly the problem was if indeed something is is progressing. So try to try to encourage people to write smaller PRs, maybe and spread them over a longer period of time where you might be able to either do a get rebase to get bisect to figure out where we're a regression stuck in, or when releases go out, there's gradually making these changes and you're gradually new test coverage. And the existing code you, you want to evaluate the proposed change say how does this interact with the current feature set, and maybe the future future set that we envision for the project, and maybe a simple example there would be a couple of examples for adding more knobs, and maybe you have like some cash size or something like that, and there's a knob for that. And the users will work around their, their whatever local issues they're having with another flag and the cognitive flags is pretty high. How do they interact with each other, do they interact with each other well. And so if, if you think like hey we're going to change how this works in the future, and we're going to have a smarter cash policy or something and this flag is not necessary. Maybe you say no to that feature and that user carries that flag in their local, local repository until you can have a proper fix and they learn. And if I would have technical risk, you really want to critically evaluate proposed changes, like, does it actually improve the user experience, or is it just something fun. You know, there's taking on maybe MongoDB or something I've had seemed really cool 10 years ago. And maybe you say we'll have infinite scale or something like that, but it's, maybe it was true maybe it wasn't. So there's different kinds of databases, maybe you would use and some of them are actually easier for free so they don't need that kind of scale and maybe nobody needed that scale to do this. So there's a proposed change limit your contributors. Let's say you're a Java based project and someone wants to write some closure, which is a Java based common list. And this was well received at the time and then that user disappeared and no one on the team new closure and so it kind of limited our ability to modify that piece of the software. And so, you know, be careful with the things you're taking on. We can really limit your contributors who don't know all these tools. And then look at whether increases or decreases the maintenance burden. It decreases it. That's a good sign, right if it adds a test that that is that more code but it kind of increases your confidence in the software and reduces the regressions. If it kind of removes functionality that it's not really being used that that's good for you as well. If people are adding new things that have kind of expensive cost to you. You can say no, or maybe you need to change that to be something that's more compatible with how you're looking at the software. And there's a great talk a couple years ago called choosing boring technology and thinking about the innovation tokens and these are finite and number maybe have free musk coins, Elon Musk coins, and you want to spend them wisely and maybe not spend them at all, or spend one or two of them. Like, if you're starting a new project where we're taking on something new, like, you're, if you're spending one of these tokens, what will that dependency or feature you're taking on with that. Essentially will that be over the long term, or will it create more problems for you over time. And so the, these are the talk with shoes boring things. If you don't have, unless the situation warrants it, and so that's, it's kind of just being safe. And the reason for this is if you take all the risks. One of them will get will burn you pick all the shiny objects. And some projects start with that way. You just get weighed down by one of one of those unlucky choices. So thinking about the project evolution. If you're taking on a new library will that new library have maintainers next year, where you have to start maintaining that library yourself as well. It tends to be like older projects tend to have a bigger community and live longer, and so they have a advantage that you maybe trust them to be around in the future as well. Okay, technical debt. This is a lot of meetings, a lot of people that I would say that any issue that increases your development friction, this technical debt. There are testing tests, flaky tests, or slow tests. The number of hours are potentially day or that I've wasted on tests that had unnecessary sleeps and, you know, or the test took two minutes instead of one minute. So this is just worth fixing. And of course flaky tests, the things are randomly failing. It's not good because you spend time diagnosing that flaky failure. And I would even say just just disable that test is not complete. Remove it or disable it until someone can fix it. This thing tests are tough. You know if you don't have test coverage you essentially in the dark for regressions. Those are usually harder to backfill. A lot of work to backfill. Other kinds of technical debt include outdated dependencies. This, this can be, this can be buggy, maybe security holes or things like that, and upgrading tends to at least give users confidence, your engines are confidence that this project takes these issues seriously. Obviously, unnecessary dependencies are possible to where maybe the standard library of your language takes on certain feature that previously was your part of library for. It's good to kind of react those. Those can even be good first bugs for potential contributors. Hey, can you help me with this kind of thing. And generally you, if you can you want to move from entry custom implementations to shared third party libraries. So this is to decrease your burden. You want to push those things out or use common code. This is easier to reason about for new contributors. Let's work for you. And similarly, I look at can you push features out of your project into other projects. This could be the custom implementations or could be even little libraries. So I long story, but I had written a HD to be clone HD been clone in Java. And it was one of the testing things I had written. And it was just better to push that out in its own project that has a couple of contributors now it's more useful to more people. And I would recommend that you try to pay down some of your existing debt before you take on new debts. And if you move the technical debt you have to the credit card and if you hit the limit, you're usually in a bad situation because you can't keep borrowing against the credit card. So try to pay down some of that debt before you take on the ones. Here's kind of a negative case study again from a three of us. This, this implements a S3 client via lip curl. This is this is for a good reasons this was done back in 2007 for C++ third party libraries existed. And I think this has been a source of bugs, you know all sorts of things with URL encoding and all the silly things. And we fix this gradually over time. But there's other features that are more difficult. Mostly advanced authentication mechanisms. And these are missing in S3 of us that are present in most other S3 applications. And it's frustrating users they don't understand why we wrote it this way. And so we can actually fix this. We transitioned to the AWS SDK would address this debt. It comes with some trade offs. Or as a new new reciprocals compiler and we could probably do that easily. We've heard some of our legacy users, but I'm personally factoring that it's not a lot of fun. Not a lot of times but always always defer it. It's always something more important to do. And unfortunately the maintainers, me and the other maintainer, we keep paying the short term costs fixing these little bugs, instead of addressing the long term issue. It's always, I'll do it tomorrow. And we said yesterday. So technical leaders need to get me the habit of thinking out loud, and maybe over communicating. And that makes some kinds of collaboration more difficult.  And so you want to foster a sense of community with your contributors and users. And this is more than just sharing your code, you want to share your ideas. And so you can do this and get have issues. And some older projects have mailing lists. Those are good too, especially threaded discussions. Twitter Twitter's okay, but you essentially want to say it like hey you know this this is what I'm thinking about this feature. What do you think. Right. And maybe you can improve your design that way, or maybe it's just a heads up to people like this is, this is coming, you know, do you have any, any objections to this and maybe in front load. Some of this before. And would buy us towards over communicating. Just just tell people you think you know I just like to be loud, being loud is my favorite. You can share work in progress commits. There's some people that are shy about contributing but if you show them like hey this is my process, you know, and here's here's something incomplete when I'm iterate iterating on maybe they'll feel more comfortable with the project. And again, you're trying to keep people really heads up about things that might be happening in the project. You want to talk to me or design somewhere other than code non developers rarely read code comments. I just put, just like, you know, sometimes a paragraphs enough, just put it in the, in an issue, or commit messages is okay PR wikis or, you know, markdown files in the main repo, often times better. It's just more accessible to users than trying to figure out, you know, connect these this function to this function the code and say like is this what did you mean here. It's just an explanation of like how maybe how a cache works or you know how how errors are handled or never cares or something like that that can actually be really valuable to your users. Okay, thinking about sustainability. That's part of the talk. So I've described to you more work essentially, which some of you may be scratching your head like how will this sustain my project. What you're going to need to make is you need to write less code to do these other things. And that's kind of not not really what I want to be doing, but I want to make these projects successful and so I do them.  So just thinking about like, if I have n work I'm going to do over two years, maybe instead I will do, you know, sort of in half and half work every year I'll do and over 10 work or something so I can do things for five years instead of two years. And that's, and that's just thinking about stretching yourself out over time these projects have a lot of value with age, the more people adopt them, and you want to make sure there's consistent in the kingdom. Sometimes it's better if the original author just step aside and let others maintain the project, just because you created something or contributed to it once isn't like a lifetime guarantee. And if you can find someone that's better to take over the project or collaborate with, please promote them to from contributor to maintainer. Yes, that's good for you and good for the ecosystem for everyone. And I've been in projects with the original author step aside, and that was fine. They moved on to new projects and created new great things. And, you know, no, no hard feelings there. So, I think that it's, you want to think about the long term as a maintainer. It's, I think it's entirely reasonable to think about where do you want the product to be project to be next year, you know, that they kind of allow you to make some more meaningful investments and maybe tooling or testing or, or something that, you know, I'm going to be around a year. I want this project to be better for me and better for our users. I want this project to get there because that's probably not just fixing a couple issues. I might be, you know, thinking about some kind of speed or compatibility or data, data integrity or something like that. And I think it's reasonable to think about the project. It might exist in 10 years. Maybe you're not making a year by year plan. But, you know, is there some, is there somewhere you're going as a project. Sometimes it's useful to have a big idea, right, like J Cloud's idea is to create the widest across cloud abstraction that it can. And that's a kind of a good goal. But how are you going to, how are you going to get there you need to keep opening the aperture of this compatibility over time with more providers and more API is this kind of thing so think about how you're going to get there. So ask yourself a couple questions. What, what kinds of changes are truly impactful for your users, because it's really easy to just be reactive. You fix random issues. So here's, here's an issue, there's an issue, boom, no progress. And that's the reason that's not good is because there's a lot of users that kind of advocate for things and change the story, like how with things you think are important. So you really want to put your product manager hat on and think about what is most important. And are there any broad themes you progress on performance, probably these kinds of things. And so your project may outlast your interest in it, and can you prepare for the next maintainer, and sometimes that doesn't mean like hey you over there you you need to maintain this now all that that's really great when that happens. So keeping the project in a state of good repair is a good idea. I've seen a couple projects where the maintainer quit kind of rage burnout and that was tough for the project to move forward. And so you really kind of want to reduce your involvement over time for planning to move instead of just up in my way. Think about your, your commitment to the project, how much time you really want to spend on this project per month on this project. And I think that there's this kind of three buckets you put this into one hour, I think you can effectively maintain some project with one hour a month, you know, just reviewing PRs and periodically, periodically cutting releases, that's that's fine. So if the first month is a little more interesting, you can actually kind of invest in the project, and not just be reactive, and maybe you work on, write some code. It's usually fun. There are projects that you can put 100 hours in a month and two. I've started some projects for the first month was pretty intense and that was great. Certainly couldn't sustain that without corporate sponsorship. It's not your day job, where do you get that kind of time from. So when you, when you think about your time commitment, think about setting a budget, like I am going to spend an hour on this project every month. You know, maybe you don't review all the PRs you don't respond all the issues when you just pick the things you think are important, and then you stop. And that's okay. Because otherwise you kind of tend to just go in random directions and oh this looks interesting now you know maybe I'll spend five hours in this.  And maybe it's okay that happens but when you think about maintainership I really think that if I'm going to do one hour of maintainership then I need to do that one hour. Also think about the quality of service you want to provide a lot of developers work in interrupt driven manners and they kind of context switch between things and that's expensive. And a lot of the work we do require concentration. And so it might be better to batch process things and so you know I'm going to look at these issues once a month once every three months maybe some projects and work through them and to keep all that context in my head. This can also be good batch processing because users can kind of figure out things on their own sometimes and maybe you didn't need to be involved and react immediately. And reminder that not everything needs to be done today. You know there's always tomorrow. And maybe maybe something never need to be done. There's certain kinds of features that kind of come in into a fad and then go away. Cloud providers and all sorts of things and you know maybe they, you don't need to do this and you can always say not yet. So wrapping up here, kind of hit the main points again, you want to prioritize the issues are important to your users. You want to enable contributors and outsource as many tasks from you on to the community that you can make technology decisions that allow you to evolve the project over the long term. It's okay to say no or not yet say it early and often it's okay you will not hurt people's feelings and think about the long term. So this project will be a lot of projects are still used a year or 10 years after the creation and they are valuable that the small ones that becomes an everywhere between. Thank you for your time. Thank you for the slides at call that works on Fox, and I believe there's a chat Q&A following this. Thanks again.


Why these unfortunate civilian killings have taken place? It is itself a warning for those who claim that we have done for ensuring normalcy in Jumu and Kashmir. This goes contrary to the claims. And that's why these are the concerns from all of us that normalcy cannot be restored just by denying the people of Jumu and Kashmir their legitimate rights by creating a political void. Three years ago on August 5th, 2019, the Indian government revoked the special status that had been granted to the former state of Jumu and Kashmir. The far-right BJP government scrapped articles 370 and 35A of the Indian constitution which had granted autonomy to the state on various matters of governance. These articles of the constitution were fundamental to Kashmir's integration with the Union of India after the country won independence from colonial rule. Along with the revocation of constitutional autonomy, the BJP government split the state into two federally governed territories. In order to suppress outrage over this move, the government imposed a total communications blackout and severe restrictions on freedom of movement and peaceful assembly. Hundreds of people were detained arbitrarily including political leaders and human rights defenders. Now, on 5th of August 2019, you know, our historic state got divided through reorganization act. It got downgraded. For the first time in the Indian federal system, any state is getting downgraded to a Union territory status. And any state, new states have been created in UP, Andhra Pradesh, Bihar, but after long discussion, seeking the approval of the common people, debating, listening to the common views, listening to the concerns of different shades of opinion, but how the reorganization act, how dismembering unilaterally the historic state of Jumbo, Kashmir and Ladakh, how a historic state got downgraded to a level of virtually a municipality by imposing, not only restrictions, imposing assault on the very moments of the common people. Have you ever heard that telephone lines were cut off? And there was no communication of a patient with a doctor. There was no communication of the people of Kashmir with outside. And even the mother was crying for his son studying outside or doing some work outside Jumbo and Kashmir. No contact.  The Narendra Modi led BJP government did all this stating that this move is meant to improve governance and the lives of the people in Kashmir. However, three years later, the people of the region do not even have an elected government. Due to heavy clampdown on any kind of dissent, trade unions, rights bodies and civil society groups are no longer able to function properly. Right after the restrictions that were imposed in August of 2019 were relaxed, the pandemic began, bringing with it more lockdowns. All of this severely impacted people's lives and livelihoods. Unemployment remains high in the region. The BJP government had promised to fill 50,000 vacancies in different government departments after article 370 was revoked. This promise is also yet to be fulfilled. You see, we have been talking about as far as Kashmir is concerned, Jumbo-Kashmir is concerned. It's a very difficult field. We are going through. Our people are virtually, virtually feeling like demoralized and hopelessness is prevailing. You see, the first thing is that the claims of the government, the claims of the government initiating a process, real genuine democracy underground by assaulting the very basic rights of the people, the constitutional rights and through clampdown, through crackdown, not only restricting the movement of all those who are having dissenting voices, but putting them under detention, under public safety act, UAPA, etc. Can you imagine, by denying the very basic rights to the common people, democracy can be restored? The BJP government had promised better governance. However, the focus even now is much more on security. Kashmir was already among the most militarized regions in the world. Since 2019, the number of security forces deployed in the region has increased even more. These armed forces have been implicated in numerous cases of abuses, including routine harassment and ill treatment at checkpoints, arbitrary detention and extrajudicial killings. The government is also continuing to abuse security laws such as the Public Safety Act to conduct raids and arbitrarily detain journalists, political leaders and activists without evidence or compliance with judicial norms. At the same time, sectarian sentiments continue to prevail in parts of Kashmir. There has been a sharp and worrying increase in the targeted killings of civilians. All of this has created an environment of fear and insecurity in the region. A lot of this reality has been suppressed by the BJP government at the centre, which has established a firm grip on media in the region, much like it is able to control the narrative in the national media. Journalists in Kashmir have been facing increased harassment by armed forces, including raids and arbitrary arrests on false terrorism charges. According to Human Rights Watch, since August 2019, at least 35 journalists in Kashmir have faced police interrogation, raids, threats, physical assault, restrictions on freedom of movement or fabricated criminal cases for their reporting. You see, this is the situation which unfortunately people of the rest of the country are not knowing and the news has become selective. Whatever suits the regime itself, yes, there are certain attempts, there are very credible journalists in our country, but unfortunately they are being harassed by different powers. That is how we do believe that this disrupting the channels of communication with the people of the country, with the people of Kashmir, that will have adverse impact in future, that will definitely not, it will not serve the purpose of the unity of the country as a whole. Now the people are seen through all the propaganda which the government of India has been conducting or spreading across the country. Jammu, Kashmir, Ladakh is in a very bad shape. We the people, Jammu, Kashmir and Ladakh, want to just express our concern, restore statehood back, give us the chance to elect our representatives so that a legitimate assembly elected through a legitimate electoral political process. Why are you creating delay? Why don't you allow us to have a government of our choice so that we can discuss the issues and we can sort out our differences, we can sort out and talk out some positive intervention for the betterment of our people in all the regions, in all the communities.