TexGen: a case study

by OSS Watch on 17 June 2009 , last updated 11 June 2012

Introduction

TexGen is a program written and maintained as part of the work of the Polymer Composites Group at Nottingham University. Key to several of the group’s grant-funded projects, it was open sourced in late 2006 as part of a strategy to make it available to the wider industrial and academic research communities. Through its role in these funded projects, TexGen plays an important part in bringing research funding to the group. Furthermore, the group believes that the decision to make TexGen freely available has both attracted some grants which otherwise might not have been forthcoming, as well as being a factor in the renewal of the group’s underpinning EPSRC ‘Platform Grant’¹.

Introduction to TexGen

TexGen generates realistic models of textiles, including their properties. Its primary application is in the design and manufacture of fibre-reinforced composites. A composite material is one that is made by combining two existing materials; in a fibre-reinforced composite, stiff, strong fibres form one part of the composite, reinforcing the other. In manufacturing, it is common for this reinforcing material to be supplied in textile form, woven from ‘yarns’ made from the fibres. TexGen creates computer models of such textiles, incorporating the structure of the weave, so as to simulate the behaviour of the material.

History

Development of TexGen began in the Polymer Composites Group at Nottingham University in 1998, when the initial algorithms were conceived and the first version of the software was written. In 2002, it reached version two after being re-written.

It had always been the case that TexGen was released freely to the group’s research partners. It was also supplied on demand to anyone the group considered a potential research partner, though only around 10 or 20 such requests were received. It was not, though, publicly available for download, and it was a goal of the group that it should be made available in this way. However, version two had several weaknesses that were an obstacle to these plans to release the software more widely, and which also caused difficulties for the group’s own, internal development efforts.

First, it had never been planned that multiple developers would work on the code base, so there was insufficient documentation of the code and no clear design. This was already causing problems, as it meant that the project was being maintained by a single developer, a PhD student. Having only one developer meant that feature requests, even from within the group, were difficult to accommodate. If a wider release attracted additional requests from external parties, it would be necessary to ensure those parties could add the features themselves rather than expecting the single project developer to do so. Insufficient documentation, and code that is difficult to understand, can be off-putting to potential external contributors because it is difficult to get to grips with the code base.

Furthermore, the code was dependent on components of Microsoft Windows, meaning it could not run on other operating systems, such as the department’s high-performance cluster. Finally, it also depended on a third-party component whose licence prohibited redistribution with TexGen. This would have been a significant barrier to TexGen’s wider distribution and uptake, as users would have had to be willing to obtain this necessary component. Version three, therefore, was to be better structured and documented, with a clear design preceding implementation, and not dependent on one particular operating system or proprietary component.

Open sourcing

It was the intention of the group to make TexGen freely available: if people could download TexGen and use it for free, such casual use might lead to collaboration. However, it was the suggestion of the students developing version three that TexGen be made open source as well. The supervisors of the project agreed, for the reasons set out below. The group chose to release TexGen under the GNU General Public License v2.

The first reason for releasing as open source was that the software is not novel in itself, and, while some of its algorithms are novel, these had already been published. This meant that the group would not have been giving away any important research in the open sourced code that was not already publicly available. Conversely, where there are techniques embodied in the software that would not be publishable in themselves, but that the group still want to disseminate in some way, the code itself can be a way of disseminating such work.

Another reason was that users might gain confidence in the program if they were able, by studying the code, to see how certain problems are solved. For example, any uncertainty regarding any aspect of the operation of the software could ultimately be resolved by examining its source code. Further, people could gain a more thorough understanding of TexGen by studying its source code, and this might lead to them being able to use it in more flexible and intelligent ways. Furthermore, with the code available and the right to make modifications, third parties could also incorporate extensions of their own into the program.

Finally, intellectual property rights (IPR) issues are simplified by releasing the software as open source. Because the affected material has already been released as open source, partners using the software would no longer need to consider whether any limitation need be placed on their use of TexGen so as to preserve the university’s intellectual property.

An alternative route might have been to charge for software licences as a product. The group, however, rejected this. First, commercial customers would expect support, which the group did not want to provide. Another significant reason was that, if the software had to be bought, casual use that might have led to fruitful collaborations would not occur. In addition, it would mean that all development would have to be done in-house, further increasing the work for the group. And, while this could be ameliorated by, for example, entering into a partnership, the nature of a commercial partnership might inhibit collaborations with other, competing companies. Finally, TexGen would probably only have been viable to sell as part of a larger system, not on its own.

Scripting TexGen

A notable feature of version three of TexGen is that it can be controlled via scripts written in the Python computer language, or be used as a component by Python programs. Either way, this allows one to develop programs that are not themselves part of TexGen, but that can use facilities provided by it. The specification of the exact functionality that TexGen offers to external programs is known as its Application Programming Interface (API). Using this, one can, in effect, extend TexGen with additional functionality without having to modify TexGen itself, or automate sequences of operations that would otherwise have to be done manually through TexGen’s user interface.

From a technical point of view, being able to customise or extend TexGen’s functionality from one’s own, separate program is desirable because that is likely to be easier than modifying TexGen’s code. Someone using TexGen in this way simply needs to understand its functions in terms of what inputs are expected, and what outputs are provided; that is, each function that TexGen offers may be treated as a ‘black box’, in that one need not know how it works, so long as one uses it according to the documented API. Modifying TexGen’s code, on the other hand, would require a programmer to understand, to some extent, TexGen’s overall architecture, and details of its internal operation.

Furthermore, external scripts allow users to extend TexGen while still keeping the modifications separate from the main code base. This may be desirable, for example, in order to delay code publication until research has been published or to help in managing an institution’s or company’s intellectual property. It should be noted that in a healthy open source project all modifications are donated back to the core project, where they will be accepted or rejected based on the strategic goals of the project. However, in some environments this may not be desirable, as is the case with research outputs. Since researchers are able to extend the application via a published API, TexGen developers can change TexGen internally in any way they want without breaking compatibility with users’ scripts, so long as they do not change the defined interface (API) that external scripts depend on. For the developers of the external scripts, this means that their interface to TexGen’s functionality is likely to stay stable over different versions of the program. Modifications made directly to TexGen’s source code, by contrast, could easily conflict with changes in new versions of TexGen, and in any case must be re-applied to the code of each new version. Once the research has been published, these code modifications can be published, allowing TexGen to remain relevant to the domain.

Governance and community building

TexGen is part of several continuing, wider projects within a university department, and development of TexGen is done by members of those projects; external contributions have come primarily from alumni. As such, there is no formal governance model. Active efforts at community building take the form of publicising TexGen at academic conferences, industrial seminars, and so on; a clear ‘spike’ in downloads often follows such events.

While the work on TexGen is still done mainly by members of the group, the project’s infrastructure was set up in such a way as to make it easy to engage with external contributors, should they emerge. Features key to the practice of open development - a version control system, a public issue tracker and public forums - exist and are used by the current developers, even in the absence of significant external input. This provides an easy and commonly understood way for outsiders to engage with an open source project. However, to have a clear governance model, setting out the rules by which the community operates, would be desirable: it clarifies the status of the members of the project, and be appealed to in case of dispute. Being able to understand in advance the conditions under which a project operates allows contributors to plan their involvement.

Outcome

TexGen has found users in both academia and industry, with over 3000 downloads registered by May 2009. Notably, valuable research grants and partnerships have come from companies that may only have become aware that Nottingham possessed the expertise they sought thanks to their experience of TexGen. The TexGen development team is convinced that this sponsorship would not have occurred had TexGen not been freely and publicly available, as those companies would have been less likely to have begun using the software.

At present, TexGen is used in eight of the group’s total of roughly 20 funded projects. In four of those cases, the industrial partners that initiated the project were existing users of TexGen, having downloaded it since its open source release. The group believes that two of these partners approached Nottingham University as a result of their downloading and using TexGen. The value of these two grants is £176k and £318k. These awards, focused on performance of technical textiles and apparel, represent new directions for the group, with entirely new partners from new business sectors.

Most importantly to the University, provision of the software as open source was a key factor in securing renewal of a prestigious EPSRC Platform Grant to underpin future fundamental research related to technical textiles and composites. This award, worth £836k over four years, supports the group as a whole, not just its activities concerning TexGen. Making TexGen freely available as open source helped the group to demonstrate a clear route for dissemination and exploitation of its work, as required by the funding body: Prof. Long, Associate Dean for Research at the Faculty of Engineering at Nottingham University, states: ‘At our panel interview [for renewal of the grant], the panel members (senior academics and industry representatives) were extremely impressed by our approach [to disseminating TexGen], and in particular the very wide user base and range of applications that this had generated.’

Conclusion

The Nottingham group’s approach to the dissemination and exploitation of TexGen is one in which the software itself is not treated as the primary asset to be exploited. Rather, the focus of the group remains its wider research. The role of the open sourced TexGen has been, therefore, as a vehicle for enabling further research in the field, both within and outside Nottingham, and as a vehicle for propagating part of the group’s work and advertising their expertise. This has benefited not only those people in academia and industry who have thereby gained a new tool to use in their work, but has also brought benefits back to Nottingham itself. First, the body that awards their underpinning Platform Grant recognised this as a successful approach to dissemination, a key factor in renewal of the grant. Second, it attracted two additional project grants from partners who were inspired to approach Nottingham thanks to their use of TexGen. Lastly, it allowed the group’s work to spread beyond its normal field and be used in different areas. The two additional project grants the software attracted both illustrated how open source projects can successfully be exploited and sustained, with these two partners realising the applicability of Nottingham’s expertise to their own area thanks to their use of TexGen.

Acknowledgements

This case study was written with the kind assistance of Prof. Andrew Long, Associate Dean for Research at the Faculty of Engineering, Nottingham University. This document is largely based on a presentation given by Prof. Long about TexGen, and on the answers to specific questions which he subsequently provided.

Some details of the initial Platform Grant and the renewed grant. ↩

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.