We often complain about the challenges associated with a fruitful research-industry collaboration. The current pandemic has just aggravated them as, clearly, companies face difficult times and have mostly paused their R&I activities. In this context, we propose that researchers become entrepreneurs and play both roles at the same time. Right now, this is much more the exception than the rule in the academic system. However, we argue this is the quickest way to get real feedback on the quality and impact of our research. Even if we do NOT end up finally creating the company, this is a good example of the journey being more important than the destination.

This (provocative?) position paper will be presented at the 8th International Workshop on Software Engineering and Industrial Practice. It’s the result of many discussions on these topics between myself, Hugo Bruneliere, Abel Gómez and Gwendal Daniel. Download the pre-print, take a look at the slides or just keep reading and let us know what you think about this idea!

On the need of better ways to collaborate with industry

The benefits of transferring technology from research labs to the (software) industry are well-known [2, 7] but it does not happen as often as we would like. Indeed, industry-research collaboration has always been problematic. As a result, software engineering research risks being irrelevant in an industry context [1]. Lack of specific funding for exploratory tech transfer actions, limited tax deductions for R&D, and the current pandemic, forcing many companies to drastically cut their in-novation budget, are deteriorating this situation. As a result, real scientific progress is in danger of stagnating [4].

We argue that the only solution is to become ourselves the industry partners we miss, as a way to still be able to reap the benefits of bringing our research ideas to the market and get real feedback for them.

While not a silver bullet either, we believe the entrepreneurial path is worth exploring, at least as a complement to other, more standard, collaboration models. Even if the researcher does not end up creating a spin-off, some of the intermediate steps, like evaluating the product-market fit, are valuable on their own to improve the quality of the research.

Standard collaboration models

There are many modes for research and technology commercialization [6], from direct transfer contracts to industrial PhDs to participation in large EU-funded industrial consortia. Each with a different trade-off.

Among those, in the past, we favored the collaboration model depicted in Fig. 1. Relying on an open-source infrastructure and through an intermediate SME, researchers get new research challenges from users. These are then solved via research prototypes that the SME matures and makes available to the end-users to close the cycle [3]. Nevertheless, this model still has two main issues:

  1. researchers get some user feedback but have no direct access to the clients’ day-to-day experiences with the tool (as users are, in fact, using a different version of the tool, provided and evolved by the SME) and
  2. the role of the SME is key to balance the collaboration. And more often than not, we have failed to find an SME that believed they could play that role and make a living out of it.

Triangle for industry-research collaboration

Let’s become industry ourselves!

The solution is conceptually “simple”. If we cannot find the right company/SME, let’s create it ourselves and control all parts of the equation. Thus, we would like to encourage researchers to try the entrepreneurship path every time they feel one of their research results has the potential to generate a major social and economic impact.

We believe the journey will provide plenty of useful feedback and information to improve the research activity itself, even if the researcher stops short of creating the spin-off. Evaluating the product-market fit, talking to the users, testing the product under realistic conditions, … all these steps, mandatory in any feasibility study prior to a company creation, will improve the researchers’ perception of the domain and of the quality of their own research ideas.

To maximize the amount and quality of the feedback, we propose to adopt a commercial open source business model (COSS [8]) where you:

  1. Release the prototype as OSS.
  2. Improve it to make it actually usable in real environments.
  3. Aim to get free users to kickstart a community.
  4. Try to get paying users by creating a commercial ex-tension or services on top of the open-source core.

Step 1 is already typically done in Software Engineering research. Emphasis in reproducibility and artifact evaluation tracks are also generally progressing in the research community (cf. Step 2). However, Step 3 and Step 4 is where the real “fun” happens. This is especially the case in Step 4 where the “show me the money” factor usually makes more honest feedback emerge. Indeed, you cannot “fake” customers such as in more traditional research (cf. ongoing criticisms on the scientific peer-review process).

Case study: Xatkit

Our reflections are greatly influenced by the lessons learned while creating Xatkit. Xatkit is a model-based approach to (chat)bot development [5]. Xatkit started already as a research-industry collaboration but after the partner company quit the project, we took the plunge and industrialized the tool ourselves, creating a spin-off in the process.

We are now two years in this journey, and it is surprising to see how much the tool has changed. While our technical choices seemed to work great for our research prototype, we quickly realized they imposed some severe limitations once we tried to use Xatkit for real client work.

A first major change was the realization that we needed a more powerful formalism as serious bots were much more complex than what we had anticipated while building toy examples. As a result, we had to rework Xatkit as a state-machine-based framework. Actual users also taught us that our chatbot domain-specific language (DSL) was not an optimal fit for any user profile. For non-technical people, it was too complex to use. For developers, it was not easy enough to integrate into their current tooling infrastructure. This led us to refactor the DSL as a fluent API to better fit the Java ecosystem while, in parallel, we worked on a dedicated interface for less technical users.

These lessons are a direct result of our interactions with customers and companies. There is a significant gap between what is considered a valid research prototype and an actual product. And you only learn how big is this gap once you actually try to bridge it


We propose researchers dare to play the role of industry from time to time in order to get real and direct feedback on the potential impact of their scientific work.

We acknowledge this is a challenging proposition and that not all researchers may be inclined to go down this road. For this to be viable, this type of effort should be better acknowledged (and rewarded accordingly) by research institutions [9]. This would go in line with initiatives like the DORA declaration that already recognizes the need to improve how researchers and the outputs of scholarly research are evaluated.


  1. Victor R. Basili, Lionel C. Briand, Domenico Bianculli, Shiva Nejati, Fabrizio Pastore, and Mehrdad Sabetzadeh. 2018. Software Engineering Research and Industry: A Symbiotic Relationship to Foster Impact. IEEE Softw. 35, 5 (2018), 44–49.
  2. Barry Bozeman. 2000. Technology transfer and public policy: a review of research and theory. Research Policy 29, 4-5 (2000), 627–655.
  3. Hugo Bruneliere and Jordi Cabot. 2014. On Developing Open Source MDE Tools: Our Eclipse Stories and Lessons Learned. In Open Source Software for Model Driven Engineering (OSS4MDE’14) workshop – a MODELS 2014 Satellite Event.
  4. Tyler Cowen and Ben Southwood. 2019. Is the rate of scientific progress slowing down? https://bit.ly/39mZ1DQ
  5. Gwendal Daniel, Jordi Cabot, Laurent Deruelle, and Mustapha Derras. 2020. Xatkit: A Multimodal Low-Code Chatbot Development Framework. IEEE Access 8 (2020), 15332–15346.
  6. Gideon D Markman, Donald S Siegel, and Mike Wright. 2008. Research and technology commercialization. Journal of Management Studies 45, 8 (2008), 1401–1423.
  7. Valerie Landrio McDevitt, Joelle Mendez-Hinds, David Winwood, Vinit Nijhawan, Todd Sherer, John F Ritter, and Paul R Sanberg. 2014. More than money: The exponential impact of academic technology transfer. Technology & Innovation 16, 1 (2014), 75–84.
  8. Shahrokh Shahrivar, Shaban Elahi, Alireza Hassanzadeh, and Gholamali Montazer. 2018. A business model for commercial open source software: A systematic literature review. Inf. Softw. Technol. 103 (2018), 202 – 214.
  9. Mike Wright, Sue Birley, and Simon Mosey. 2004. Entrepreneurship and university technology transfer. The Journal of Technology Transfer 29, 3-4 (2004), 235–246.