Hi everyone, and happy 2026! 
We’d like to gather feedback from the Brian user community about what your ideal Brian simulator of the future would look like. What features, functionality, documentation, or training materials do you think are missing from Brian?
Please share your thoughts and ideas in this thread!
Your suggestions don’t need to be highly specific or technically detailed – they can be broad or aspirational. Every comment is welcome!
Hi @mstimberg , Here are a couple of quick points in my mind:
Many thanks for your comment @DavidKing2020, this is the kind of useful feedback we had in mind. One small question: do you have any specific neuromorphic hardware in mind, or is this about having any type of neuromorphic hardware support?
Hi @mstimberg , I was leaning on the accessibility and user base. If I understand it correctly after surfing on the web, the EBRAINS seems a good match since it allow any researcher to sign up an account and run jobs remotely. On the other hand, it would be really cool if there could be a brian2 interface for any types of the hardware.
Thank you @mstimberg for asking 
I like the unix-philosophy of doing one thing and doing it well. This helps maintainability and stability. For Brian I think the one thing has been the flexibility and accessibility and easy integration with python, together with fast enough speed (thanks to devices). The good-enough documentation is one key.
One question arising is how to share a complex model. Obviously, we can share it with the software, perhaps inside a container. I guess this is the way to go at the moment. Lighter models are shared as scripts, which is sure the best way.
However, inspired what @DavidKing2020 mentioned about the interfacing, can Brian models (eg standalone code) be exported to any generic format? I recall there was some integration with PyNN, but your docs do not mention it. In PyNN pages the latest changes seem to be 2018, plus some software interfacing to PyNN 2020. Apparently there has been not much pressure for this kind of interface.
A low hanging fruit would be documenting an example pipeline for saving and loading spike- and statemonitor results, as well as the simulation state. Currently the pickle.dump is apparently the way to go?
This, however, brings up the larger question of the saving format. There are at least Neuroscience Without Borders and SONATA. Earlier I tried NEO, but struggled with multiple file formats.
Do you think Brian should interface with some existing electrophysiology fileformat pipeline?
Hi! I’ve been an avid user of Brian for a long while now and to be fair I’m at the point where I love fiddling and using Brian’s internal methods and parameters. I think it would be great to have an in depth developers section with some more support for “developing to interact with brian” instead of “developing brian”. I’m sorry for the lack of better words to explain myself.
Another thing I can think of for now is graph representations of networks and subsequently some convenient visualisation tools that would show the architecture and connections (I am unaware if there have been any attempts by anyone regarding this).
Lastly, I would love it for more support of the “real-time capabilities” of brian and interacting with sensors. I’ve already worked on interacting with external sensors using the cpp standalone mode but I wouldnt call the current solutions straightforward. It would be beautiful if this changes at some point.
I’ll add other things once they come to mind and I am happy to elaborate if need be.
@mstimberg Thank you for all the amazing work so far!