Ten Simple Rules for Academic Open Source Collaborations with Industry

Jonah Duckles, Dan Sholler, Beth Duckles

March 26, 2025

This work is licensed Creative Commons Zero - Public Domain

Introduction

Open source software (OSS) is a critical component of modern science in both academic and industry settings. Much like other prominent digital technologies (e.g., operating systems, the Internet), transformative OSS languages, packages, and sub packages are often created and developed in academic settings before being deployed in industry firms. Yet despite industry’s reliance on OSS tools, academic scientists carry much of the burden of OSS development work for a number of reasons:

Academics are uniquely positioned to work on longer time scales, often unburdened by quarterly financial targets;
Funders increasingly support OSS with grants for graduate student, postdoc, and faculty development time and resources;
Academics are not as vulnerable to vendor lock-in as industry scientists whose firms invest significant money into proprietary software licenses;
While competitive, academic spaces are not as prone to the pitfalls of trade secrets and intellectual property concerns within industry firms

Industry scientists use OSS in a number of ways, including as primary data manipulation/analysis tools or as secondary tools for “filling the gaps” between proprietary software capabilities and the unique demands of scientific research. In other words, industry may play less of a role than academia in OSS development, but industry scientists / technical staff certainly constitute a major base of OSS users. There are exceptions of course, and some industry players have strong track-records of deploying broadly useful open source projects (see the rise of Open Source Program Offices (OSPOs) in industry firms as evidence of this trend).

Academics, though, often have a difficult time finding and sustaining industry support for OSS development and maintenance. The reasons are complex and intertwined, but include:

Academics have a mental model of funding that skews toward grants and other public sources that can seem incongruent with industry partnerships;
Academics often don’t learn the skills needed to market their projects and negotiate partnerships;
Academics are often shy about communicating the enormous value their projects provide

Here we suggest 10 simple rules to help academics find a market for their open source research products and partake in industry activities to support continued development.

We offer these rules based on our belief that open science and open licensing of content and software provides a unique mechanism for researchers and industry to pool resources and expertise and achieve shared scientific goals in pre-competitive environments. These goals are both technical and social: Academia-industry OSS collaborations can drive the creation of new capabilities in software, improve the culture of sharing and coordination to push scientific frontiers, and create an ecosystem of training materials and content that benefit a new generation of practitioners by making skill-building and career paths more accessible to all. Each of the above outcomes create significant value for academic and industry scientists, their organizations, and the general public.

In summary, the rules are:

Rule 1 - Build empathy for industry practitioner challenges

Rule 2 – Get to know your users, customers, community members

Rule 3 - Build community by understanding how your insights and tools are used

Rule 4 – Share ownership of the vision for your research activities

Rule 5 – Learn to ask for money in new ways

Rule 6 – Build partnerships into your organization’s structures

Rule 7 – Consider other organizational models

Rule 8 – Value your community leaders

Rule 9 – Share your story

Rule 10 – Demonstrate your impact

The rules

Rule 1 - Build empathy for industry practitioner challenges

Academic and industry science, although drawing from similar labor pools, have key differences that often limit academic scientists’ ability to establish mutually-beneficial Open Source collaborations. Perhaps the most basic and consequential difference is academia’s support for basic research, tool development, and tool maintenance. Businesses, on the other hand, are more constrained: Basic research is not prioritized in the same way as getting outputs to market; building tools is less important than effective use of existing tools; and maintenance is largely contracted out to proprietary software vendors. Each of these constraints can make it difficult for an industry scientist to justify OSS development and support to business leadership.

Justification for OSS support, though, is possible within industry. The key to garnering support is to demonstrate how partnerships and collaborations are capital investments that can return multiple times their contribution. As an academic looking for support from industry, it is essential to spend time building empathy for these demands, how investment decisions get made, and how they’re justified within a broader business context. The most straightforward way to do this is to talk to industry practitioners within your scientific domain: Ask them about their software challenges, probe for which parts of their organizational structures inhibit their abilities to explore and create tools in new areas, and assess what, if anything, their company has done to support OSS in the past.

Armed with this understanding, academic scientists can then ask themselves how their research, tool development, and content creation and maintenance could help to resolve some of these challenges. It is best to start small, thinking through how a minor inconvenience such as proprietary tool interoperability could be resolved with existing OSS tools rather than something new. More substantial engagements, such as building new tools, will likely require asking a company, or coalition of companies, for money. Doing this empathy-building work will help you understand the argument an industry practitioner will need to make to business leaders to demonstrate why that expenditure is good for the company, and solving a small problem to start will provide evidence of the collaboration’s potential. In many cases the stories told to support your effort inside of companies will be different, but not entirely unrelated, to the way you’ve advocated for your work in academic settings.

Find ways that industry professionals and academics can come together to discuss common pain points and challenges in the context of scientific work. Many industry professionals have a keen interest in research and discovery, and opportunities for them to share with academics can be welcomed. Create events, workshops, and fora where researchers and industry professionals can talk about their challenges and build future visions together.

Rule 2 – Get to know your users, customers, community members

If you’re developing software, training materials, lab apparatuses, research protocols, or anything that people will be users of, it is essential that you have a good understanding of how people perceive these tools and products in their own work. Start to reach out and engage with your users. There is a very strong chance that how you perceive their use of your tools is different from what they tell you when asked. Act as a naive enquirer and find out how your tools are used, valued, taught, and considered within users' organizations. There will be some variability to these responses as well as some similarities; work to find the commonalities, and celebrate and work to understand the differences. New opportunities often emerge from these unseen or "unintended" uses.

Valuing in-person interactions and meetings can pay enormous dividends for your community. These in-person events and activities can serve a variety of purposes:

Getting to know each other
Developing a strategy and long-term vision for the project that meets both community and industry partner goals
Facilitating strong technical collaborations (e.g., pair programming, software peer review)
Setting priorities for future industry / academic collaborations
Giving your community opportunities to network and explore career paths

As your community grows, people will come to your community and embrace it for a wide range of different reasons. Doing some intentional work to better understand what the tools (software, lessons, outputs) give community members as described above is valuable. But so too is understanding how involvement in the broader community and its activities (workshops, conferences, meetups, networking events) benefits community members, and it can help you to understand where the mission of the software and tools and the personal and career aspirations of your community come together. A rich understanding of this juxtaposition space is invaluable to crafting actions and next-steps that can support and help people to grow their capabilities within the tools / community you’ve built.

Rule 3 - Build community by understanding how your insights and tools are used

Science isn’t easy, and most research tools don’t have the budget to develop easy-to-use interfaces with a depth of UI/UX research. One way to address the perennial challenges of making scientific tools accessible and valued by more people is to create a community of practice around these tools and capabilities. With a strong community, a shared vision for how the community can improve the lives of researchers and industrial practitioners often emerges, and the community can collectively direct itself and evolve to the ever-changing needs of its membership. Building community is not something every scientist wants to do with their free time, but with a bit of intentional focused effort, and a few resources, it can pay strong dividends for decades to come.

Beyond just the software you produce, there can be training materials, background documents, supporting materials, and events which help to connect a user community. Be particularly aware of tool users who are using your tools outside their intended scope. A real example we've encountered illustrates this nicely:

A group of earth scientists built a tool built for earth observation remote sensing, intending it to be used to advance science in their particular domain. The team, through ongoing engagement with their users, realized that the tool was being used by biologists to analyze microscopy using multi-spectral sensors. When the tool developers engaged with these users, they found that biologists needed the tool to work on spatial scales on the order of mili / micro-meters (as opposed to the meter / kilometer scale used in earth observation). The developers could have easily viewed the issue as out-of-scope and walked away. Instead, they engaged with these users further to learn about the problem and added features to benefit both communities. The result was substantial growth in their installed user base.

Focusing on how tools are used rather than how you, the developer or creator of the tools, intended for the tools to be used can open up interesting opportunities for new support and advocacy for your work. It’s important to take the time to open communication loops with your users and invite them to share how they’re using tools, keeping an open mind to understand that they may have deeper insights to how the tools can be used than you may have considered.

Open source software is often plagued by the challenge of unshared vision about the direction of a project: The lack of alignment about project goals and direction can often broaden the scope and lead to non-complementary development efforts; likewise, uncertainty around where the project is headed can create stagnation and disengagement. At the outset of your effort, think about where and how opinions, ideas, and future moon-shot scenarios can be invited, shared and prioritized by the community itself. Building feedback loops and structures to create alignment will help to generate buy-in and support from outside participants (especially those who need to justify why working on an OSS project is beneficial to their company's goals).

Inside a large company, it can be very difficult to justify and build the support needed to go after a large tool development, strategic collaboration, or other open research activity. By opening up a vision for a research agenda, and soliciting outside involvement in the crafting of that vision, you can benefit a broader community. With a joint model for developing that vision, you can avoid many of the tragedies of the commons that often plague open efforts. Ideally this visioning effort includes benchmarks and measures for success: What should our tool be able to do next year that it can't do this year? How do we organize around providing this new capability once the idea has been validated by the community?

Rule 5 – Learn to ask for money in new ways

Researchers ask for money in very different ways than how money is asked for in industry. Money in academia is generally given based on intellectual merit or interesting areas of exploration supported by other peers in the scientific community. Return on investment is not typically a concern of academics, and grant funding is not typically seen as seed funding for ongoing sustainment of an activity. In short, academics know how to ask for money as grants, but they tend to not have a clear sense of how to ask for money from industry members. To ask for money from industry, you usually ask for money in a way that is conjoined with its return on investment, or some tangible and explainable value that the work would have to the company.

Companies have different ways they can pay for this kind of collaboration: Event sponsorships, named fellowships / postdocs, training, software feature bounties and more can all be offered by companies when there is high likelihood that it will improve its employees' work. The key to each of these kinds of financial relationships is that they are more directly related to the needs of the payer than the pure intellectual merit of the activity.

The only way to build a deeper understanding of what your supporting organizations are struggling with and need from your tool is to talk with each other on a regular basis. Recruiting good developers might be a challenge, for example, so how can your work and your project be a pathway for the company to recruit and develop contributors to your open source project that they then might hire? When you think about the financial success of the company and the impact / reach of your project as conjoined and dependent on each other, new models can arise for exploring symbiotic relationships between organizations. It is these multifaceted win-win-win scenarios that can build robust long-term support relationships.

Rule 6 – Build partnerships into your organization’s structures

Building-in a culture of collaboration is important if you’re going to value this type of work by partnering with industry. Many OSS projects have cultures and practices that aren’t necessarily supportive of contribution from outsiders, yet there are ways to encourage more collaborative relationships. Look at examples in Open Source Program Offices (OSPOs) at both companies and Universities to find groups of people that are doing the work to bring organizational change and support for open source into both academic and industrial settings. This is a long-game and takes years of intentional work and development to shift toward more open contributions and open collaborations.

Universities have a strategic advantage over companies in that they have a lot of talented people who can tackle challenging scientific and software problems and can devote time to it over the long term. Companies often have resources and capital, but are increasingly slashing R&D budgets. If you’re in a university or a private company, cultivating relationships with open source projects can be a powerful way to build innovation and infrastructure development that can accelerate and advance your capabilities.

Structures that work for facilitating this kind of collaboration include but are not limited to OSPOs. Routine (e.g., yearly) events that bring together industry players with OSS project communities, share communication forums outside of GitHub (e.g., Slack or Discourse), and ongoing opportunities for industry practitioners to engage with project leadership (e.g., office hours) can all be beneficial to strengthening these relationships and making decisions about funding easier to justify to company bosses.

Rule 7 – Consider other organizational models

High-impact work can often outgrow the support capability of an academic department. If you’re working to develop a lasting organization with independent governance and sustained long-term impact, you may want to explore other organizational models that are well suited to the types of impact you’re seeking to have. Often people think this will require them to go create a brand-new non-profit or charity organization, but in many places there are structures like fiscal sponsorship which can be a much easier stepping-stone to sustainability.

Look into what models your institution can and does already support. Many offices of technology development at research institutions are able to aid and support projects that have a desire to create a model outside of the academic department. This can be spinoff companies giving the new entity access to things like SBIRs (Small Business Innovation Research) and equity investment, or umbrella non-profits (effectively fiscal sponsorship) where activities are run through the university foundation. These structures vary by institution, and you may find that your institution does not have these kinds of support structures. There are a host of non-profit fiscal sponsors that take on projects of particular types (software, science, community impact) and support them to run under their umbrella non-profit status. This kind of structure can help you to focus on your impact and not worry about IRS tax filings, insurance contracts and other potential distractions.

Don’t discount the power of a small business to be flexible and capable as well. A small company that is agile, has low overhead, and engages in contracts and sells services can provide sustaining revenue streams for a project. There are several interesting cases of profitable companies with relatively low overhead generating sustaining revenue streams for more in-depth long-term software development.

Rule 8 – Value your community leaders

Your community leaders are usually with you because they care deeply about the work and impact of your organization. Many times they land in leadership roles without experience or training for how to lead, manage conflict, and advance a sustaining mission and vision for the project. Because of this, they’re often underappreciated and sometimes taken for granted. Their work is the glue that holds your community together and it is important to build organizations that value their work and contributions.

Community leaders are also the human glue that can create opportunities and agency for those that contribute to open projects. Whether its developing hiring pathways for private sector companies, or finding ways that private sector employees can more deeply engage in academic work, these kinds of things all start with community leaders who understand the needs of academics and industry people. Your community leaders are the bridge from the deeply technical work of your community to how it is seen and accessed out in the world. They need to feel supported and valued, such as by being given public leadership status, autonomy to explore new pathways for growing and/or sustaining the project, and seeing how this leadership work benefits them and their careers.

Some technical projects let the technical capabilities of their projects speak for themselves, but it can be important to peel back a few layers and show how your project is functioning, working through challenges, and how you’ve created new impacts and capabilities with your work. Open source work is valued and supported based on an intangible, hard-to-quantify set of things. By telling your story often, and loudly, you can showcase your organization to new potential contributors, invite new support from outside organizations, and generally invite others to share in your open model for bringing impact and capability to others.

Your story should tell the stories of humans, structures, initiatives and impacts your project has had. By focusing on humans, you show how your project fits into the lives of those who contribute. Looking at structures helps others to understand how you arrange and build structures for catalyzing your work and impact. Deep dives into particular initiatives can showcase your theories of change, and how organizational needs are being met by the work your project is doing. Shouting out your impacts helps others understand the ways you think about success, and the driving forces behind your projects.

Find opportunities to share stories wherever you can, formally and informally. Examples include publishing blog posts and user case studies, giving talks at conferences (academic and industry), documenting community members' stories via interviews and surveys, and asking companies for testimonials about how your tool has helped their organization.

Rule 10 – Demonstrate your impact

To bring sustaining support into your organization you’ll need to show that the time and resources contributed to your project result in impacts that would be difficult to achieve in other ways. To really understand your impact takes introspection and observation of those who are affected by the work you do. Again, this takes time to open the door to conversations. Some of the most exciting and interesting impacts are those serendipitous ones where a piece of software or project caused a change in an organization or person that transformed what they’re capable of.

In the context of academic / industrial collaborations, telling the stories of how collaborative partnerships impacted scientific work in academia while simultaneously creating market impacts in industry are the types of stories that will enrich your collaboration and showcase to both sides of the collaboration the value of your work. These demonstrations can be everything from data-heavy, in-depth reports of impact to small signals such as putting company logos on your website (e.g., "our tool is transforming work at WidgetMaker, BigShotBiotech, and DataScienceSuperstars"). These small demonstrations of impact go a long way in attracting more engagement from industry partners.

Conclusion

Academic industry collaborations can be strongly beneficial to both companies and academic software projects. With the right alignments, ongoing structured conversations, and unified strategy, all participants can benefit from these engagements. Academic freedom allows academic software projects to think long-term; funding from companies can complement this approach by keeping the development work grounded in real-world benefits of the project and providing the financial resources to sustain their efforts.

If you’re an academic OSS practitioner looking at these rules, seek out ways to open up your project in ways that it can be better understood by industry. If you’re in industry, you can use these rules to better understand how academics think about building and sustaining OSS projects. With open communication, shared vision, and an eye toward long-term impact, companies can readily invest in academic open source software if they can see tangible ways in which the software is being improved in ways that make it easier and more cost-effective for all.