Interesting example: last year Cloudflare found out that a CA had been (incorrectly) issuing certs for 1.1.1.1. They only found out 1.5 years after the first cert had been issued. The CA didn't do it with malicious intent, and as far as I know they're still in business. https://blog.cloudflare.com/unauthorized-issuance-of-certifi...

The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.

Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.

They're getting more aggressive at it too. Just yesterday I received an email from Alignerr (not YC affiliated I think) saying that my sign-up was complete and cheerfully welcoming me to their platform. I had never even heard of them. An automated "job opportunity!" email didn't arrive until 3 hours later, but by then I had already directed some angry words towards their support email.

Other, even less respectable projects are also regularly enrolling my GitHub projects into their platforms, and I have to actively reach out to them to remove it.

I'm so tired of this man. Can someone go and take away these organizations' ability to send emails?

Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.

People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)

Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.

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 ;)

That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.

For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.

There already exist fantastic open source tools such as Yosys, Nextpnr, iverilog, OpenFPGALoader, ... that together implement most features that a typical hardware dev would want to use. But chip support is unfortunately limited, so fewer people are using these tools.

We decided to build a VSCode extension that wraps these open source tools (https://edacation.github.io for the interested) to combat this problem. Students are already using it during the course and are generally very positive about the experience. It's by no means a full IDE, but if you're just getting started with HDL it's great to get familiar with it. Instead of a mess of a toolchain that nobody truly knows how to use, you now get a few buttons to visualize and (soon) program onto an FPGA.

There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.

It shows to your potential users that, even if they decided not to trust the developer anymore in the future, they will likely still be able to use your application. Everyone praised Simple Mobile Tools until the developer sold it to an ad company. But because it was open source, people were able to fork the entire suite of apps to continue using them.

There's also a lot of growth potential. draw.io likely wouldn't be integrated into so many other products if it wasn't open source. It allows them to charge money (apparently) for specific integrations, simply because everyone is already familiar with the product.

Typst is another good example. Their compiler is free and open source, but the web app is not. Certain features of their web app require a subscription, which allows them to pay the bills. But I (and many other people) wouldn't be using and recommending it if the core wasn't open source, because if Typst ever disappears, I still want to be able to compile my documents. Currently this might not matter much for your app since PDF is a universal format anyway, but as you flesh out your product, it will become more important.

It's difficult to monetise open source software, but so much more rewarding if it does work out. And your app being targeted at the general public gives you a massive advantage, since the potential market is so much larger.