I took a look at this. First I have to say I'm mighty impressed. This is a nice bit of coding, and I especially like the drag-and-drop of components into the window.

What follows may not be the kind of feedback you want to hear, but I'm going to go ahead and say it anyway.

Given that there are lots of programs out there that do what yours does, you might want to give your program a little extra something to make it stand out. I humbly suggest that you make that something real support for styles.

Your app doesn't get styles. Doesn't really get them.  Don't worry, it's in good company. Most WYSIWYG HTML editors don't either.

But in 2008, there's really no need for another HTML editor that generates HTML 3.2, with hard coded formatting attributes embedded in the markup. It's time we all moved on.

What a WYSIWYG editor ought to really do is understand that what I want is well-formed, CSS-compliant HTML, even if I don't know that's what I want. It should understand that when I highlight a paragraph and format it with "Trebuchet MS" I don't  really want a "font face=" tag on that paragraph. What I really want is for the program to: 

1. Create an entry in the stylesheet for me called something like "Normal_TrebuchetMS"
2. Apply that style to the "p" tag on my paragraph
3. Make that style available up in the style dropdown box, so that I can apply it to other paragraphs.

The WYSIWYG program has to understand that on the web today, the stylesheet is not an afterthought but an integral part of the page. It should offer me some control over it; the option to save it as an external file or embed it in the page header, for example. It should let me import or attach an existing stylesheet (as you already do).

But it shouldn't make me monkey around with it too much. It shouldn't just dump me into an "enter CSS here" text box with no guidance, let me fend for myself as best I can, and then basically treat that part of the job as if it never happened. In MS Word, the Style dropdown shows me all the styles used in my document, or those available in the attached template. I can't understand why no WYSIWYG HTML editor does this. Why bother to let me design styles at all if I can't then apply them through the GUI?

The application should handle the creation, application and maintenance of style definitions for me, because that's what computers are good at. And if I'm using a WYSIWYG web editor, that's probably not something I'm good at. Yet it's something I really need to do, even if I don't realize it. And you know what? Even though I personally can code CSS styles by hand without too much trouble, I'd still prefer the program handle it for me, provided it did so in the right way. Hand-coding CSS is not a fun part of the job, any more than hand-coding HTML is. If the program spares me from one tedious chore, why not the other too?

I realize that this is not a trivial task, and that it requires functionality that's not included and would probably be difficult to implement with the default components available to developers. I can understand why a developer wouldn't want to take the uphill path on this. But I have a list as long as my arm of WYSIWYG HTML editors I've tried, and they all pretty much do exactly the same thing. I can't understand why a developer would want to spend their time building yet another Nvu, or another Komposer, or another WebDwarf, or another...  Well, you get the idea.

So I'm sorry if this post comes across as negative. I do like your program and heaven knows it's better than anything I could ever build. But I really feel strongly that until some bright developer realizes that CSS is no longer an optional part of HTML, and makes the effort to embrace all that implies, we're just going see this endless string of the same darn thing over and over when it comes to these kinds of programs.

I read the Coding Horror entry when it was posted. He makes some good points.

The company I work for has a polciy: no personal software licenses on their machinery. This means that my software choices come down to:

1. Choosing from the already offerred software suite, which covers the basics such as MS office.

2. Going through a fairly inconvenient process of getting the company to buy a software title I'm interested in. This means getting my manager involved, justifying the purchase to IT, a PO process, etc. There's the justification piece: Do I really need it? Why? How much do I need it? Should we consider a site/group license in case other people will need it? To tell the truth, if it were a title that isn't carried by CDW, I doubt I'd ever get the company to buy it for me. The request would probably just fall into a process balck hole.

3. Download and install a FOSS title that's close to what I want.

Guess which option I choose 99% of the time?

I think another key thing to remember here is that software is software, and open-source and commerical titles are more alike than different. Software that focused on the fun stuff (new features) to the exclusion of the not-fun stuff (bug fixing and docs)? I've seen that plenty in the commercial software world. Developers that just walk away from a product after you've made an investment in their technology? Ditto. After all, isn't that one of the things that SPAWNED open source software? The idea of a hedge against vendors dead-ending a product you rely on?

The thing is, the open source ecosystem is a developer's party. So is the closed-source ecosystem when you come right down to it. (Microsoft has been described as a cult of developers, and I think there's some truth to it.)

Developers don't think it's fun to write docs? Well, guess what, there are plenty of tech writers who DO, but where's the welcome mat for them? "Sure you can contrbute - just go this developer's website, download this suite of developer's applications, learn this developer-only source-control technology and then figure out how to fit what you're working on into its constraints. You'll need to compile binaries form source code, but you know how to do that, right? Well, it's not that hard, just look at these 27 interlocking forum postings and you'll figure it out. So once you're all set up, feel free to contribute!"

One thing commercial dev shops (usually) have going for them is they recognize that there's more to software than writing code. They make developers work with the others in the field who are needed to support their efforts. I don't see this nearly as much in the FOSS world. I think it could happen and is more likely to happen in a community setting, but it's hardly a given there, either.