Nuevos modelos de equidad laboral entre mujeres y hombres

Managing divergent interests was a governance practice that emerged due to the inclusion of diverse international universities ranging from small community schools to major research universities. As shown in figure 12, this required universities to adjust their local work flow processes to meet the needs of Kuali. Besides, the existence of diverse universities has raised the risk of the community being dominated by the requirements of leading universities. In other words, it has raised a tension between the university- specific needs and the community needs.

Figure 12: Data Structure: Phase2-Managing Divergent Interests

Kuali community include universities that are entrenched in their work practices (Tech1). Universities have divergent interests, and thus the community experienced resistance to adjusting university-related work

132

practices to meet the standard working practices of Kuali projects. One of the major resistance was with regards to the process of purchasing OSS in American universities, as explained by S5:

“…one of the things we're working on this year [2014] is working with our procurement or our purchasing agents. We’re helping them

understand how to buy free software, and this has been a long journey”

Universities are used to purchase software through a tender; however Kuali Foundation is not a company. This complicates the process of joining Kuali community. Managing divergent interests is a governance practice that looks at such complexities and adjusts the work practices from both perspectives. The following is an excerpt from meeting2, where the Board members were discussing solutions for the tedious workflow process of purchasing an OSS product:

“[A member] shared that the [a company] is interested in providing an overall marketing and outreach program for a variety of open source higher ed projects, including Jasig, Sakai, Durapace, and Kuali. This project is a start, to show value and to create a deliverable that is useful. This project will help in analysing the procurement process and how we can make open source software acquisition more viable in the process”

In addition, the diverse universities of Kuali community have emergent university-specific requirements. These requirements were mainly implemented through two different ways. First, the university performs the implementation internally using their local resources. Then, the university proposes to contribute this newly added feature to the base-code (i.e. common pool) by going through an agreed-upon approval process. Second, if the university lacks the resources to implement the feature locally, it requests the corresponding Project Board to discuss the possibility of implementing the feature using the pooled resources of the project. In this

133

case, this specific feature will not be implemented unless it is aligned with the common community needs. This has caused a tension between the community requirements and the university-specific requirements, especially that universities are looking at things from their own perspective. They view Kuali:

“1) as an ERP vendor that provides systems they can install, or 2) as a community that they can engage with that provides a strategic way to move their administrative systems to a new, higher quality, and more cost-effective approach” (Meeting28)

However, at that time, Kuali community was not a vendor. It was a community-source:

“…it [i.e. Kuali] isn't a zero-sum game. This is a game in which winning is possible across the board. But it may mean that no one school gets exactly what they want all the time” (Admin4)

Project Boards accommodated this tension by inviting diverse universities to be partners in Kuali in order to ensure the coverage of wide range of requirements. With regards to KFS and KC, the system requirements were clear, and thus the focus was on attracting variety of institutions:

“For instance, financial systems have 12 partners, all the way from very small schools including community colleges, up to major research universities. Kuali Coeus, the research, has, I think, 18 partners now, again very diverse from small and large” (Admin1) “…we tried to make sure we had a mix of all of the different things” (BA1)

However, with regards to KS, the requirements were complex. Thus, diversity was not sufficient. The KS community was targeting universities that have complex business requirements in order to share their experiences:

134

“We wanted to have rules for complex relationships… We wanted to identify complex business requirements we saw common across many different large universities. We wanted to bring that, those features, out of the box” (Tech6)

The tension between university and community needs was also reconciled through restricting the process of code contributions. This was achieved by either parameterising or prioritising contributions, which highlights the materiality of technology. Parameterising features takes into consideration that the newly added features may be relevant for certain universities, but irrelevant for others. In addition, the relevance of the feature may change over time:

“When I understood it was something that was very specific to [my university], I made sure there were feature flags, parameters, you

can turn this feature off or on. I did the extra work in the software

to accommodate that” (Admin3)

“if these things are going to be sharable in the future, I will keep that in mind when I write the functional spec. For instance, Hawaii might use this, Cornell might use this, so even though California only needs this, I parameterise it” (BA2)

In terms of prioritisation, some contributions were given higher priority due to their higher impact on the community. For example, Admin7 describes prioritising features in KC project as follows:

“But I think a lot of us feel like the proposal development module being something that a lot of people can use is a greater good issue. It also helps us to get new users, new partners to the community, whereas a small module who is only used by central administrators at a university may not be the thing that gets us new partners“(Admin7)

135

It is evident that parameterising and prioritising the code contributions is a way to arrange the material features of the OSS code with relation to the context. Managing divergent interests shows that the OSS code in not only an end product. Instead the code is co-developed and in a continuous state of change. The material features of the code are rearranged to enable the accomplishment of the governance practice. Further illustrations are provided in section 5.3.3.

The community also reconciled the tension by allowing the emergence of roles. Same individuals were sometimes assigned different roles causing different interactions, and thus different consequences. For example, some Board members toggle between two roles: a university representative, and a community representative. During the Board meetings, these roles emerge as a significant agent that determines the direction of the project (i.e. whether to accept the proposed features or not):

“So I sort of carry two hats though. I need to carry my hat of ‘this is what [my university] needs’, and then I have to have a hat that says ‘this is what is good for the community’. My boss understands that sometimes I am conflicted in those two roles” (Admin3)

“…when you are an institutional member and you are voting on the road map items, you are paying in your funds to be a paying member, and you are definitely thinking about ‘well what am I getting from this money?’ or ‘what I need might be different from what my companion school who is sitting next to me might need’… So, we have to balance ‘what do I really need’ versus ‘what has to get the community going’" (Admin7)

In OSS communities in general, tensions cannot be totally eliminated. The fluid and dynamic nature of the community promotes the development of diverse requirements and interests. Therefore, managing divergent interests is a governance practice that realises the importance of fluidity; i.e. existence of divergent interests to enrich the community.

136