[fn-mote]

> it's just me and a professor of previously mentioned course who are actively involved in the project

Unfortunately, past experiences I have are that a very small academic team = stay away, project will have too many rough edges.

I hope your experience goes better. Tip: A revenue stream gives you something to work with. Failing that, carefully document your whole architecture so contributors will be willing to help.

## Irrelevant Complaining

Just ran across this last year: good looking software, great concept, first half of features work great … enough to hook me, so when I finally found out the other half was bug ridden I stuck it out but ouch. Needless to say, no design document so even fixing stuff was a pain point.

[malmeloo]

I know exactly what you mean and I share your frustrations with academic software. In our case I think it helps that our main goal is to provide a good user experience: we're not reinventing toolchains from scratch, but rather making existing ones available in a user-friendly way. Especially in the past year or so I've spent a lot of effort on reducing tech debt, modernizing the underlying architecture and squashing bugs. We've gone through several UI iterations just to see what would be most intuitive. Compare that to most pieces of academic software that should technically work, but are so difficult to use that nobody except the developers really know how to utilize it.

Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)

[woah_okay]

have u looked at the teroshdl extension?