Charles,

Thanks for sharing your thoughts about Vine Type. As the creator of Vine Type, I am not concerned about people putting AdSense on their blogs. Vine Type, however, is flexible and can be used as a CMS for a small-to-medium sized website. If a designer uses Vine Type for a client website, then I would consider that a commercial enterprise. Do you think I should spell that out at the Vine Type website?

Carl,

Even in the situation that you describe above, it's still ambiguious. Why? Well, I hardly think that most people that want to use a blog will be capable of setting up their own blogs. Should I not, as a developer and designer, be allowed to help someone else set up a blog using Vine Type? Should I have to pay for a license in such cases even if the site that I set up is not a commercial site, but rather a personal blog? Should I be able to charge for my services, irregardless of any fees for using Vine Type?

I think you enter into a gray area and it's hard to define what is "commercial" nowadays with regards to blogs. Certainly, you would agree that "blogs" like Engadget.com and Gizmodo.com are "commercial". And yet, they do not *sell* anything.

I don't know. I certainly agree that, if it is the choice of yourself and the other developers to reap some rewards for your work, then you are fully entitled to such; it's the capitalistic way, isn't it? But the question here is whether you want to go that route or go the OSS route and offer your product for free under one of the various possible OSS licenses that would still protect your work from being exploited. (Note that I only have vague understanding of the licenses).

As for Vine Type, I'm gonna dig into it one of these days and see how it stacks up to dasBlog feature wise ;)

Charles.

I agree there is a gray area between 'blog' and 'commercial.' Perhaps I should simply provide additional features and skip the whole 'non-commercial' quagmire. I'll be thinking about this. Thanks.

As for features, Vine Type is about ease of use, standards compliance, and design consistency. It will never have the most features. It will ALWAYS strive to the the RIGHT features. I'm happy to be on your radar screen, and I look forward to any candid comments of the product.

Hi Charles, the reason we're not running our project page using Subtext in part is that we want the project page to be a portal and we plan on expanding it with a wiki. We will add a blog component to the project site (using Subtext of course), but for now, I wanted to choose the right tool for the right job. I felt DotNetNuke was a better choice for building out a portal with rich navigation.

Subtext is a fork of .TEXT and is mostly XHTML compliant. I say mostly because it depends on which skin you use, since skins are infinitely customizable. For example, you can see that my blog validates as XHTML 1.0 Transitional (http://haacked.com/). We plan to scrub the existing skins, but as you might imagine, resources are limited. Consider helping out! ;)

Also, our next major release will include a plugin model. You should give it a shot. We worked really hard to make the installation experience quick and simple. We support BlogML for importing and exporting your blog post data (thus there is no lockin). DasBLog has plans to implement BlogML as far as I know.

Also, we have the same BSD license that DasBlog does. So you can use it in any way you see fit.

Haacked,

I dunno about "Mostly XHMTL compliant". Either you are, or you aren't, simple as that ;) I confirmed that at least http://www.haacked.com/ is compliant. I understand that different custom templates may break the compliance, but at the least, I would expect that all of the default templates should be compliant. Good to see that you guys are working towards that.

Looking at Vine Type, it is clearly XHTML compliant (1.1 no less). I can tell that Carl went to great lengths to ensure this compliance by the incredibly clean (X)HTML source.

Now, don't get me wrong, I'm hardly a compliance Nazi (hey, as long as it works, right?); it's only second to functionality in my opionion. But to be sure, there are tons of people who are compliance Nazi's.

As a suggestion, both of you guys should consider adding a list of sites that are using the engine so that new users can get a quick feel for what's possible.

I dunno...maybe the two of you should join up ;) I really like some of the features in Vine Type and I really like the road map of Subtext (and the greater installed base of .Text users who would be willing to upgrade). At some point in the (possibly near) future, I hope I'll get a chance to evaluate both and do some sort of write up (nothing too formal). I'll keep you both informed. It's been a terrible pain to find and evaluate .Net based blog engines so far.

Joining up might be difficult as Subtext is a truly open source engine with a BSD license, so it can be used for both non-commercial and commercial use with no restrictions. With Vine, there are specific restrictions as Vine is ultimately a commercial product.

I plan to keep Subtext truly open source as I see a need for that in the community.

Aside from any licensing issues, I say, Vive la Difference. No one product is going to meet everyone's needs. Each product will have its strengths and users will benefit. Competition is good and leads to product improvements.

Addressing a previous topic: There aren't a lot of Powered By Vine Type sites out there right now -- mostly my clients :-) But here are a couple: iamacamera.org (my blog), vinebranches.com (my company), lostcreekmud.org (utility district), austincursillo.org (church organization), michaeljcamera.com (my brother). I'm working on transistioning other clients to Vine Type. I do plan, per your suggestion, to add a "site gallery" to the Vine Type site.

Phil,

"I plan to keep Subtext truly open source as I see a need for that in the community."

Agreed; I understand your viewpoint.

I've taken a look at the Subtext codebase and I'm very much impressed. There's more there than I thought (the codebase would probably do well to have some sort of diagram to describe how all the packages and pieces work together; a general "theory of operation" diagram). And, while some of the code is somewhat dated (no Enterprise Library?), it's well organized and well written. That being said, Carl is also doing some very nice work as well on the UI/HTML output front (a area that I understand that your team is addressing now) and it's a shame that we have two "feature bases" that essentially address the same space.

Oddly enough, in taking a look at the codebase, I'm wondering if the move to .Net 2.0 will require far more drastic action to take advantage of all of the features of 2.0 and Atlas (Go Live license!). I may be totally off base here, considering my relatively short time with the codebase, but it may make sense to halt development on the existing code (except for bug fixes) and start planning for version 2.0 with a fresh design from the ground up to take advantage of ASP/.Net 2.0 features and Atlas.