Intro

This document highlights a number of issues mentioned in recent reports on the state of play in UK e-Research, and argues that these issues can be successfully addressed by taking stock of some basic lessons about building communities in open source software environments.

Background on UK research infrastructure

E-research is defined as an innovative way of conducting research by creating a new environment for academic and industrial activity in which virtual communities share, federate and exploit the collective power of global scientific facilities.

The importance of community development in the success of e-Research is increasingly recognized internationally. For instance the US National Science Foundation funds a programme under its Virtual Organizations as Sociotechnical Systems (VOSS). The European Commission has a strand on Virtual Research Communities in its current FP7 call. However in the UK the role of building a community around processes and products associated with scientific research is still underestimated. As mentioned in a recommendation from a recent e-Research Community Engagement report, UK funding bodies should consider including similar calls for community engagement activities in future e-Infrastructure programmes [eRCEF-rec15].

e-Infrastructure in this e-Research context refers to the new environment in which researchers have shared access to unique or distributed scientific facilities (including data, instruments, computing and communications), regardless of their type and location in the world. The importance of a reliable and effective e-Infrastructure is acknowledged within the research communities, who see it as a facilitator of larger-scale and more multidisciplinary collaborations, as an enabler of innovative ways of conducting research, as a means of reducing ‘time to discovery’.

In the European Commission's research strategy e-Infrastructure is perceived as a key element of the newly organized European Research Area. Its aim is to provide an innovation space where the specific interests of the scientific communities are fulfilled and cross-disciplinary solutions for distributed research activities are deployed. Additionally e-Infrastructure is seen as an important vector of international scientific cooperation.

However a number of reports mention the need to embed the technical infrastructure employed in research in a 'human infrastructure' [LDM2006], i.e. the social and organizational arrangements enabling technologies to be effectively used [eRCEF-rec7]. For instance the AVROSS report states that the adoption of e-infrastructure is as often hindered by human and organizational issues as it is by technical ones [ref]. The report recommends that the UK should continue to promote innovation in technologies that underpin e-Research, but at the same time improve the human infrastructures that ensure that the research community has the capacity to exploit these technical innovations [ref].

Other reports make similar recommendations. The e-Research Community Engagement findings of the e-Uptake project signals the need to correct the current emphasis on technological achievements at the cost of understanding real circumstances of use [eRCEF-rec8], and encourages the formation of research intermediaries, or 'boundary spanners', who can act as facilitators between disciplines and between researchers and technical people [eRCEF-rec10].

Lessons from building open source communities

Developing this human infrastructure is not an easy job, as a number of failed attempts have shown so far. Actually it often proves to be more difficult than making available an impressive array of technical infrastructure tools. The simple reason for this is that sadly, or should I say luckily, human nature is much more unpredictable and dependent on factors usually ignored by systems architecture and software engineering planning. However, as is happens, one need not start from scratch in this delicate business of making researchers engage efficiently with the existing and further emerging e-infrastructure tools and resources. Actually quite a lot of real-life experience about building communities around technical systems exist, one of the most long established and valuable being coming from the area of open source software development.

The importance of maximizing the users' and contributors' engagement for the success and sustainability of a project is well known in open source communities. Building a sustainable open source product largely depends on creating an environment where users and developers share a culture of mutual support and a sense of belonging to a common goal. Creating this welcoming and want-to-come-back environment is not easy, but one important point about it is that it should make everybody aware that each of them is welcomed to contribute in their own way to the growth and refinement of the products being developed.

An important aspect of building a community in this way is encouraging collaboration from the earliest days of developing the code. In line with the famous open source dictum 'release early and often', developers are expected to make the code accessible from its earliest versions, in spite of its provisional nature, and to encourage everybody to contribute.

Some of the people interested in what the software promises to do may not be programmers, but they may become future users of the software. These people can actually substantially contribute to the project by doing other tasks than coding, from simply asking questions on the project's communication channels (which is likely to generate answers useful to new members), to testing and providing feedback on the software releases, writing documentation, promoting the product to colleagues and friends etc.

Growing the user base is therefore critical for open source projects. But growing the developer base is equally important, as in addition to programming, the number of administrative tasks increases dramatically with the growing demands of users. Bringing on board new people able to help with either programming or doing administrative tasks seems unlikely to happen online just like that. Nevertheless, compelling evidence from open source development shows that often friendly, transparent, well managed, well documented projects end up attracting both users and developers, by encouraging participation and appropriately rewarding their contribution.

[FIX ME] Add 2 more paras, one on project sustainability and one on tools

In sum, the main community building lessons to be learned from open source development include:

  1. Create a sense of belonging and a culture of mutual support
  2. Foster collaboration from early stages
  3. Encourage and reward internal and external participation
  4. Build and implement a sustainability plan
  5. Adapt technology to community needs

The next section discusses the relevance of these issues for the adoption of e-Infrastructure by UK researchers, as identified in the previously mentioned reports.

Removing barriers to engaging with research e-Infrastructure

UK e-Infrastructure consists of a number of loosely interconnected or separate projects, tools and services, often independently funded. Some are more general in scope and are designed to serve the needs of various researchers, but many are quite specialized and address the requirements of particular categories of researchers. Despite this mixed bag of e-Infrastructure resources and tools, the reports indicate that a number of general barriers to adoption can be identified. Some of these, I suggest, can be addressed by learning from the open source development experience.

Create a sense of belonging and a culture of mutual support

A number of researchers and service providers report difficulties in creating an effective channel of communication between the various players involved. Some software developers and service providers find it difficult to understand research questions or publication requirements. Researchers sometimes don't understand the technical challenges of implementing applications, or what distributed systems are and how they can support research activities. In the absence of some common ground for mutually understanding their aims and activities it is unlikely that they will know what to expect from each other.

As one IT service provider puts it:

“if you buy a car, you know, most people know what you get and what you should look for. But if you come to us, 'what can we do for you' is always vague, because we can do quite a lot, we’ve got a lot of expertise, but you know, if it was written down in a brochure it would be kind of a long-winded one, and often they don’t understand all the jargon that we have and all that sort of thing.” (IT10).

One way of addressing this issue is by encouraging cross-specialist dialogue:

“there is a need for more people to sit down with scientists and work with them on their specific applications [...] people that understand both, people that can understand the applications and also understand how to grid-enable them.” (NE6)

Removing the barriers associated with the use of technical or scientific jargon is another way of building a sense of being part of a common overarching goal. Respondents emphasized the need to encourage jargon-free communication that is understood equally by researchers, software developers, service providers and other potential users.

“one of the things that’s sort of continually frustrating in the field is the assumed terminology, if you know what I mean, there’s a lot of terminology that’s come over from computing science, which was never designed for the rest of us who actually do the science [...]” (EP5)

Another aspect concerns the generational gap between e-infrastructure users who are differently socialized technologically. The technical possibilities of e-Infrastructure often evolve faster than the ability of institutions to adapt. As a result the rate of technological change experienced by researchers in these institutions affects them differently, depending on their technological capabilities. University IT managers are often concerned about this issue:

“what gets in the way of our strategy, there’s also the cultural thing that the committees of the University tend to be run by the more senior academics who all date back to the days before computers took over the world, and so talking to their research students and their junior post-docs is practically speaking a different language compared with speaking to the professors” (IT3)

Providing a sensible level of guidance on using e-Infrastructure services can also be a way to enhance the sense of community. For instance, one high power computing service provider referred to the tact and patience they needed in order not to drive away early adopters:

“we know that some people use [Condor] badly, but when we find out we talk to them and say, look, you need to understand a little bit more how this works [...] if you restructure your work like this you’ll get a much bigger benefit [...] It’s a tension between if you wanted to guarantee that your users used it perfectly you’d have to hand-hold them all the time, and they would find that unbearably restrictive and wouldn’t use it, so that would be stupid” (IT49)

Sometimes a more engaging step is needed for building community. Being able to mediate between different community members is an important aspect in this respect. One respondent referred to an instance when a research team may need special access to the facilities provided by the National Grid Service (NGS), and in order to get it they may need to be recommended by fellow researchers already known to the NGS:

“you know, it can be hard to persuade the NGS to give you a 700 gigabyte [...] to actually get the data there. So I think you have to know the right people and sort of ask them very nicely to sort of, you know, send an email as someone who knows about these things to the NGS people, and say yes actually this is [...] a serious request, and they do need this amount of data, and actually it's really only [...] temporarily for them so they can actually get the data on there.” (IT42)

These intermediaries have an important role in creating the sense of being part of a mutually supporting community. As the report comments, their role in this case will involve managing the researchers' expectations (by reminding them that the NGS does not provide long-term storage for data), and at the same time acknowledging to the service provider that the requested resource is part of a genuine research requirement.

As another respondent pointed out, it is important for the community to know where e-Infrastructure usage has made a significant difference to researchers. These success stories need to be disseminated in order to inspire other researchers:

“It's been interesting [...] when people start going out and about and just saying what it is possible to do just how much excitement you can generate, so I think having stuff where you can show that people have done really new science using those tools and using jealousy. [...] it seems to be working quite well in terms of getting engagement and so the fact that you know, we're saying that other communities just like things like the systems biology communities are beginning to be very keen to play and join in.” (BB5).

Appropriate incentives can play an important role in maximizing the effect of disseminating these success stories. Some of these incentives, one report suggests, should be RAE-related (eRCEF-Rec1). This endorses a recommendation of the Century of Information Strategy report:

“The funding bodies should make the award of grants and the evaluation of their outputs include a significant element of contribution to education in the domain of the research.” (Atkinson et al., 2008, p.21)

All these examples show that both users and providers of e-Infrastructure services are aware that in order to maximize its uptake a deeper sense of community needs to be fostered, both within separate user-provider relationships and across the entire UK e-Infrastructure. The collaboration solutions tried and tested in the open source environment, and especially the ideas of transparency and bartering that eventually forge a jargon-free and mutually supporting space, can provide useful models in this respect.

Foster collaboration from early stages

Another necessary pre-condition for success in open source projects is having "something runnable and testable to play with" (Eric Raymond, The Cathedral and the Bazaar). This often means sharing a product that is imperfect or incomplete. However according to the famous 'release early and often' open source mantra, this attitude often attracts invaluable early feedback and builds confidence in the project.

Learning to collaborate early on an imperfect product is an important issue the emergent e-Infrastructure communities may want to take into account. As one of the reports acknowledge, researchers’ willingness to collaborate is key for e-Research, therefore understanding their incentives and disincentives for collaboration is an important issue. 'Collaboration readiness' (Olson et al., 2008) depends on many factors and can play out in different ways. While it may be useful for researchers to pool together skills, effort and resources, there are also barriers to collaboration, most of which are directly or indirectly related to funding.

As one interviewee puts it,

“To a certain degree research centres are in competition. So there is a certain reluctance I think in individual research centres within the same discipline sharing what they’re doing. They may well be bidding for a research project in competition with each other.” (IT20).

Research is indeed a competitive endeavor, and the nature of the collaboration between researchers or research groups is often temporary and conjuncture-driven. The pressure exercised by the 'publish or perish' demands of the Research Assessment Exercise (RAE) also affects researchers' incentives for working collaboratively and their career opportunities prospects:

“[RAE] encourages individuals to publish independently, to keep things secret while they can be many advantages to their career, no matter if they have been funded publicly or not, because by doing that they appear to be better by the criteria used for measurement of the research assessment exercise. That’s the major cultural problem, because it makes it too difficult to perused scientist to be open with their data, they fear losing it, and therefore their current position.’’ (MR5).

One way to counter competition leading to secrecy and closed doors is to share from early stages, when the sense of ownership is still relatively low. Collaboration between rival centres can be envisaged in thios sense, e.g. by agreeing on strategic partnerships between groups who agree to collaborate rather than compete on writing grant proposals, and sharing project work and research outputs.

The sharing of research data is subject to policies designed to protect intellectual property rights or the privacy of the research subjects. While in many situations these policies are useful, in some cases they may be too restrictive and end up inhibiting collaboration. Therefore one needs to evaluate sensibly the level to which legal and ethical policies should be enforced.

“I would argue that perhaps there is too much bureaucracy, it does mean that sometimes you cannot do things with data that, if it wasn’t for that, it would be perfectly reasonable to do, in my view.” (MR6).

One needs to be aware that sharing certain types of research data is not always possible. Research collaboration however need not be necessarily understood in terms of sharing data only. Actually emphasizing the distinction between sharing research data and sharing research infrastructure is an important step in clarifying the various levels on which members of the community are prepared to collaborate. In some cases researchers, as part of their university departments, may be faced with the perspective of pooling together e-infrastructure resources in order to reduce overlapping costs.

For instance departments may find it more useful to arrange for all their high power computing needs to be arranged locally, in order to avoid overheads associated with using the National Grid Service:

“I think we may look to share facilities between departments here as a way of increasing power and keeping things locally managed. That would be my guess for the next five years at least.” (BB2).

However barriers to sharing computing power may appear at the administrative level. In this case policies and support for resource sharing need to be provided, otherwise initiatives of individual researchers are unlikely to succeed:

“I looked [...] to see where if you could offer [a local compute resource] as part of an NGS resource, and it was too difficult for me to get that put on and go via that way to submitting jobs on to it, because the way I understood it is that we all put our machines on it and then the NGS would be a much bigger computer, so I looked to try to see whether the resources that we had we could stick on it, and actually there were various political barriers to doing that [...] [Parts of the University] harbor resources basically and stick up barriers towards their open use, and I guess that’s probably true about any University, I don’t know.” (ES3).

Even in such situations when institutions decide to share resources locally instead of using the nationally provided ones, the experience, if documented and shared on an appropriate communication channel, is likely to be useful to other institutions. The national service providers themselves, NGS in this case, are likely to find this feedback useful, as this would help them design a better service.

Encourage and reward internal and external participation

Another important lesson from open source development concerns the ways in which projects encourage and reward contribution, and how they manage to expand the early days team by engaging with externral users and developers. Like anywhere else, users in open source projects are usually relatively passive in terms of their interactions with the community. Some however decide to take on more active roles, e.g. by reporting bugs, helping other users, or writing documentation. A sustainable open source community has in place mechanisms for rewarding the efforts of these people. Active members are often rewarded by being offered additional access to, or control over, the project. Clear documentation explaining how one can move from user to contributor, then to senior contributor with commit rights, and eventually to participant in the decision making process, are set in place so that everyone knows what they need to do if they want to increase their influence in the project.

The first step for users often consists in offering some sort of feedback on the functionality of the product that is being developed. The key thing here is to make sure that the path they are supposed to follow in order to do that is as quick and straightforward as possible. This is surely the case in e-infrastructure contexts as well, when users decide to take the trouble to report a bug or notify the service maintainers that something is not working as it should. Keeping this path to reporting bugs or submitting technical requirements straightforward, and getting back immediately to acknowledge contribution and eventually address the issue, is crucial for the future engagement of those users.

“in the case of individual surveys, there is sometimes the case that I have downloaded a file and then found out perhaps an error within the data file, or lack of priority on a particular variable, or a variable missing within the data file that’s referred to in the documentation, and occasionally I have reported that sort of example to the help desk, and they’ve usually been, well in fact pretty much every time, they’ve been able to get back and come up with the solution quite rapidly, so I find them a very helpful service in that respect.” (ES7)

There are a number of other issues one needs to keep an eye on in order to make the adoption by users an easy process. Some e-Infrastructure users complain about unavailable or poorly structured documentation.

“essentially it was through searching for handouts and searching for presentations that were scattered about over various websites.” (ES8)

Others ask for training opportunities that would provide them with the necessary skills for starting using the service

“I can see that there are things there which we probably could be able to use in the future, but first we’d have to work out how, if you know what I mean? There are projects, for example like OGSA-DAI, and OGSA-DAI has some features which I can see they would be useful if we had skills, or if we had the time to actually be able to get far enough into the technology to be able to actually utilize it properly.” (EP5).

Support after training days is another issue mentioned by users:

“they do offer the training days, which are really quite good for hands-on help, and advice, and showcase of the software, and how to use it, you know, and example tutorials of how to build the workflow, they’re quite good, but it’s just once you get back to your laboratory and you’re stuck on your own.” (BB6).

Some e-infrastructure service providers are aware of these issues and try to make their users' experience of engaging with the service as easy as possible. One of them interestingly suggests that the documentation provided should be so good that users should not need to ask for training at all:

“if you want a wider benefit then you would have to make it easier for them to use, not just keep on training them, because you have to not just consider the cost of training, but also the cost of them not being engaged for a long time with their own stuff because they’re being trained to use this, and of course e-Infrastructure will change again and then they have to be re-trained. So what you want to do is make it so easy for them to use that you don’t need training.” (IT10)

In other words, any unnecessary hurdles that may turn users away need to be carefully removed. This sometimes involves even streamlining security gateways or renouncing the potential benefit of gathering information about the users. Registration, multiple passwords, lack of standardized access rules, difficulty of acquiring and managing certificates etc., all may potentially lead to users giving up trying to engage with the service

“I know there has been a barrier for me, and also for a lot of users, which is the requirement that you register before you can download anything from the Data Archive, and I understand why that is, but it can be very difficult and very off putting, and a lot of people just give up before they download stuff.” (AH3).

However e-Infrastructure service providers should not exclusively focus on attracting users. Instead they should consider equally expanding the very team who is developing and maintaining the service.

Expanding beyond the initial team, and harnessing the unexpected contribution of interested participants who were impossible to identify in the first place, is another key feature of open source development. In many projects developers form the core of the initial open source community, but as the product matures and user requirements multiply more contributors are always needed. If the tools and processes a developer uses on a daily basis are made transparent and appealing, and if the adoption path into the community is clear, welcoming and informative, new developers are likely to join in, attracted by the prospect of being part of a potentially successful and sustainable project.

Some of these contributors will want to negotiate a fee for their contributions, which the project leaders may be prepared to consider or not, depending on the financial circumstances of the project. Other contributing developers may actually be paid by their employers to work on particular aspects of the product. Others may be attracted by the technical challenge, or the prospect of acquiring kudos, or simply to improve or showcase their professional skills. All the accepted forms of external collaboration need to be made clear in the project documentation.

Usually the teams tasked with building and maintaining e-Infrastructure tools work in closed projects, in the sense that the technology or software being developed is kept within the confines of the team and no collaboration is sought from the outside world. Apparently there shouldn't be anything special about this, as many of the tools and technologies that researchers use are produced in this way. However, with e-Research placing so much emphasis on sharing and collaboration, it should be possible for these teams to put in place mechanisms by which external contributors could work, for instance by developing certain user requested features that the service cannot deal with by itself.

Build and implement a sustainability plan

One issue OSS Watch often hears about when consulting with academic projects is their concern about continuation funding. Being able to secure follow-up funding at the end of a project is often perceived as a recognition of its success. Conversely, failing to secure further funding is seen as an expression of the project's incapacity to persuade funding bodies that what they previously did was valuable enough. In this context, the sustainability of a project (and of its outputs, including software) is understood essentially as securing further funding.

However this is definitely not the only way, as indicated by the experience of open source development teams. Support beyond the initial funding may come in various other forms, such as user or developer time spent on the project, or paid technical support for the software being developed. All these alternative revenue streams and ways in which the project thinks the software will be maintained and updated, are often put together in a software sustainability plan. By making this plan widely available online, the vision for the project becomes clearer and any potential external contributors can better plan their engagement with the community.

In the e-Infrastructure context sustainability is often mentioned as a potential source of concern. One aspect refers to the sustainability of the technical solutions offered by the service providers, which is critical for the researchers’ decision to adopt them. Some respondents mentioned the lack of reliability of technical solutions produced by academic projects with time-limited funding.

“So you’re working with products that come out of research rather than out of a software factory, and often these will have problems or they’ll be half finished or they don’t really fit together yet [...] it's difficult to decipher what the risk is before you start.” (IT10).

Most of this software is not yet ready for general use, and requires significant time and skills from users to actually deploy:

“most academic software seems to have the lifespan of about a year before it disappears, or doesn’t get updated, or something, and we just can’t work like that. So the reason why we would always want to work with people like OMII and the Text Mining, rather than some of the academic groups within the space, is that we know that there’s longer term support available, so the stability matters to us.” (BB5).

The OMII model this researcher refers to is one in which early stage software from selected research projects is 'hardened' and maintained up to the point that the research outputs have been produced. The code is released under an open source license, so that anybody can inspect it and provide contributions.

The fact that OMII provides this level of development and support for a limited period of time seems to be good enough for some researchers. However, as a recent report points out, it may be the case that these issues need to be addressed in a more fundamental way. 'The way in which funding is provided for projects developing software may need to be more radically changed, so that they start producing self-sustainable products rather than just prototypes.' [ref]

Or, in the words of this researcher:

“unfortunately we found that GridSAM has some problems, and unfortunately GridSAM is no longer actively developed [...] Depending on what happens over the next 3 or 4 months we’ll probably either start coming up with [...] solutions that work better for our purposes or try and fix GridSAM ourselves, I would guess. I mean [OMII has] been trying very hard but obviously it’s very difficult because the developers are employed on something completely different, so it’s quite hard to get the support for a lot of the OMII software, although they are trying hard to improve that. Unfortunately most of the software that’s in the OMII stack isn’t actually finished, that's the main sort of problem. I mean, I think OMII is a very good idea but they’re in a very difficult position because obviously most of the time a research project is funded for 18 months, 2 years, 3 years maybe, it produces results, it demonstrates a technology, but you know, the EPSRC in the UK were not very good at funding software development projects.” (EP5).

As mentioned earlier, in building and maintaining e-Infrastructure services the initial development costs are usually covered by time-limited research grants, therefore the completeness and usability of these applications is limited. Additionally, their adoption by early users often generate further requirements, and the need to provide ongoing maintenance, which the project simply cannot offer:

“It’s difficult because a research group [...] has a number of post docs and PhD students and it’s not a software engineering company. So when you finally deliver something it's going to be a prototype, it's never going to be a finished product. But they then start depending on it, and then the problem arises, because you don’t have the funding or even the capacity to maintain [it ...] whenever they want to change something, and they don’t have the money to do the same thing, because they can’t just say, oh here’s an extra amount of money just to add this feature that doesn’t exist, so it's going to be very limited.” (IT10).

Adapt technology to community needs

The prevalence of technical over social aspects of e-Infrastructure was one of the main issues mentioned in the reports. The message was clear: instead of building tools thought to be useful to the research communities then struggling to persuade them to use them, a more sensible approach would be to involve users themselves in the process of building them, at all the steps from design to adoption, thus ensuring that what is being built will suit best their needs.

One problem with the previous approach flagged by some researchers, especially from the arts and humanities, was that the e-Science paradigm itself, which was at the root of building e-Infrastructure, was felt as potentially inappropriate for supporting the types of questions asked in the respective disciplines.

“Being able to fit an e-Science paradigm into Arts and Humanities is the problem rather than whether we can use the technology.” (AH1).

Consequently the e-infrastructure tools pushed to the researchers ran the risk of not being disciplinary neutral, and since using them could dramatically affect research practices in some disciplines, their adoption would be compromised.

“there are fundamental barriers to using these technologies for the Arts and Humanities, but that’s to do with the discipline [...] rather than [with] not understanding the technology, not being able to get the technology. It’s a matter of what can we do with these technologies which are useful, which are methodological questions, and also [...] about what is Arts and Humanities, what kind of research are we doing?” (AH1).

Understanding the aims of the community and matching technology accordingly is therefore of crucial importance. In some open source circles this issue is known as the 'community over code' requirement. 'Look after the community and the code will look after itself' is another way of putting it in a memorable way, which also flags the importance of letting community members select or develop the tools they need rather than pushing them to adopt externally designed and built ones.

Another issue emphasized by the reports concerns the more practical aspects of engaging with technology. One respondent mentioned issues related to the different configuration of the NGS nodes, which resulted in the need to compile code repeatedly:

“So the problems we faced from the user’s point of view, I guess the biggest problem, is that the machines in terms of libraries and compiler versions aren’t kept in sync. So it’s not – MPI libraries and so on – it’s not always possible to compile on one machine, especially MPI executable, and then take it to another of the NGS machines and run it, and this is a significant problem because it means that [...] where you use multiple machines you have to long into each one in turn and compile your code, which takes time, and the more grid resources you have, the more time that takes.” (NE2).

A proper mechanism for keeping the different software versions in sync is crucial. Here again the open source experience of working on software code as online distributed teams can be useful. In the same way in which open source teams use versioning systems to avoid clashes between the different versions of the software they work on at the same time, technical solutions can be found for streamlining the process of synchronizing the NGS nodes. The key is the ability to coordinate the people and processes directing the performance of these nodes rather than the technology itself.

Another issue mentioned in relation to the NGS concerned the degree to which e-Infrastructure tools software allow others to build on top of it.

“[...] what I would like to do is build applications that use the NGS underneath, and the NGS has the wrong kind of interface at the moment, so it’s difficult for me to build those applications [...] it’d be useful if the interface was a service, at the moment it’s a log-on, I have to log on to the system and type my own commands.” (NE1).

[Footnote: The NGS is currently developing a GridSAM-based endpoint for job submission but this is provided only as a pre-production service]

The open development lesson here is that one needs to constantly bear in mind the sustainability of the product that is being built, and the need to make the community around it thrive. By ensuring that the technology associated with the product is as easy to engage with as possible, one maximizes the chances that others from outside the project try it out, modify it, build on it, and thus become future community members ready to dedicate some effort to its benefit.

Conclusion

References

OSSWatchWiki: ResearchSustainability (last edited 2013-04-15 13:56:14 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.