It's a recurring theme. The relationship between the .Net developers community, the community leaders, Microsoft products, and Microsoft itself is an endless debate.

These last couple of weeks I've seen it come back again, strong, with the usual rants, departure notices, and rebuttals (which are getting fewer and further between).

The Microsoft .Net User Group Leaders

I run a small .Net UG in Chicago and when I have a chance to talk with other user group organizers, no matter how truly dedicated and valuable they are, I invariably come to the same sad conclusion.

The majority of the UG's act as mere outlets for showing off introductory talks on whatever is the shiny new technology from Microsoft. I wonder if all user groups have a clear (or even unclear) mission statement.

There's nothing intrinsically wrong with providing 100-level content about new products. The problem I see is that this doesn't really contribute much to build any kind of community and we can't make our UGs be restricted to just that.

In many UGs there's a lot of emphasis put in "Microsoft" and ".Net" but almost none in "User" or "Group." I think this is completely backwards. The UG leaders should have their focus on their members 100% of the time, thinking how the UG can be used to truly benefit their members, making all of us better developers, not just better .Net developers (Microsoft or ALT) and much less better MS developers.

The .Net Developer Community

We all know this community isn't exactly like other developer communities. I'd even go out on a limb and say that the use of the word community is a bit of a stretch, it's more like a demographic.

We grew up simply waiting what comes out of One Microsoft Way and attended MS-produced events and conferences. I think there are very few occurrences of organically formed community manifestations in .Net, like the Code Camps and ALT.NET.

That's something that can't be changed by just talking about it. As community members there are things we could do.

• Look for developer events even if you weren't forwarded one of those MSDN emails (there's Community Megaphone, Meetup, EventBrite, just to name a few).
• Attend non-MS user group meetings. Seriously. If you're a web developer, look for a JavaScript or Flash UG. If you're curious about the Windows Phone, check out the iPhone and Android users groups too. There's a lot to learn and much networking to be done.
• Attend Code Camps, even if costs you a small road trip. There's no way you'll ever regret doing this.

We will only be a community when we start acting as such.

Microsoft

At least in my region Microsoft does a very commendable work in trying to connect the .Net developers with non-.Net ones. More and more I see MS interested in leaving the community organization to community itself, providing some level of infrastructure, access to good speakers and sponsorship when possible.

I'm not convinced MS knows how to measure the health of .Net communities. For me, even looking from MS' standpoint, a successful community is one where a novices have easy access to experts and where knowledge and opportunities are exchanged. It doesn't matter that you have tens of thousands of .Net developers in your region if you don't know where to find them for a question or business proposition.

Microsoft Products

Like any other technology company, Microsoft releases products that range from tremendously successful to niche applications to complete failures.

We can never dispose of critical eyes when analyzing a new product. The community members invest their time when attending meetings and events. We need to always demand perspective in addition to purely technical content.

Here I want to draw the line and separate developer tools from core technologies. As a developer I'm ok to be seen as a consumer of developer tools, like Visual Studio and Blend, but when it comes to the platform technologies, like IIS, SQL Server, Azure, Silverlight, etc I much rather be treated as a coworker that is trying to create high quality software with these products. Forget that there's money to be made by both of us in this process when we talk about core technologies.

Can we fix this?

I used to be more optimistic about this situation. I still hope we can stir the will to participate, produce, and consume all things .Net.

The one thing I know for sure is that I won't sit and watch until it happens. I try to do the tiny bit I can but I like this stuff too much and I have no problem in carrying my energy over to another platform.

But the question stands — Is there a way to make it work?

After a successful first Chicago Code Camp last year, we're back to announce the second edition of this unique technical event.

The Chicago Code Camp 2 will happen on May 1^st. In this event we are addressing one obvious and recurring feedback: Make it closer to the city.

We're thrilled to announce that our Code Camp will take place at the IIT Campus, just South of downtown Chicago, easily accessible by car and public transportation.

What is the Chicago Code Camp?

Just like last year, we want to host an event where any platform or programming language can have its space, as long as there's community interest in talking and hearing about it.

The code camp is a great opportunity to learn about and network with developers of different walks of life and technologies. Last year we had diverse topics such as .NET, Python, iPhone, Ruby, XUL, JavaScript, Scala, etc. We hope to have even more this time around.

To ensure the numerous technical communities are fairly represented, we are inviting all local technical community leaders to get involved and provide speakers and attendees.

The event is free to attend but everyone needs to register. Registration will open soon Registration is open and it's limited due to the venue capacity.

Call for Speakers

The Chicago Code Camp website is up and ready to receive talk proposals.

The Code Camp Manifesto calls for sessions that privilege code over theory or slides, but it doesn't mean a good presentation will be immediately turned down because of that.

Stay tuned

We will have more exciting news and announcements to share about this event. We will do so as soon are they are confirmed.

Keep an eye on the website (or this blog) to learn about registrations, volunteering, and getting involved.

I haven't mentioned our meetings here in a while but our group has been going strong and enthusiastic all this time.

Tomorrow, March 10^th our topic will be build scripts for .Net projects using Rake and Albacore. I've been using Rake and a little bit of Albacore in my own projects and I'm ready to say that it will take a very serious event to make me go back to NAnt or MSBuild.

Introduction to Rake with Albacore.NET

6:00 pm
Pizza and networking time

6:30 pm

How would you to write your build scripts using a scripting language instead of XML? In this month's meeting we will see how the ease of programming in Ruby can be used to create a much more pleasant and extensible build script.

Rake isn't just for Rubyists or Alphageeks anymore. Albacore helps bring the power and expresiveness of the Ruby language to the world of .NET build automation. Using Rake it's never been easier to handle build automation, test execution, continuous integration and just about any task you need to automate for your build.

Michael D. Hall has been developing software on the Microsoft platform for over a decade. He's been an Alt.NETter for years and is really enjoying the exposure to different ideas and concepts beyond the safe confines of the .NET world. Currently he's a consultant working with Obtiva and has started a Cloud Developer's Group that meets monthly in McHenry county.

There ALT.NET bashing season is on full steam. Ian Cooper has a thorough post about it.

To my recollection, ALT.NET was formed by people that shared very similar tastes on what represents good development tools, practices, and methodologies. This group of people, just by the simple fact that they decided to get together under one roof to discuss these ideas, showed that they are constantly and decidedly trying to become better at what they do.

But when you take the step to form a new community or movement (or whatever else you want to call it) you can't easily control who jumps on board or who jumps ship - and you shouldn't even try to.

Inevitably the original idea started to attract many different kinds of participants, which I'm going to roughly distribute in the below four categories (I was tempted to use the term personas, but … never mind.)

1. I'm here to help
   
   • I like to teach,
   • to write,
   • to contribute to OSS,
   • coordinating UGs and events
2. Those who like to complain
   A very minor percentage of those know how to externalize their criticism in a constructive way. Unfortunately the majority limit their contributions to rants and trolling.
   That's probably the only group of people that I'd try to weed out if I could (but I can't; and we shouldn't).
3. Those who want to learn
   
   • They want to hear about other ideas,
   • to figure out how to bring better practices to their work,
   • they have a specific problem and they're seeking opinions or answers.
4. Heliotropic migrants
   The ones who want to be linked to (and hops on) every new, shiny thing for commercial reasons. There's always this type of people. They need to latch on to what could be the next big thing for the sake of their own livelihood. There's nothing wrong with that, by the way.

Some people just can't put up with the other types. Some folks go ballistic with people on #4, others can't stand the whiners in #2. Some don't tolerate repeated or trivial questions from folks that are just trying to learn.

In the midst of all this, it becomes hard to connect #1 and #3, which I think is the ultimate reason for ALT.NET existence.

Frankly speaking, I think I've personally danced around in all these four categories but I find myself most of the time in #3 and some other times in #1. I do apologize for my ventures in #2 – it's hard to avoid.

So, if you dabble in the ALT.NET waters, let me just ask you to exercise a little bit of patience. We all still have a lot to learn and there's very good indications that some of those lessons are permeating the .NET development community — from the individual developer to the big Enterprise, Inc.

Let's no try to change the world with a single swing of the bat. Changing one constructor method at a time will get us further. In the end, the idea is simply to more efficiently produce more maintainable and reliable software.

Last Saturday I had the pleasure to present a JavaScript talk at the Iowa Code Camp. The talk was Stop Programming JavaScript By Luck and it tries to highlight some of the most puzzling differences from your mainstream programming language (read: C#, VB, Java.)

I'd like to thank all that came to the talk and the Code Camp organizers for inviting me. Here are the video recording and the slide deck.

The video

And the slide deck.