Trusted by design

set up your research software for community adoption

Niko Sirmpilatze @ FOSDEM 2026

2026-02-01

So, you want to make a research software package

How do you persuade others to use it and contribute to it?

Practices that build trust

1. Define your software’s mission and scope.
2. Make a reasonable first release and follow it up consistently.
3. Embrace radically open communication.

whoami

• Neuroscientist & Research Software Engineer 🧠🐭💻
• Sainsbury Wellcome Centre, UCL
• Fellow of the Software Sustainability Institute
• Participant in the Birdaro Training Program

Find me online

niksirbi | @niksirbi@neuromatch.social | nikosirmpilatze.com

Neuroinformatics Unit (NIU)

A research software engineering (RSE) team… dedicated to the development of high quality, accurate, robust, easy to use and maintainable open-source software for neuroscience and machine learning.

Built and maintained by us

~25 open-source Python packages, including:

BrainGlobe: computational neuroanatomy

• >3 million downloads
• 140+ contributors
• 70+ dependent packages
• cited 400+ times

movement: animal behaviour

• >80k downloads
• 30+ contributors

Your mission & scope

Scoping out your project

How do researchers do it for scientific projects?

• Write an abstract before you even start!

• It’s not your destination, it’s a compass.

How about software abstracts?

mission statement: single-sentence, high-level.

Followed by one or more of the following:

• Specific aims
• Scope (features)
• Design principles

movement’s graphical abstract

In the early days of movement, Mikkel Roald-Arbøl reached out to us with this message:

Hi everyone!

I’ve followed the project from the side-lines for a few months now, … I have over the past few years been curating a similar package for R, … functionality seems to overlap, … Would be great to have someone to work together with on which features are useful, what are best practices, etc. and have packages for both Python and R.

The perks of a having abstract

Do it publicly and up-front.

• You invite collaboration and scrutiny early. 🤗
• You sharpen your vision. ✊
• In disagreements, you have something to point to. 🧭

Release early, release often

Eric S. Raymond, The Cathedral and the Bazaar

The Cathedral and the Bazaar

 

 

 

Your first release

Our team’s check-list for a minimum viable product (MVP):

1. The software contains at least one useful feature.
2. That feature is well documented, incl. usage examples.
3. The software installs seamlessly on target platforms.

One feature is all you need

• Keeps you focused on a concrete milestone 🏁
• Won’t be perceived as trivial if you’ve clearly articulated your mission and scope 😉
• Goal is to reach a few early adopters fast 🎯

Seamless installation is crucial

You don’t get a second chance at making a first impression.

• It’s hard: dependency hell is called that for a reason.
• Manage expectations up-front.

Subsequent releases

Rinse and repeat:

1. Release a few features at a time.
2. Avoid releasing undocumented features.
3. Make sure you don’t unknowingly break existing functionality.

Incremental releases rock 🤘

For your team:

• Easier course-correction
• Small wins to keep morale high

For your users:

• Can adapt their workflows gradually
• Clear release notes are essential!

For the ecosystem:

• Predictability is currency.
• Respect your neighbours.

Radically open communication

From one-way announcements to multi-way interactions.

Use issues as a scratchpad

• If you get a new idea, write an issue.
• If you get new info on an idea, comment on the issue.
• If an idea bursts its banks, break it into smaller issues.
• If two ideas are related, cross-link the issues.
• If an idea is no longer relevant, close the issue.

Tip

If you can formulate it as a sentence, it’s ready to be written down.

Where would you post an issue?

The perks of a public scratchpad

• Transparency builds trust.
• A lively issue tracker signals activity.
• Attracts like-minded people.
• Other people may solve your problems.

Pull Requests

Make all changes through publicly visible work.

• Leads by example.
• Creates a documented track record
• Facilitates review.
• Every review is a chance to embody your norms.

Scale your comms alongside your community

Warning

Past a certain size, managing all these channels requires significant effort.

Practices that build trust

📝 Write a software abstract

Carve out your place in the web consciously, openly and from the outset.

🚀 Release early, release often

The trust you build through consistent, predictable releases compounds over time—worth far more than the polish you sacrifice by not waiting for perfection.

🤗 Embrace radically open communication

Write everything down. Make it public by default. Watch the magic happen.

See blog series for more details

neuroinformatics.dev/blog/trusted-by-design_intro.html