I am very much interested in helping out. I am available on MSN, mail & GTalk on the email address provided.

I should also add that if you’re in any way interested in helping out with the work, be it beta testing, sample code or anything similar, just let me know!

Thank you for the advice, which are very good!

Regarding the recent releases, in hindsight a beta period would definitely have been nice. It was such a small addition, and I underestimated the impact it would have, and it got a bit unfortunate. But it’s also about needing people who are interested in helping out with testing, and it’s not that easy to find people interested in that.

With the license I think it’s important to see what the community wants as well as looking at the competitors, to offer something which can match what they offer. The community communication idea is to have this blog post (instead of a poll) to gather inoput and ideas, as well as balancing it with what I’ve learned about the licenses.

MIT License seems to be the best for end users, basically putting no constraints on them (or me) in whatever project DOMAssistant will be interesting to use.

The different elmsBy* methods are used internally in DOMAssistant for code separation, so offering it publicly is only about offering something which is in there anyway. Besides, if you have a certain element reference (DOM reference), it’s easier to use them directly on that element then, with the added benefit of utilizing XPath when it’s available. For example: $(document).elmsByClass("news", "a").

Another reason that they’re available for everyone’s usage is backwards compatibility, and at the same time offering a more “programmatic” approcah for those not into CSS slectors. For example, these two samples do the same thing:

$("container").elmsByClass("print", "a");

$("#container a.print");

I completely agree with John’s suggestions, and that’s my approach to, and the reason I’m very wary about adding new methods. replaceClass and especially post for AJAX calls were inevitable, so I felt it was better adding them sooner than later.

There’s also a Wiki page with Feature Sggestions on the code site, where everyone can express what they feel suited for DOMAssistant, where I will consider and comment on those.

Another thing that crossed my mind is that ElmsBy* methods might be superfluous due to the introduction of CSS selectors. The only gain I could see of having them is that they’re possibly faster than the CSS Selector method. This should of course be benchmarked to see if there’s any significant gain of actually keeping them.

Perhaps create a forum to discuss future additions to the codebase? I believe that every addition should be put through careful consideration before adding. As John Resig said during the “Best Practices in Javascript Library Design” presentation:

You should fear adding new items into your API. You need to keep it as small as possible because every single method that you add, you are going to have to support.

Wherever possible, if you can get away with not adding a method, you should.

…Just thought I’d give you some friendly advice.

Thanks, good point. I wouldn’t want it to be forced for them to re-release their changes, although my (maybe somewhat naive) hope is that they will be interested in giving something back.

I think it will be a MIT License for now, and then we’ll see.

Erik,

Good!

A modified version of DOMAssistant that isn’t released as open source can still indirectly be of contribution to the project because it can lead to contributions in the future from either the modifier himself or from someone else who has been inspired by the success of the closed modifidied library.

I think that DOMAssistant can benefit from having people contributing to the project according to their own possibilities rather than by a license. In other words - I would prefer MIT, but I don’t see anything wrong with LGPL…

Hmm, I see. To me it’s a delicate balance between offering what the other library makers do, while at the same time trying to make sure that DOMAssistant is respected.

Maybe LGPL is better if it means that it can be used anywhere, and if you tweak DOMAssistant itself, only that certain part has to be open. Preferably, given that I offer it openly, naturally I don’t want it to be closed in with anothe environment.

Do you see any scenario where a LGPL would hold any web developers/product back?

As a side note: the license reference in the DOMAssistant code refers to the DOMAssistant Google Code site, so I can change it without re-releasing the source code. Therefore, I want to try what suits everyone best without comprimising the integrity of DOMAssistant.

As I’ve understood, there might be issues where some of your other code will need to be open source as well, which isn’t always desirable in commercial projects.

Besides, most other major JavaScript libraries use an MIT License, so it felt like a good idea to be on par with them.