Interesting behavior, what would be the problem?

Hi have a bunch of home-made Arduino clones with Atmega328 uC's.

They have an FTDI header and ISP header. It seems to be that I can't generally program them over FTDI, but I can just after I burned the bootloader onto it. Doesn't matter what bootloader I choose. (avrdude: stk500_recv(): programmer is not responding error)

If I upload the bootloader again (via ISP), I can program it again using FTDI, but only once... Of course it doesn't really matter since programming it using ISP works very well, but I use the FTDI for configuration and debugging purposes using the serial port.

Sounds like you didn't implement the Auto Reset hardware properly.

When you load a fresh bootloader it has nothing better to do than sit around waiting for an upload.

Once a sketch has been uploaded the bootloader will only look briefly for an upload after a reset and will then turn control over to your sketch.

To upload without a working Auto Reset you have to use a manual reset. Hold down the Reset button (if you didn't include that either, short the Reset pin to Ground) until you see the "Binary sketch size:" message on upload. This should give the bootloader control at just the right time to notice the upload attempt.

That was what I was thinking, I used a 10k resistor and a reset button b.t.w., just like the Pro Mini design actually, I only left out the .1uF capacitor.

It is the capacitor that makes it work.
Without it you have to press the reset button at exactly the right time.
Hold the reset, down load the code. When it says downloading count to three and release.

I thought so (I looked at the datasheet of the pro mini), and soldered a 104 / .1uF capacitor between RST and DTR, but it doesn't seem to work like that either! I use the official Arduino Ethernet FTDI module to test it.

and soldered a 104 / .1uF capacitor between RST and DTR,

Why?

The capacitor should go from DTR to the arduino reset pin.

Well it does (have the cap between the uC Reset and DTR), I abbreviated Reset to RST (but might cause confusion because there is also an RTS of course in a serial port application).

but might cause confusion because there is also an RTS of course in a serial port application

Yes it did sorry.

You need to look at the signal with a scope and see what it is doing in that case then.

Yups, one of the only options indeed, I will try to! Thanks!!!