That was the topic under discussion in the first ALT.Net talks today. There weren't that many people at the talk, but it was very focused and useful.

In general, there aren't that many ways of funding OSS projects. Note that I am talking here from the perspective of the developers who does the actual work, and how they get compensated for their time and effort. This exclude reasons such as scratching an itch, or as a hobby.

• The OSS work is useful for the day-to-day work of the developer. This is by far the more common model in the .Net world. Most OSS developers tend to do so because supporting the project supports whatever they actually trying to do.
• Reputation building - being part of OSS project usually means that you get a good reputation as a result. This can be useful in getting a job, as an example.
• Contracting / training / support. This seems to be a very common model in the Java world. There are only a few projects in .Net that are working in this approach.
• Donations - nice in theory, doesn't work in practice.
• Grants - someone who needs a feature pays for it being included. I had several leads in the past, but nothing that ever got to actual money exchanging hands.
• Work for hire - Some entity that hire a developer to work on an OSS project. SvnBridge is a good example of that. The difference between this and the previous entry is that this is not necessarily something that the dev was initially involved at.

The session was focused on two subjects, how we can increase awareness, and how we can fund OSS projects. I think that the ALT.Net community is doing a lot best practices, approaches and techniques and the tools that can be used to support those. We recently had several articles in mainstream media about from members in the ALT.Net community, as a simple example. We can do more, like reaching out to the user groups, talking more about it, doing entry level tutorials, etc. But that is more related to adoption of OSS tools, not to funding them, which was the major topic for the session.

When we are talking about funding OSS projects, we have to make a distinction in what we are talking about. We can fund the OSS project itself, and we can fund OSS developers. I feel that a large part of the session was spent making this distinction.

The major difference is in what you are trying to achieve. I use OSS projects to help me do my work, I don't need them as a source of income. They are a tool. Getting paid to work on them is fun and would be lovely, but tat is not actually something that I spend a lot of time thinking about. A lot of the suggestions that we had at the talk all involved OSS developers making considerable investment in time, money & risk for the goal of furthering OSS development.

Sorry, it doesn't work that way. At least not for me. I am getting paid to write code. Incidentally, at this point in time I am actually getting paid to write OSS code, which I consider as a really nice perk, but not something that is in any way required.

When we are talking about funding OSS projects, I am actually thinking on the other side. Funding the project itself. however, is something that I would like to focus on. The best way I know of actually getting things done is to actually pay for it to be done. Working for free works if and only if the task is fun. If it isn't, it isn't going to happen. If you want something from an OSS project, put your money where your demands are.

You want more documentation for doing X, pay for it. You want feature Y, likewise. And by paying for it, I mean anything from offering money to submitting a patch to adding to the documentation.

It is a very simple concept. And the best one I can think of.

I was a blast, I had a lot of fun, some incredibly interesting conversations, and got to meet a lot of the members of the community that I have only knew by email alias before.

We had some really good discussions today, and I got to clarify some thoughts that have been luring in the back of my mind for a while now. After the ALT.Net conf officially ended, we started hanging around, swapping stories. Somehow it got to 8 PM, I am not sure how. Roy took a bunch of us that remained to dinner at a nice place. I haven't had a drop of alcohol today (unlike the entire last week), but I am feeling more drunk than on any other day.

I would like to take this opportunity to thank TypeMock for sponsoring the dinner. It was wonderful, although I have trouble walking and / or thinking.

Doing MVP Summit and ALT.Net, back to back, is a real tiring experience.

That said, got a lot of stuff to think of, and will probably generate quite a few blog posts.

Thanks for all those who attended, for creating such a rich discussion.

Special thanks to the sponsors, Version One, ThoughtWorks, Microsoft P&P, DigiPen, DevTeach, InfoQ and CodeBetter!

Still not sure that I figure out what is going on, but I am here:

http://twitter.com/ayende

I have been thinking about this for a while now, and I am getting ready to release Rhino Mocks 3.5. The major feature is taking advantage on C# 3.0 language features. This allow some really interesting experimentation.

var mockedSmsSender = mocks.ToBeNamedMocked<ISmsSender>();
var mockedRepository = mocks.ToBeNamedMocked<IUserRepository>();
mockedRepository.Stub( x=> x.GetUserByName("ayende") ).Return( new User{Name="ayende", Pass="1234"});

new LoginController(mockedSmsSender, mockedRepository ).ForgotYourPassword("ayende");

mockedSmsSender.Verify( x => x.Send("ayende, your pass is 1234");

A few things to note about this code.

• No explicit record / replay model
• Arrange Act Assert model
• You can setup return values by using Stub()
• You can setup expectations using Expect(), with the same syntax
• More complex verification is also possible.
• I don't know what to call this new mode

As an aside, I am deprecating CreateMock in favor of StrictMock. Using strict mocks by default was a bad design decision on my part.

Thoughts?

I think that yesterday was absolutely wonderful. It did feel like I spent about 5 hours straight talking, however. The DSL talk was interesting, and gave me much to think of (and might actually kick start the book again!), great fun.

I think that my liver died at some point last night. MVP Summit + ALT.Net are not friendly to it. No time to recover.

I am the states right now, and I am thinking about giving a course in how to build a DSL or Castle or NHibernate, depending on what people want.

Right now it is likely to be in Austin or thereabout, probably at the beginning of May. No promises, and strictly based on whatever there would be enough participants.

Would you like that?

Note: If you don't know about what I am talking about, please ignore this post.

A few days ago I was in a meeting with a Microsoft team, showing a few of the MVP a new product. I was there to give feedback to the team, and I am afraid that I did no such thing. In fact, I blew up. I acted in a completely unprofessional way, and I certainly did nothing productive. I was about as unproductive as possible, and offensive to boot.

To the guys in the team, I am sorry. No excuses, I am supposed to be better than that. I certainly ought to be able to make a difference between the product and the team that develop it. I should not have tried to take my frustrations on you.

I apologize again, and deeply regret this outburst.

I was taking part in a session in the MVP Summit today, and I came out of it absolutely shocked and bitterly disappointed with the product that was under discussion. I am not sure if I can talk about that or not, so we will skip the name and the purpose. I have several issues with the product itself and its vision, but that is beside the point that I am trying to make now.

What really bothered me is utter ignorance of a critical requirement from Microsoft, who is supposed to know what they are doing with software development. That requirement is source control.

• Source control is not a feature
• Source control is a mandatory requirement

The main issue is that the product uses XML files as its serialization format. Those files are not meant for human consumption, but should be used only through a tool. The major problem here is that no one took source control into consideration when designing those XML files, so they are unmergable.

Let me give you a simple scenario:

• Developer A makes a change using the tool, let us say that he is modifying an attribute on an object.
• Developer B makes a change using the tool, let us say tat he is modifying a different attribute on a different object.

The result?

Whoever tries to commit last will get an error, the file was already updated by another guy. Usually in such situations you simply merge the two versions together, and don't worry about this.

The problem is that this XML file is implemented in such a way that each time you save it, a whole bunch of stuff gets moved around, all sort of unrelated things change, etc. In short, even a very minor change cause a significant change in the underlying XML.

You can see this in products that are shipping today, like SSIS, WF, DSL Toolkit, etc.

The problem is that when you try to merge, you have too many unrelated changes, which completely defeat the purpose of merging.

This, in turn, means that you lose the ability to work in a team environment. This product is supposed to be aimed at big companies. But it can't suppose a team of more than one! To make things worse, when I brought up this issue, the answer was something along the line: "Yes, we know about this issue, but you can avoid this using exclusive checkouts."

At that point, I am not really sure what to say. Merges happen not just when two developers modify the same file, merges also happen when you have branches. As a simple scenario, I have a development branch and a production branch. Fixing a bug in the production branch requires touching this XML file. But if I made any change to it on the development branch, you can't merge that. What happen if I use a feature branch? Or version branches?

Not considering the implications of something as basic as source control is amateurish in the extreme. Repeating the same mistake, over and over again, across multiple products, despite customer feedback on how awful this is and how much it hurt the developers who are going to use it shows contempt to the end developers, and a sign of even more serious issue: the team isn't dogfooding the product. Not in any real capacity. Otherwise, they would have already noticed the issue, much sooner in the lifetime of the product, with enough time to actually fix that.

As it was, I was told that there is nothing to do for the v1 release, that puts the fix (at best) in two years or so. For something that is a complete deal breaker for any serious development.

I have run into issues where merge issues with SSIS caused us to have to drop days of work and having to recreating everything from scratch, costing us something in the order of two weeks. I know of people that had the same issue with WF, and from my experiments, the DSL toolkit has had the exact same issue. The SSIS issues were initially reported on 2005, but are not going to be fixed for the 2008 (or so I heard from public sources) , which puts the nearest fix for something as basic as getting source control right in a 2-3 years time.

The same for the product that I am talking about here. I am not really getting that, does Microsoft things that source control isn't an important issue? They keep repeating this critically serious mistake!

For me, this is unprofessional behavior of the first degree.

Deal breaker, buh-bye.

I have been producing the Hibernating Rhinos screen casts for over a year now, and so far, I have offered them free of charge.

Estimated cost of producing a single screen cast is 3,500$ - 10,000$ each, considering the amount of planning, recording & editing that goes into them.

I am thinking about making the new episodes available for a fee, something in the 10$ - 25$ range.

I would like your opinions in this matter,

~ Ayende

Or, to be rather exact, to the MVP summit and to the ALT.Net Seattle conference.