Hello, everyone, and thank you for having me here today. I would like to present my, most recent work, which is titled, do we run? How we say we run? And it deals with the formalization and practice of governance in foundation supported OSIS communities. So I'll briefly describe as to why governance is significant in open source. So most of the open source communities are characterized by, independent communities often volunteer driven, and they have dynamic trends of contribution and are also characterized by fluid changing membership, changes in resources, availability of resources. And governance is a very useful mechanism which serves to streamline and coordinate all these various aspects, which are which are important in ensuring the survival and functioning of these communities. And today, open source is a very is an invaluable asset. It's valued at several billion dollars and is integral to tech, academia, as well as research. But at the same time, independent projects do face considerable practical challenges. And recently, over the past few decades, there has been a trend of nonprofits which have banded together several, independent communities. And they do they kind of serve to provide systematic governance mechanisms as well as, tangible and intangible resources. Governance is in the form of community regulation and practices as well as other pertinent aspects such as licensing and legal representation and also mentorship and systematic community policies. And one of the major questions that, my paper, looks at are how this foundation policies actually relate to how communities operate, how they behave in what the observed behavior is and what their actual objective performance is in an incubator program. So one of the ways which we look at the impact of formal governance against observed tactical behavior is by understanding that governance in these communities comes from multiple multiple seats of, of administration. So we do know that an incubator has certain policies which the communities are expected to respect and follow and which we can also expect can help, projects realize certain goals and coordinate themselves. But at the same time, projects have their own prerogatives. They are not developing the same sort of applications. They do not have the same resources. They have different needs in terms of the developers they're looking for, etcetera, etcetera. So they also have their own norms, practical norms as to I mean, an example could be who incorporates patches, who reviews patches, how often patches need to be reviewed, like, very basic operational ground level norms such as that. And these norms are actually important to communities because they they do ensure how they cater their own objectives, their own specific requirements, and also adapt to the change in use of the market. So at the end of the day, how projects perform is not just a reflection or a function of the foundation policies, but also how they institute their own beliefs and operational norms into how they conduct their businesses.

so how exactly do we understand or measure an an observation of governance and also compare it with respect to what the what the formal foundation policies are? So we look at routines. So routines have been used in organization theory as a means for understanding how skilled communities behave and routines are basically what to say they are. They are repeated patterns of behavior, which come out of an implicit or formal rule, which someone is someone or a community believes in, and they conduct from time to time. And therefore, these repeated patterns of behavior or routines, they are an expression of all implicit beliefs and norms as well as the foundation policies that the community subscribes to. And routines are very significant in terms of how they indicate that a community is trying to structure its activities, if it, believes that a committee should be elected in a certain way and does it over and over again, we can say that it has been established as a belief or or a norm in the community. But at the same time, we're also interested that among all these concurrent beliefs and behaviors in a community, how many of them actually reflect or bear any semblance to the foundation policies? So we look at two major major like, two important measurements as to how often repeated behaviors are seen, behaviors which are an outcome of the beliefs and norms, all beliefs and norms of a community, and also to what extent they actually resemble the formal policies. So now I will introduce the three research questions this the current work investigates. Also, a brief overview of the particular case study. So we are currently looking at the Apache Software Foundation, which is one of the most well known foundations out there. It has been around for almost three almost two decades and has to date entered over 300 projects. And it it has a it it also operates in a curate fashion. The foundation kind of looks into important aspects such as licensing, mentoring, setting up committees, basic rules of voting, etcetera. Whereas the projects are free to conduct their own, nitty quities of development and project management. So the first research question looks at how, behavior or normative behavior of projects relates to the formal policymaking. So policymaking spans different topics, which are of importance to, to a foundation. And we basically look at mailing lists from projects, and we try to identify repeated behavior. The way we do it is we try to understand how different activities reported emails. They are similar to each other, and we club together similar repeated behaviors. And then we see how many of them are indeed related to governance topics, from the participatory foundation. And we also bin the policies themselves across different topics. And we see if the distribution is in some way related to each other. And the second research question looks at whether these enacted routines or government activities, how similar they are to the, foundation policies, among all concurrent behaviors, how how often do, do project members subscribe to policies or invoke policy elements in their functioning? So once they have been the activities, we kind of, look how similar they are to the policies we know, and we measure the similarity, the semantic similarity of behavior, observed behavior with respect to non policies. And we'll also again compare that that distribution with respect to policy distribution formal policy distribution across different topics and see if they're related in any meaningful way. Finally, the last research question looks at these two different aspects of governance, our performance of, the performance of all, underlying beliefs of community members and how they internalize formal policies and tries to understand as to whether they have any significant bearing or association with the graduation rates something graduation rates of the incubator. So I might have missed describing how the Apache incubator works. So the way Apache works is they admit new projects, and they kind of put them through an observation period of it's it's usually two years, but it can depend upon the project's specifics and their requirements. But they they're kind of put to this incubation period after which they undergo assessment. And throughout this incubation, they are mentored and they receive all sorts of support and resources on the foundation. But towards the end of the incubation, they undergo assessment. And if they have been found to meet certain basic criteria set by the Apache Foundation, they are graduated and retained for for the support. But in case they are not found to perform satisfactorily with respect to those conditions, then they are usually asked to leave the foundation. So we kind of use that as a binary, indicator of project success, and we try to understand if any, governance behavior is associated in sort in in in a in a certain way with how often projects graduate from the incubator. So our data comes from there are two major sources of our data. One is understanding what the formal policy representation of Apache is. And for that, we found 234 comprehensive policy descriptions from the Apache Software Foundation Incubator. And we also use your preexisting dataset of developer emails from several projects for our 214 projects which were previously collected. And we also control for the project size and specifications such as how many members they have, how often they, commit code, and how much code they have effectively written in, in terms of certain project covariates. So, I will briefly, describe how we did the data processing. So since a lot of this in, the data was unstructured, mostly emails and policy is getting, streamlined representations from these data sources required, several steps of preprocessing. So the first step involved tokenizing those longs, blocks of emails and policies into sentences. And then since we are interested in activities or observed behavior, we focus on the verbs in the text streams. And with respect to every verb, we get we extract information as to who performed the particular activity or who was involved, or what context the activity was performed in to basically get very precise representation a brand new representation as to what is happening inside these communities. The next step was essentially finding routine activities that is looking at taking all these activities, finding which are most similar to each other, and kind of identifying that emergent pattern of repeated behaviors and assigning them to relevant topics with respect to the Apache policies. This is a a brief overview of, the four major parts of the processing, pipeline. So like I described, we first tokenize and, extract information about activities followed by aggregation based on how similar activities are with respect to each other. And after this aggregation into clusters of activities, we assign these clusters topics based on the policies which you already know and have from the Apache Software Foundation. So we basically are taking observed normative behavior and assigning them under what categories the best fit under with respect to Apache's policy domains. And finally, we, measure policy internalization where we take activities from each of this cluster and measure them with respect to policies, under the same, governance topics. And we've we, we kinda treat the that's pairwise similarity as a measure of internalization. That is this activity is most related to a certain policy in this topic. And that gives us an understanding as to the semblance between what is done and what is supposed to be done. So I will next present the results for our three RQs. So in the first RQ, we that is frequency of routine behavior and distribution of policy across different governance domains. In this in this analysis, we did not find any significant association between how often policies are made and whether projects indeed dedicate a lot of structured government activities towards those topics. Interestingly, though, in the second research question, we do find, that how often policy is made in a particular governance topic predicts how much the policy is internalized on community members. And by internalization, we basically say basically try to mean that the way developers talk about the top about a particular policy topic in an email or how they report that this has been done. We need to do this. It's very much, in line with how policy describes those aspects, or those themes of governance. Finally, in the last research question, we we analyze if any governance behavior is significantly associated with project graduation. And we did find some effects from both governed activity and internalization. So we found that activity, routine activity with respect to patch management was indeed supporting our graduation, whereas projects which participated in a lot of activity with respect to to project reporting surprisingly had lower rates of graduation. Similarly, when it comes to internalization, there are certain aspects of project governance such as setting up configuration, rules regarding graduation and retirement, as well as conducting different types of voting mechanisms and rules regarding those voting mechanisms. These topics had had a positive effect when it came to when it came to internalization and graduation. However, when it came to management of ProjectWiki, policy neutralization seemed to have a negative effect with respect to graduation. So we conducted a post hoc conducted some post hoc experiments where we removed some of the topics and policies which were very associated with graduation and retirement and comprised of policies which are mostly observed towards the termination of the incubation period. So for example, wiki management and graduation graduation requirements and maturity model, they contain a lot of those policies. So So in the post hoc testing, we find the same results for our q one and our q two. But for our q three, we find significant effects for only three of the, three of the governance measures. That is for patches, incubator reporting, and voting protocols. So we report our findings based on both the main, analysis and the postdoc testing. So so in terms of the main takeaways of this work, so the r q one finds that the effect of governance is less on the frequency of normative behavior across different topics. But at the same time, policies do serve to kind of frame, the mental representations of, community members and how they understand and enact policy is more tends to resemble policy more along the lines of increased policy making. And similarly, in our q three, an interesting observation is that the effects do not come from topics which are very severely governed like, very heavily governed. So so if you might see, there's some of the major topics which are very heavily governed include management committees, licensing, emails, release management, etcetera. But most of the effects that we observe to be significant do not belong to this top top governance topics. Instead, they are relatively less or relatively less governed. And the only topic which so I'll I'll kind of discuss a bit about implications of these different topics. So voting timeline is integral to ensuring systematic consensus building to ensure systematic systematic consensus building among community members. Similarly, patch management. There aren't many formal rules about how patches should be incorporated or how patches should be submitted or reviewed, but it kind of comes down to the ingenuity of the community as to how you bring together your members to decide who does what and, you keep a project going. So that's that's pretty interesting as to how, how communities convene, systematic behavior in less governed, aspects, actually counts towards their source of success. In terms of incubator reporting, incubator reporting is is a mechanism to ensure compliance on projects and see whether they are performing as as expected or keeping up with the standards. So while it's, while, it's a useful mechanism and it often, is imposed when projects are not performing as per expectations, these these additional organizational requirements do tend to act add as a act as an act as a deterrent as in they may often shift investment in development, like contribute energy and development away towards more formal requirements. So that's that's a very interesting observation and probably requires, for the treatment. So, finally, we do, have reason to believe that communities are in are in their practic in the in the practical behavior, somewhat divergent from what their formal specifications are or what they convey. And foundations are, are likely to benefit from involving community members in policy making and in identifying aspects which need more intervention and assistance or guidelines. And in in in such possibility, it really helps legitimize foundations, governance, as well as ensure that policy making is being conducted in a manner that is beneficial and supportive of community interests. And thank you so much, and looking forward to questions.

So I'm a little confused because it's our first time doing a stack q and a. So here's the first question. Right?

Right. Right. Right.

Oh, I see. Right. In terms of ethics so so just to clarify, when you say so do you mean looking at ethics as a governance domain yourself? No.

Oh, yeah. I mean, sure. I can probably get a conversation going, but I can come back with my own views later.

I'm happy to say something if I may, which is simply it's going to be very short. People who know me know I this is this is a blue moon statement. I'm absolutely blown away. I think this is absolutely brilliant work that you're, moving into the world in which let me see if I can, this is new to me and I need to read a lot of it before I can be more articulate. But that my understanding of what you're doing here is that you've moved beyond, is that you're bringing the worlds of process together with the static descriptions that are formal of how the governance world should work. And my critique of what much of what has been going on in this domain of digital governance and this this world that, MediGov is drawing me deeper into. I was aware of the literature, but now I'm getting more familiar with it, but that it was flat on the text, what a lawyer would call black letter law. It was the equivalent of that, and that you are bridging it in a way that I think will have methodologically, you're gonna have a lot of followers. And I'm going to be reading a lot and following up with it, but I just wanted to congratulate you and tell you I'm blown away. Thank you.

Thanks so much.

The the ethics question?

Okay. Right. So I'll probably so, I mean so when we talk about ethics, the first thing that comes to my mind are, like, AI policy buzz buzzwords. But AI ethics has been like, OSS ethics has been there for a long time. Apache themselves have some written ethical guidelines as well as I'm pretty sure there are normative guidelines as well. One which I can, like, off the top of my head, think of is that you should provide credit to people in commit messages. And I think, like, that has major implication when it comes to collaborative work and ensuring people get to do. And they're also, like, probably I mean, this is I mean, I well, I wouldn't decisively say it's unethical issue. But observing, like, observing licenses and ensuring you're using the right licenses right license and respecting their terms. That also comes kind of along the, like, the like, the border of ethics and legalities in open source. So, yeah, I mean, I haven't explicitly looked at which of the policies were had ethical implications because what we define as an ethical practice is subjective and with I mean, it would, like, really benefit from more deliberation as to which norm is ethical and which is more like just accepted norm or just enforced policy. So I think that's very interesting to look into, and I think there's a lot of potential in that direction.

Mhmm.

I I think that's a very interesting thing that you brought up, and I I do not see a reason why PolicyKit would really, really benefit the sort of work I'm doing. So I think I mean, this is, like, probably very ambitious, but, I think we can probably or we are probably getting closer towards dynamic governance by force recognizing the fact that the governance which happens is very different. It changes over time, and it's very much subjective subject like, very much subject to current conditions and circumstances. So, I mean, I kind of have this slide open, and you can probably see that people are doing several things time and over again, none of which are registered as policies. But in some of the, like, probably in around 10 of the 200 projects, they have a rule. Say, someone must review patches every seven days or every commit is to be reviewed before it's accepted. And it's not it's probably I mean, what I'm kind of trying to say is if we can recognize policies as they're built, as they're designed, and if we can have a governance plug in which can recognize or register these policies and put them into effect. And I I think it would be remarkable if this could be done hand in hand. So I I think I think that's a really good direction that you kind of pointed me towards, and I appreciate that question. But, yeah, I I think there are possibilities out there.

I think at the very basic, what one would need is some measurement some reliable measurement of observed behavior. We had mail mailing archives. There might be discussion threads. There might be issue threads. Get that's probably something you might be able to get off GitHub. If you're thinking of other communities, web communities, there's Reddit probably. I'm I'm this might not be an like, a very conclusive set of examples, but anything that unbiasedly provides a representative, example of how communities behave or conduct their business, I think, that should be helpful. And, also, their extensive rules that well, these are the rules we all believe we absorb, and that should provide a reference as to understand that where the community kind of represents their governance. And I think that should be, like, at least a good enough place to start comparing that what's known about the governance structure and how we can understand what actually happens towards an attempt to further inform governance design or assessment.

Yeah. I I was wondering if you could, like, refresh the question. I'm I'm sorry. I kind of lost the last bit of it. I'm sorry.

Right. I think I think this is a really very a very interesting question. I mean, I think there should be an attempt to recognize that there will be differences, because for example, if you look at open source, the it it caters to a market. The market's requirements change changes and is changing fast. We didn't have I mean, since AI is a kind of recurring team, we didn't have AI the way it is ten years ago, and now the very definition of open source is under revision, and we are rethinking what open source means. So we have a system which is intricately linked and is linked to the market. So there will be changes in how people behave, what people need, what they're working on at a given time. So we can expect that rules on ground will be different from rules that are currently governing. So there will like, at any given point, if we compare whether there's a divergence between known policies and observed behavior, we'll probably always find some difference because there are new rules coming up all the time. Their rules has become redundant. I mean, there's probably there are rules about utilities. There are rules about I mean, most Apache products stopped using SVN about a decade ago, but there are still policies about SVN, which are which are probably only limited to few projects. But GitHub is more popular. So it's so fast changing. It's really hard to say that we can achieve that total alignment between, like, normative behavior and policies, but it's still important to recognize this difference and probably make policies in an in an attempt that recognizes that, well, this is something that needs to be a policy is about. This is something that this policy need to needs to be revised, and that can probably, help address to some extent. And maybe right right now, the difference is really stark. Maybe, participation and, intuitive policy design. Those can probably play play go a long way.

I'll be very brief. I put longer arguments in the chat. Just two things. One is to say that, the most among the discouraging legal arguments that are gaining play in The US right now is the argument that no government entity should be allowed to govern in an area in which it had not previously. So the US Supreme Court is looking at a question about one of the regulatory agencies that had been regulated in a certain area in the past, extremely dangerous. And so it it has to do with this if performance varies from policy, it's like an extreme version of that. And the other was just to make the comment that this really important question of the difference between black letter, the policy and the performance is that that covers a wide range of normal, like, adaptive ability, the social worker who really does understand you, and revolutionary radical change. And so what you think about that would or how one would deal with that for governance purposes would really vary with the kind of change and the kind of systems that are interacting. Speaking of my talk, what I was talking about, it would depend on where you were and all of that, what you would do with it.

Right. I really apologize, but could you, like, rephrase the question briefly? So

There's no question. I was just trying to succinctly restate orally points I made longer in text in the chat. Okay.

Yeah. I mean, one of the, aspects we are currently considering are basically generalizing as to what I mean, it's a it's, again, like, kind of a mammoth task, but understanding what or how governance manifests across different foundations and as to whether there's any commonality or thread as to what sort of behavior is supportive of sustenance. So that's kind of one of the directions you're looking at. And I think more more work along those lines can help us agree as to what sort of policies and when when we talk about large scale umbrella policy making, be it at the state level or like, we are looking at foundation level if we kind of scale to the state level. I think somewhat generalizable takeaways can go a long way. And, yeah, I'm kinda looking forward to that.