My Experiences in Establishing Open Governance and the UXL Foundation

In 2023 I was given the opportunity to start something that ended up becoming much bigger than I could have imagined. I was tasked by Joe Curley and Sanjiv Shah with finding a way to bring about adoption for an API specification and open source projects. In particular, the main objective was attracting more semiconductor companies to adopt the specification known as oneAPI, but more broadly, developer adoption. I worked closely with Alison Richards who had spent time establishing an existing developer community around what is known as oneAPI.

I’m writing this post to share my experiences and hope that perhaps some of it might be helpful to others trying to open up their code and specifications to the world.

I believe the world benefits most when open source and open specification projects are used as opposed to proprietary approaches. For example Linux democratised data centre computing where Windows once dominated, and OpenGL provided standard interfaces for graphics developers. The goal in this case was adopting open principles for High Performance Computing and Artificial Intelligence use cases, providing building blocks to accelerate these workloads in a vendor neutral way.

To achieve an open approach, organisations that compete with each other need to cooperate, and this is often a huge challenge. How do organisations retain their competitive advantage while making it really easy for developers to adopt their technology? I’ll talk about the journey I took with colleagues from across the industry that ended up with the formation of the UXL Foundation and subsequent growth. I’ll also talk about some of the work that was done to ensure collaboration was streamlined within the foundation in a further post.

The oneAPI specification was first defined by Intel engineers to lay out a set of standard interfaces for domains including math (such as linear algebra), neural networks (such as convolutions), distributed AI compute architectures and data processing, parallel ISO C++ and multi-threading. The intention was always to build something that could be used as the standard across the industry so that developers could enjoy writing a single codebase for multiple vendor processors.

One thing that helped us initially was that the specification and the open source implementations were already pretty mature and stable, making releases on a regular cadence. Intel had also established feedback channels from the community in the form of Technical Advisory Boards, however these were invite only limiting the participation. I initially expanded on this by forming the oneAPI Community Forum and opened these groups to anyone who wanted to join. This potentially brought a much larger audience, but the engagement was still fairly limited. We needed to do more.

We needed to talk to other semiconductor companies about adoption of oneAPI and find out how we can get them engaged. Fortunately my colleagues - Andrew Richards and Charles Macfarlane are well connected in the industry, and together we were able to establish connections with the right people from potential collaborators.

When we started these discussions, a pattern emerged quite quickly - oneAPI was not perceived as an industry initiative, and this brought about some major concerns.

• A single organisation was seen as the sole owner of the specification
• A single organisation was the GitHub owner for all the projects
• There were some perceived barriers for contributing to the projects

Ultimately it was felt that one organisation held too much control and this brought about too much risk when it came around to adoption. oneAPI was lacking robust open governance, a key ingredient for cross industry adoption.

So, while organisations were supportive of the idea of a standard API and oneAPI, in practice they did not feel like they could have a big enough voice or influence. The proposal was that we would establish a body that would provide open governance and equal rights for members that were part of it. By moving the control and ownership of the specification and open source projects to a neutral organisation everyone can have an equal voice and influence on the direction.

The proposal was met with enthusiasm by the organisations involved in our discussions, this was a great start. The next step however was not straightforward, we needed to form a committee, then agree on the governance structure and approach we would take and establish a completely new entity. This had to be done democratically to align with the open governance approach, and it was up to me to come up with a set of options, and to guide the group to consensus.

I established a committee to steer the group to the formation of a new foundation to host the oneAPI specification and open source projects. This included a cross section of organisations from the semiconductor, software and CSP industries. I also used a planning spreadsheet to track the various stages required to establish the new foundation as well as tracking actions, decisions taken and a risk register. This was a really good mechanism to show the group where were were and what we needed to do to. If you are interested in seeing what that looks like get in touch.

To avoid losing momentum it was important that we moved quickly to establish this new entity, the phrase “strike while the iron is hot” comes to mind. 

There are many options for establishing an open governance organisation, but I focused our discussions on three options that I felt were a good fit, in particular considering it was both a standards organisation and software foundation.

Option 1 - Establish a non-profit entity with new governance defined by the group

Option 2 - Set up a project under the Oasis Foundation with template governance provided by that organisation

Option 3 - Set up a project under the Joint Development Foundation (JDF) (part of Linux Foundation) with template governance provided by that organisation

There are pros and cons for all three of these options, and we discussed these at length during meetings with the formation committee.

Option 1 brings ultimate control and provides an entirely clean slate, but would require significant work and expertise to establish legal documents, and paperwork to set up the entity. It also requires individuals to take on legal roles associated with the organisation, annual accounting paperwork, and a significant overhead that comes with managing a non-profit company. There would be significant work required to set it up and on an ongoing basis.

Options 2 and 3 are similar in a lot of ways, offering established paperwork and processes to help establish a foundation quickly. They also have the support of existing organisations with the ability to scale activities and reach. The effort to set up with an existing template would be the path of least resistance, especially if the organisations joining the new foundation had already legally reviewed the paperwork.

The simplicity and strength of the JDF templates alongside the significant resources the Linux Foundation provides edged the group towards this option. It was also an advantage that some of the organisations involved had already reviewed the JDF and Linux Foundation legal agreements. In addition, the strength of the JDF and Linux Foundation software community is impressive with existing large events, marketing channels and infrastructure, increasing the potential to help us with our goal of industry adoption.

So, our chosen path for open governance was the Joint Development Foundation giving us a rapid way to establish this new entity. I give thanks to Michael Sirtori for his help in bringing ideas for how to establish the foundation, and navigating the legal hurdles when investigating the options. Jory Burson also tirelessly helped us to navigate the steps towards formation and launch and kept us on track.

Foundation Structure

An important part of a software foundation is structuring the various groups that are needed for collaboration, organising work, marketing activities, legal and probably other things depending on what you are trying to achieve.

The JDF template governance defines some aspects of how the foundation needs to be structured, for example it describes a Technical Steering Committee and Working Groups, but we still had to decide the overall structure for the foundation. 

This meant defining the Working Group purpose and practices and setting up Special Interest Groups (SIGs). The main difference between the Working Group and SIGs is that anyone can join the SIGs but to join the Working Group your organisation needs to have signed the member agreement. This lower barrier meant the SIGs had ultimate flexibility to bring discussions and presentations from the community in a more information setting, whilst the Working Groups could focus on organising specific work packages related to one or more projects as well as monitoring releases for example. We also established a marketing committee to organise and plan activities like events, collateral, announcements and other outbound communications.

Budgets

Another major decision centres around the overall funding for the foundation. Membership fees and structure is a blank box in the JDF template agreement, allowing projects to set their own, and this was something we had to define as a group. On reflection this part of the setup was more important than I realised, as it dictates what the foundation is capable of doing. This includes staffing (for example a Program Manager, Technical Lead, or Marketing) as well as things like infrastructure costs like CI, testing, packaging, web hosting and the list goes on. It’s important to think about current and future costs, ensure you have a good story for what the money will be spent on, and agree with the founding members on the funding approach. There is a balancing act to achieve, with the fees needing to cover costs, but you also need to ensure organisations will pay the fees and extract value from them. While I tried to figure out current and future costs, at this time we did not have the context for all the infrastructure and operational costs we might require in the future for open source projects. So the main advice I have is to try to predict what you will need operationally for the foundation and use this to set the level of funding from membership. It’s definitely easier to reduce the fees than to raise them.

What’s in a name?

One of the hardest parts of this whole process was figuring out what to call the foundation. I did anticipate this since every time I have been somewhere that has named or renamed a product it took a long time and was quite divisive. I have been in many discussions about how optimised a name is for search, or web addresses. We went through a shortlist of names, starting with the oneAPI Foundation (this was rejected on the basis that the group wanted a neutral name), Open Software for Accelerators Foundation (too wordy…), eventually ending up with Penporn Koanantakool 's suggestion of the Unified Acceleration Foundation (UXL). If I can give you a tip to streamline this I would but really the best course is to give this stage enough time, and keep trying to align all the stakeholders. Sometimes a vote pushes everyone to a smaller shortlist and then consensus becomes easier or fatigue sets in :-).

Decisions, decisions

One of the things I like about the JDF is that it encourages the committee to use consensus where possible. It is a good way to work as it avoids constant voting and the overhead that brings. It also makes sure that everyone feels they can voice their opinions towards a solution. Obviously consensus can sometimes cause things to get stuck, but that is when voting can be used to move things forward. It’s important to establish a decision making process that your members are happy with, and also enables the group to move at the right pace. Moving too quickly might not give everyone a chance to properly review something, but moving too slowly inhibits innovation and progress.

Launching the UXL Foundation

One of the reasons we chose the Linux Foundation to host our foundation was the reach the organisation has, and this was immediately justified when we came to announce the formation. The 2023 Open Source Summit event in Bilbao was used to announce the UXL Foundation and we were honoured to have a section in the keynote presentation as well as lots of press coverage and interviews to talk about the foundation and its goals. 

The one thing I would say is that it is really important to make the most of the launch announcement, you are unlikely to get more coverage than at this point, so make the most of it - ensure you provide the press with the information they need and make sure someone replies quickly to any emails requesting information. Having named contacts and a dedicated email address for press enquiries will help. We also put together a press pack of sorts with a presentation and other information about the foundation. (Look Mum, we made it into TechCrunch)

The next steps are also important, establishing the open governance and internal workings required to operate an open foundation. In my follow up post I'll talk about how I worked with many great individuals to establish the foundation operations, mechanisms to organise work and collaboration across organisations, and how we grew the membership of the foundation.

Thanks to everyone who helped to make things happen, in particular the members of the Steering Committee who ensured their organisations were engaged with the process from beginning to end.

If you’d like to talk to me more about my experiences, or ask any questions please get in touch!