Skip to end of metadata
Go to start of metadata

Definition of the problem

We are writing a lot of code, that are very useful in the context of a given project. Sometimes code is just written for a specific purpose, but often times it would save time in the future if it can be reused, potentially saving time in future projects.

In addition, if code is well written and well documented, easy to deploy, the developer will get better visibility and higher gratification, seeing that his or her work has a long-term impact. 

Questions:

  • What measures need to be taken
  • Continuity of code
  • Continuity of data
  • How can visibility, gratification be achieved
  • Best practices

 

Results of the discussion

Definition:

For products not actively used: A random archaeologist in a long future can download it and use it directly or with some acceptable work, but it not lost.

  • For this projects need to use standard technologies.
  • Documentation.
  • Is possible in the future to continue developing the software if someone want it, source code should be available.

For products actively used: People continue using it in the future and the project is maintained with an active team.

Existing communities/products:

1. If you can make your software be part of another bigger well know project will be better exposed. It can also help the quality of the software. If you can make it part of something like bioconductor.

Exposure / Marketing:

Applicable to all products:

1. Sexy webpage where you can actually:

  • Should show the problems that the software manage to solve and the project overview. Problem ­> Solution elevator pitch.
  • Case Studies with the list of previous users and what they solved. Obtain a recommendation your users for the page.
  • Download the software.
  • Documentation.
  • Better than documentation, a quick start 5 min tutorial with samples, also shown in a video.
  • The projects should be if possible driven by an open source community or at least the source available.
  • Provide standard linux distribution packages for binaries, source, documentations.

2. Search engine optimization (SEO) so people can find your product when they search.

3. Data should contain on their metadata “produced with software X”, this is something that is done by most mainstream software. Ex: Gimp.

4. Give more courses about the software inside the user community of the product domain using the problems the product solve as a hook so they get interested.

5. Use most popular products to advertise less popular products.

6. Have the software installed and available in demo machines so it can be tested by users.

Applicable to scientific products:

7. When the data is used on available scientific databases, the metadata showing with what software was produced should be visible.

8. Papers should explicitly include a bundle with the software and an explanation of how to use it to reproduce the experiment from the raw data if possible and this data should be available. This way people interested in applying the same workflow to their problems can be it a try. Obviously exist different levels of complexity, not all software can be use by all users and this should be mentioned. NOTE: The scientist are not necessarily wanting to make the data reproducible because they cheat.

9. Going to conferences where you got the opportunity to show the software.

10. Make the software available in internal infrastructures of communities that we know will maybe use it.

Gratification:
  • Make it part of your portfolio.
  • People using your software give you personal exposure.
  • Keep your Job because the software is successful.

NOTE: Have luck to develop a software that is successful.

What can you do:

At least point 1 of of the Exposure / Marketing section should be accomplished. Having an internal webpage or 4 lines about the page and a logo in an unknown page that nobody visits is not a solution. For sure some projects have archive part of this already.

 

 

Questions, Discussion points at final presentation

Q: What is 'not' active?

A: Software that is not actively used, but salvageable, can be reconstructed on a new system based on the available information and documentation. Some code clearly cannot be salvaged (specific to some windows version with heavy use of undocumented internals)

Q: Website to keep information? One for software package?

A: an internal website that is not that helpful, or a page that is difficult to parse. A webpage should have some usability aspects, requirements are given.

Q: Differences are big between different softwares, how to standardize?

A: Generic aspects are searchability and google awareness, community awareness.

Q: Asking colleagues is frequently better than google

A: Be awareof self advertisement of the colleagues own code..

Discussion points
  • Contributing to a community or a bigger project like bioconductor then this will be also better exposed. It might even have to have a higher quality due to expectations or policies of that community.
  • Example is the BIOSS project that had the aim to build ready to deploy packages.
  • Reduce time, barriers to use your software
  • DATA continuity should also be addressed, there are a few more aspects to data continuity than software continuity.
    • Continuity aspect of data publication and reproducibility. Finding data through publications.
    • Access to raw data, secondary data.
    • Access to workflow producing secondary data
    • Mining of knowhow and information, changing workflows to gain new insight based on existing data

 

 

 

  • No labels