Let’s say, just for the sake of argument that the standard bits are perfectly safe. I know there still a couple of concerns there, but put them aside for this point.

In Special

One of the things we are hearing is that mono will be clearly split into “standard” and “non-standard” bits. That’s great. Another thing we are being told about the non-standard bits is that ”nobody cares about those – they aren’t used for the apps people moan about.”

But: Banshee needs System.Data and SQLite. F-Spot needs System.Data and SQLite. I believe both of these use ADO.Net, and are in the “non-standard” bits camp.

I would suggest that Banshee and F-Spot are very much “apps people moan about.” (The other two that are hot are Tomboy and Gnome Do, which look alright in this area based on my understanding.)

In General

The problem here I’m seeing is two-fold:

1. The Community Promise has made parts of mono safer. That’s great.
2. Some people might not be clear that this is not a blanket over all mono. That’s not so great.

If mono proponents want mono critics to acknowledge the Community Promise is a positive step, they need to be honest about its limitations.

If applications are using non-standard bits of mono, it would not be honest to promote them under the argument that “well, everyone knows mono is safe now.”

I want to make this point strongly because we have lots of email showing that Microsoft internally, and a high levels, discussed a strategy along the lines of only standardizing enough of .NET to make it look good, but not enough to make it actually useful.

If major mono-based applications – the ones people are pushing to get into distributions by default – rely on these non-standard bits, then the arguments for them are not much affected by the Community Promise and they need to remain optional.