intertwingly

I probably met with 70 to 80 people over the last few days.  Some were from large companies/organizations, many more were from small companies or informal organizations.  I have a large number of specifics that I will inject into the wiki over the course of the upcoming weekend, but for now, some overall themes.

First, I won't pretend that this sample size was representative or scientific.  But the feedback seems to me to be amazingly consistent across a diverse set of people, and bears further reflection.

The most striking input was about the wiki.  It's biggest strength and weakness is that it is inclusive and chaotic.  Shortly after the 0.1 snapshot was published, the wiki example evolved in a radically different direction - replacing most elements with attributes.  This stayed for a few weeks and then snapped back.  This is leading many to the conclusion that the best course of action is to simply sit things out for now.  This is OK with me, if it truly represents an "either way is fine with me" vote.

What I want to avoid is people with something worth contributing only doing so after it is too late.  The only solution I know of to this is time.  Publishing infrequent snapshots, with clear rationale for every change, and encouraging experimentation.

Another clear example of this is the inability of the project to come to agreement over a name.  The wiki was amazingly efficient in ferreting out the trademark issues with the name Echo.  It may have been similarly efficient in doing so with Atom, but many worry that it may have been a bit too efficient, and perhaps even hasty in this process.  There are people who have expressed a willingness to donate professional legal resources towards resolving this issue - but are reluctant to do so if such an effort would be disregarded.

To be clear, my favorite name so far was, and continues to be, 'pie'.  But I am clearly in the minority on this, and I fully accept that.  Beyond that, any name on the current FinalVote list (with the additions of Echo and Atom, but not Necho) are acceptable to me - subject only to a legal clearance on the name.  In my opinion, what's best for the project is to let go, and submit this list to people who are willing to dedicate the resources to research this properly - and in so doing, be willing to accept the outcome of the result.

The final overall theme that seemed consistent is the importance of security in an API.  Unsurprisingly there is widespread agreement that sending passwords in the clear is not sufficient.  What was more surprising is the input that, given the number of people blogging in conferences and public locations,  md5 or sha1 hashes of passwords is also not sufficient.  These, too, can be sniffed and replayed.  What's needed is a solution that is not only easy to implement, but also one that is easy to administer.  Not only for large, hosted, blogging providers, but also for small individually hosted weblogs.