Towards sharing developer XR materials

Summary

Below is a bullet-wise summary of the things discussed in the sharing brainstorm.

Reasons for sharing

• Avoiding “reinventing the wheel” by providing re-use of applications, frameworks, or pieces of code;
• By reusing and/or learning from how others tackled issues you can realize similar solutions faster than building from scratch. It provides insight into ways in which a project or problem were (technically) approached, including detailed development steps taken;
• When sharing, some form of return is appreciated, such as access to other shared materials from peers. This also provides a benefit of access to a larger variety of applications than you are usually working on yourself;
• Sharing publicly provides a way to gain visibility and recognition of your work on XR

What is asked back

• Share using a Creative Commons license, so any reuse stays open-source;
• A connection from any developer (re)using shared materials back to the party that shared the materials

Types of materials to share

Source code (possibly in the form of libraries, plugins or blueprints)
 

• The majority of XR projects are realized using either the Unity or Unreal game engine, but other frameworks are also used. Hence, shared code and plugins for those two engines can potentially be widely reused.

Applications and demos
 

• These can be complete education or research applications, but also interesting tech demos showcasing particular technical features of software and/or hardware
• Depending on the project and use case what is shared might be a standalone app, but could also require other apps or services that were developed by others (for example, a back-end service for storing experimental data)

PoCs, failed experiments, incomplete results
 

• These results might still be interesting for others, even though not directly usable.
• Availability of partial results can motivate others to use these kinds of results, and to do the same. It might even help in finding new funding to continue work, etc.
• Self-hosting such materials isn’t feasible for an institute in many cases, it takes too much effort and cost involved. 
• Included here is also the state of a project when funding stopped

Knowledge
 

• Best practices, for example on certain development aspects
• Lessons learned from realizing projects
• Design patterns
• Showcases/portfolio
• Processes and methods, for example, how to embed a new project or application in an organization
• Certain information can be provided in templated form, for example, processes, planning  & budget, legal/IP challenges

Assets
 

• There are a number of asset stores online that commercially provide 3D models, textures/images and other content, usually for a reasonably low price (10s-100s of euros, depending on complexity and quality). The cost for these assets is low enough that purchasing is a cost-effective option compared to creating the same assets from scratch yourself. Lots of XR projects therefore use these commercial assets. However, purchased assets usually cannot be shared to other parties, as their license does not allow it.
• For very specific cases asset stores do not always have the necessary content. For example something specific to the Netherlands, or a 3D model of a particular piece of equipment in an operating room. In these cases creating those assets yourself might still be needed. This can take many man-hours and thus is more expensive. But these custom assets then do become valuable within the community, if shared.

Hurdles

• Time is a major issue when it comes to sharing. In most cases this time needs to be spent to prepare source code or applications for sharing, for example to clean up, comment and document, or to gather all necessary materials in shareable form. This includes making sure that a shared project is complete, and so is usable by a third party. In lots of cases such time is not available, or only in very limited amounts. This then, unfortunately, causes materials not to get shared at all.
• Providing support on shared materials is also dependent on having time available. Here, there is usually a difference in supporting development materials versus supporting applications. The former is more developer-focused, the latter more focused on the end-user and/or IT supporters.
• Use of purchased assets and plugins, as mentioned above, makes it much harder to share a complete project, as those purchased materials can usually not legally be shared (the license of the asset/plugin doesn’t allow it). This means leaving out those purchased parts from projects being shared is usually the only way around this issue, forcing anyone wanting to reuse that project to either purchase the same materials themselves, or to find or create (free) alternatives.
• Some control over who gets access to shared materials is wanted. The two opposites of providing materials fully open-source without restrictions (even allowing commercial reuse), versus not sharing at all, are both judged too extreme, and some middle ground is needed. This is less about the control itself, more about providing a trusted environment in which the parties sharing know in what way and with whom they are sharing (“share amongst friends”). This trust, in turn, then might cause more parties to start sharing, providing a further positive effect. Some access control is still desirable, for example, to only give specific groups or domains access.
• Another aspect of having a sharing environment or platform is that it centralizes available materials and makes them searchable and discoverable, specifically focused on the education and research domain. Current source code sharing platforms, such as github, lack such easy discoverability, especially when focusing on education and research. Having such a platform also saves effort as institutes don’t have to go through the trouble of self-hosting, which usually involves storing XR projects with large assest (100s MBs - 10s GBs) and complete source code repositories including their development histories.
• Legal and IP issues in some cases can be major hurdles, for example, when an audit is needed to judge if materials may be shared outside the organization as is, or extra legal/IP protections are needed. There is also a difference in sharing internally within an institute, versus outside, with fewer hurdles internally. For certain (externally funded) projects, materials that are developed within that project are sometimes only available to project partners and cannot be shared outside of the project.
• A lack of standards in sharing code and projects, together with different approaches to design and implementation, can make it harder to reuse shared materials. Some institutes do use certain standards, but most do not. However, even without a standard shared materials can still be of great value for reuse and learning from, compared to not sharing at all.
• There are choices that can be made as to which shareable unit (or type of modularity) is most sensible. For example, if a project has been set up as a set of libraries or plugins, then those can be reused more easily. But this requires conscious effort before and during project development to accomplish and will be more appropriate for larger projects. 
• Differences between institutes, in terms of funding and IP issues, can stand in the way of sharing. Although this seems more of a hurdle to reach a general solution for all, than to start with a small set of institutes to share amongst themselves.

Next steps

We're focusing on a small set of next steps for the coming time:
 

• On the short term we want to make an inventory of currently available materials, including terms on which these materials are available. This is a form of low-hanging fruit, as it shouldn't require too much effort, while providing valuable insights into the current state is of available materials, and from whom.
• Working towards sharing amongst friends is something that will take a bit more time. Some conditions have already been identified (e.g. the wish for a platform that allows control over access), but some more concreteness is needed. If such a (possibly new) platform is indeed the way forward then this will take more time.
• Scouting the road to co-development is a long-term activity, as it requires a lot more coordination and effort, as indicated above.

We will be working together with the NPuls Pilothub XR on these steps, to make sure we align our goals and available resources.

As mentioned above the next Developer Network meeting on the topic of sharing XR materials is scheduled for 11 October at SURF Utrecht. See this event page for information on this meeting, including how to register.