Very nice use of FlexWiki as a Bliki: http://bliki.salamandersoftware.co.uk/.  Nice use of WikiTalk.

This evening FlexWiki took the next step in its life and has been made available at SourceForge.net under the Common Public License. With this step, the developer community will have the latest source (including all the WikiTalk features), better access, better tools, and a better legal environment.  The FlexWiki developer community has kinda stalled out a bit over the past few months as I've worked to get FlexWiki to this point.  Now we can really get going again!

As I was thinking about what I'd write in the blog entry, I found myself enumerating questions that I thought people would have. So, I'm going to use question and answer form to talk this through. It's been a pretty exhausting process getting ready for tonight (not to mention the hard work going on in my "real" job at Microsoft and my fabulous, but recently sick family). If I've missed something important, forgive me - or better yet, let me know.

Why am I doing this?

So if it was exhausting, you might ask: why are you doing it?  Well... for me it's all about the FlexWiki experiment.  I've spent a lot of time on a lot of projects over the years and there are a set of things that I've seen cause pain and suffering consistently throughout.  It's always seemed to me like a number of those things could be addressed by Wiki (e.g., not enough communication, a lack of a shared vocabulary, tools that are too heavy and get in the way of collaboration, no record of project history).  That's what originally motivated me to build FlexWiki, starting last year here at Microsoft with Chris Anderson and proceeding, well, through today :-) 

I wanted to test my hypothesis that Wiki could help.  There's no question that, at first glance, it seems like Wiki could (help) solve many of these problems.  But Wiki's got some downsides of its own.  And there's a real honeymoon period, too.  So the real questions was: could a good enough Wiki implementation really improve the software development process here at Microsoft?  That's the FlexWiki experiment -- for me, anyway. 

I still don't think I really know the answer yet, though the indications are good.  Regardless, a funny thing happened on the way to an answer - lots of other people (both inside and outside Microsoft) got interested. 

There are a bunch of teams inside Microsoft using FlexWiki now (unknowingly participating in my mad science experiment -- heh heh).  And after repeated requests, I also made the code for the early version of FlexWiki available on GotDotNet and people started using it and contributing to it.  In the meantime, FlexWiki has had some nice successes and more and more people want to both contribute as well as use FlexWiki.  Which means it's time to scale up and take the next step with FlexWiki.  Thus SourceForge.net and thus the Common Public License (CPL).

I don't know about FlexWiki, can you give me a summary?

FlexWiki is an implementation of Wiki, a web-based, collaborative writing environment.  I wrote a lot (but not all!) of FlexWiki.  While there are lot of Wiki implementations out there, this is a nice one because of its various features.  FlexWiki is particularly designed to allow multiple teams focused on diverse, but related, projects to work in the same Wiki environment with multiple namespaces. This allows large groups of people to collaborate more easily. Additionally, FlexWiki supports a new, fully integrated, scripting language - WikiTalk. WikiTalk enables content contributors to access .NET framework objects for dynamic content while working within the traditional Wiki environment and it allows .NET developers to easily expose rich dynamic functionality to writers of Wiki content.  For a quick jumping off point about FlexWiki overall, check out http://www.flexwiki.com.

I've been following FlexWiki in the past, what's changing now?

A few simple things:

• The source code is moving from its current host to SourceForge.net
• The source code is licensed under the CPL and contributors need to agree new licensing terms described above
• The latest sources -- including all the WikiTalk support is now checked in
• We have a fantastic new continuous integration system that automated builds from the SourceForge.net CVS repository (thanks to the amazing efforts of Craig Andera [author of fwsync and FlexWikiPad] who has offered himself up to be FlexWiki buildmaster!  Much karma goes his way.)

Why SourceForge.net?

Pretty easy answer.  Actually three easy answers.  First, WiX and WTL (the two projects that Microsoft has released like the company's doing today with FlexWiki under our Shared Source Initiative) have both been successful there.  Second, SourceForge.net has a wide range of tools and services to support the developer community; many of these will be helpful as the FlexWiki development community continues to grow.  Third, there are lots of Windows-related projects on SourceForge.net (I think it's over a third).  This all adds up to a good strong place for the FlexWiki development community to land.

Why the Common Public License?

I'm not a lawyer and even though I find the law interesting and engaging, I'm not going to pretend that I am one.  The advantages I see in releasing FlexWiki under the CPL going forward are: (1) it's a well-established license used by lots of people on lots of projects (including IBM); (2) it provides clear answers to many important questions left open to interpretation by many other "open source" licenses; and (3) it effectively addresses the right set of issues to enable individuals and companies to both contribute to the FlexWiki project as well as to comfortably use FlexWiki as a collaboration tool.  This last one is really the most important one for me.  I want to enable the broadest range of people to get their hands on FlexWiki, try it out, make it better, etc.

[Remember, it's all part of my "secret" experiment :-)]

You said "better legal environment" above.  What did you mean?

As part of this change with FlexWiki, contributors to the project will assign ownership of their contribution to Microsoft and then, as part of the same agreement, we give it all back to them.  This is pretty common practice for a bunch of important open source efforts (like the Free Software Foundation which does the same thing).  The advantage here is that the project gets a single, clear copyright owner, etc.  This is an example of the kind of "better legal environment" that I hope will make companies (even) more comfortable using and extending FlexWiki. 

Thanks to early contributors Craig, Mike, Jan and Ryan for your contributions and agreeing to help FlexWiki grow.

What's next for the community?

Over the next couple of days, I'll write more about this, but I am hoping to rally the FlexWiki community around the idea of driving to a 1.0-level release.  Right now, FlexWiki is really a strong beta.  But it's got a pile of bugs and feature requests.  Now that all the latest sources are available and we have good tools and such in place, I would like to gather a group of folks in the FlexWiki community together, identify the bugs we need to fix, the features we need to add and then work together to get it done.  If you're interested in this work, let me know directly or join the FlexWiki users mailing list where I'll also post more info.

Call to action

So:

• Grab the latest release of FlexWiki and try it out
• Grab the sources and look around
• Sign up for one or more of the FlexWiki mailing lists
• Send me your comments and questions

In closing...

It's been a long road to get here.  I first started working on trying to move FlexWiki into the world of Shared Source this spring.  It's been a bit of a menagerie working together with folks inside Microsoft to get here today.  The challenges have really been same same kind of challenges that exist doing something unusual in any big organization.  But the people I've worked with - both making FlexWiki better and helping it get to today - made it much better and much easier than it would have been, I think, at most other places.  People like Korby, Tommy, Omar, Jeff, Rob,  (just to name a few with blogs). Thanks go especially to them (and to some others who have, perhaps, the good sense not to have blogs :-)).

And thanks to Ward for starting it all a long time ago...

OK, I finally found some time to address many, but not all of the annoying and lingering problems using FlexWiki with Firefox.  This came partly down to CSS work and partly down to how script and forms all fit together in the initial implementation of the topic editing page.  I've gotten the two major Firefox problems fixed now (font sizes and the edit page working).  There are a few other minor things I got working, too. 

There are two features that you get in Internet Explorer, but not in Firefox yet: TopicTips and the TopicBar.  These are nice features of FlexWiki, but not essential to its operation.  There's no principled technical reason why these don't work yet; just time :-)

This is running live on FlexWiki.com and will be available in build 1593 (available at flexwiki.com within a few days).

Well, I haven't spent any time writing Outlook add-ins as I'd imagined.  Instead, here's something positive and something nagative from my experiences so far with Getting Things Done and the Outlook add-in:

On the plus side:

• Contexts are great.  Putting things onto a todo list and pre-categorizing them based on the context in which you want to do them is great.  This is super helpful.  When I have a few quiet hours in the morning, I can do the things that require concentration.  When I'm between meetings or only have a few minutes free here or there, I can work on lots of those thigns that take 5-15 minutes.  For me, I've created two key contexts that I use for work @small and @medium.  @small things are the ones I can do really anytime (when I'm at a computer -- which is almost all the time I want to be actually working).  @medium ones are the ones that take more then 5-10 minutes.  Those I actually try to schedule onto my calendar into slots that don't have meetings.  I've just started this new approach (using TaskLine to lay out the tasks automatically for me).  We'll see if it actually works.

On the negative side:

• Lower priority items can drift forever.  This is one of the things that I wanted to solve when I started using GTD.  The basic problem I have is that something gets assigned a low priority when I put it on my todo list.  And it really is low compared to other stuff.  Then I work on my high-pri items all the time.  And I have enough high and medium-pri stuff to do that I never get to the low priorities.  Which is fine and appropriate for a few days or even a week.  But sometimes these things just keep slipping out forever.  Very bad.  Maybe some way to raise the priority of things as they age?

Today I released a new build of FlexWiki.  It's got some improvements (see the list of things included in ReleaseNotes1569).  More importantly, it's the first officially mainstream build of FlexWiki with WikiTalk; WikiTalk is no longer in experimental builds only. 

I still don't have all this stuff checked in yet (yeah, I know, I need to get it done).  I also really need to write more documentation for WikiTalk...