“It makes me really sad to have so many friends and family members who are highly technical and opt not to use Fedora. I know many Fedora contributors whose families use Windows, OS X, or other distros. I feel very strongly this is a problem.”

This is absolutely key. Fedora has to have a role, and I think to often the “<x> isn’t stable” and “stuff is breaking” arguments get batted away with “This isn’t RHEL/CentOS”. Without being strongly usable for something, fewer people will be tempted to use it.

So I would like to make my technical feature plea, along similar lines to the comments about updates. Right now, Fedora revs extremely often, and isn’t supported for long. Yet, the major version upgrade story is really pretty sorry – even with preupgrade. It’s not straightforward to upgrade to a new version and quite often packages will break.

If we’re keeping up this pace, I think it should be much more incumbent on Fedora as a whole to make major version upgrades clean and easy. Packagers should be testing this constantly. I saw figures recently about versions of Fedora being pulled by yum updates, and it didn’t look pretty reading. If Fedora is about being “First” we have to bring users with us.

I’ve been testing this over the past few hours with a new package: SparkleShare. For those who’ve never heard of it before, this is essentially a little tray app that synchronises a local directory tree with one held on a remote server: you can think of this as being very similar to Ubuntu One, Dropbox, iFolder or similar. However, what’s interesting here is that this is built on top of git: so SparkleShare essentially automates the commit and pull/push process, handling it invisibly for you, while still giving you a pretty solid system underneath.

Now, SparkleShare isn’t really ready for Fedora itself yet – it’s still under a large amount of development, there are funky bugs in it now and then, and it’s likely going to change constantly. However, it’s also useful software already, and is something I want to try out on a number of my machines, so the new people-based repos were the obvious candidate.

If you want to try it too, you just need to enable my new SparkleShare repo:

Recently a new system has been added to people.fp.o, the ability to host yum repositories. It’s not an equivalent of Ubuntu’s PPA system by any stretch of the imagination, but it’s another useful facility to have available.

I’ve been testing this over the past few hours with a new package: SparkleShare. For those who’ve never heard of it before, this is essentially a little tray app that synchronises a local directory tree with one held on a remote server: you can think of this as being very similar to Ubuntu One, Dropbox, iFolder or similar. However, what’s interesting here is that this is built on top of git: so SparkleShare essentially automates the commit and pull/push process, handling it invisibly for you, while still giving you a pretty solid system underneath.

Now, SparkleShare isn’t really ready for Fedora itself yet – it’s still under a large amount of development, there are funky bugs in it now and then, and it’s likely going to change constantly. However, it’s also useful software already, and is something I want to try out on a number of my machines, so the new people-based repos were the obvious candidate.

If you want to try it too, you just need to enable my new SparkleShare repo:

sudo curl -o /etc/yum.repos.d/fedora-sparkleshare.repo \
    http://repos.fedorapeople.org/repos/alexh/sparkleshare/fedora-sparkleshare.repo

And then you can “yum install sparkleshare”. Fedora 13 and i386 only right now – I’ll have x86_64 builds up later today, and I’m going to be doing Fedora 14/Rawhide as soon as I can get builders up for those two.

However, even though it’s are the “barely walking” stage it is actually doing useful things, so hooray! If nothing else, I already have a system to back-up my phone contacts working, and in maybe another week or something I’ll have something pretty awesomely functional which I can take on the road. Plus there’s no reason why shared contacts/etc. won’t be sync-able, which is even more awesome.

But there is a black lining to this cloud. Z-Push, although it seems to be reasonably well-developed and commercially backed software, has a problem: ActiveSync is pretty heavily patented in the US, and it requires a license to develop software which uses the protocol. Hence Google buying a license for the protocol to cover Android 2.2 and above, where the support will be native.

This doesn’t pose much of a problem for us as a project: there’s really nothing in the back-end as designed which would be infringing on anything except good taste. However, it’s also totally useless without Z-Push, and as it stands it looks unlikely that Z-Push will be entirely “clean” for USA-based users and developers to try any time soon.

I’ve really been dabbling with this to scratch the personal itch of being able to sync contacts and events on my phone, and so far it looks like that will be straightforward. I can’t help feeling a bit guilty though…

One of the problems we’ve had is that working on a number of pieces of the system, including the backend and web front ends, has been difficult – both parts are in development, and having everything subject to change like that it pretty difficult. On top of that, the web parts we were bequeathed from Hula just don’t work well and ideally want to be restarted with a modern JS library underneath.

So, we’ve agreed to take a slightly different short-term path: initially, we’re going to ship a version of Roundcube as our mail client. Yesterday, I demonstrated some of the work that Lance and I had done to this end, which comprises a skin for Roundcube (based on the Dragonfly design and assets), and a Bongo plugin based on the PHP bindings we developed as part of the Dragonfly-NG project. As well as the standard IMAP and SMTP support, then, the plugin connects straight to Bongo and pulls through your address book – as well as your own, you can also access shared address books on the server. This all works right now and is pretty useful.

The direction we’d like to take this is to continue the development of these additional parts to make Roundcube as good a Bongo client as we can make it; including:

• calendar access;
• server-side rules, signatures and vacation settings;
• anti-spam training;
• removing dependencies we’re not interested in (SQL being the obvious one).

It will be interesting to see what extent we can do this within the existing Roundcube framework; the plugin API doesn’t seem sophisticated enough quite at this point. However, the intention is definitely not to fork the project: where we can’t do things within the plugin, we’ll need to see if we can put forward proposals which are more generally acceptable to everyone – making Bongo-specific core changes would be pretty easy, but really not the road we want to go down.

The initial version of this plugin and various other bits of code are available in the Bongo-Web project on Gna!. The intention here is that we will release this concurrently with Bongo, so the two pieces fit together well: we will also be developing an separate administration tool to sit along side this.

What this means for the future web development is unclear at this point. It’s still possible we would take forward our own client development in the future, but that isn’t something we need to think about at this point: and even if we did, it would still be advantageous to maintain good support for Roundcube users in the future.

The company I work for moved offices recently, and this also set me thinking about Thunderbird again as we update our e-mail systems. As well as an update breaking one of the add-ons we rely on, there are still basic features missing from this mailer which we need as a business, and doing things like adding good-looking signatures to e-mails is bizarrely difficult and user-unfriendly.

We’re also in the position of still running on Thunderbird 2. We’re there because it’s a reasonable little client, but Thunderbird 3 is not: it comes with bad defaults which need to be switched off, and the search is irritatingly difficult to manage. Every now and then I search and rather than the useful folder filter I get the craptastic separate search tab, which doesn’t work because I’ve turned off Gloda.

Thunderbird 3.1 is supposed to be an easier upgrade for Thunderbird 2 users. Two problems: first, I don’t really believe it, and second, there are now no new Thunderbird 2 releases planned. So we’re now on an unsupported product with only an upgrade to a product we’re unhappy with available.

What would moving to Thunderbird 3 involve for our organisation? Well, primarily, it’s a support issue. We’re distributed (as well as having an office), so we would need to be giving users some kind of training so they could support themselves on the new software (avoiding all the inevitable “Where has button X gone?” type support calls), and ideally we’d want some distribution mechanism so we could control the setup of Thunderbird for our users. Of course, no such stuff is readily available – you can’t even buy it from Mozilla Messaging, the business set up to develop Thunderbird. This seems unbelievable to me; we can’t be the only business who’d be willing to pay for a business-ready Thunderbird distribution.

It’s now getting to the point where we will be making decisions. I can guarantee that we will be testing Evolution on Windows, to evaluate its suitability as a cross-platform client. My misgivings about this before have again centred on commercial support and reliability: however, Evolution has a much, much better business story, a clear development roadmap and solid history of releases.

Evolution would also be an easy sell to our users with the enhanced address book and calendaring support. It doesn’t look amazingly Windows-native to me, but that’s potentially a quite small problem – the main thing is testing it’s reliable.

I would have never thought Evolution would even have been a contender on Windows, but to be honest if we’re not in a position to receive commercial support for either suite, the choice becomes a lot more interesting – and obviously for our Linux users, it’s stable and has a great integration story.

Before I start talking about what’s new, I will just say putting the Alpha on a USB key to test it went wrong in quite a big way for me. Eventually I used ‘dd’ to get it on there, but livecd-iso-to-disk is just totally busted for me – I had all sorts of problems. I have a horrible feeling that the “does not destroy data” feature has been totally broken by the current Linux kernel support for vfat long file names. By the by.

But look what’s coming. Nouveau support – already good – is getting better, with some optional 3D acceleration you can turn on. With a good wind blowing it seems that for many people this support will be pretty good. NetworkManager – already good – is getting better, with signal strength meters for 3G users such as myself and Bluetooth DUN support. Lots of little things like this make a difference.

It doesn’t stop with the small things, though. SSSD will be turned on by default. For some people, this will mean nothing. For enterprise users of Fedora like myself, it means we can setup our laptops to authenticate against LDAP when on our corporate network and it will continue to work when we’re off the network. It seems a decent new feature to me.

There’s also automatic printer driver installation for local printers, and the supremely awesome http://boot.fedoraproject.org/ – slightly technical features I guess, but certainly making the lives of people installing and using Fedora much easier.

And, of course, Fedora 13 comes with GNOME 2.30 as standard: probably the last release before GNOME 3. It’s the usual bouquet of small touches, and combining the improvements to Evolution, the updated OpenOffice.org and the SSSD feature I think this is probably the first Fedora release you could truly call an enterprise desktop.

What’s your favourite Fedora 13 feature coming down the pipe?

What is oData? Put simply, it’s a bit like being able to do SQL queries over the web – for non-technical people it’s deeply disinteresting, but what it effectively promotes is an ability for web-based services to open access to their databases in a pretty straightforward and standards-compliant method.

Now, there is some commentary that this is effectively trying to subvert another set of standards, RDF, OWL & SPARQL. I have to say up-front that I don’t see the comparison particularly: they’re similar in many ways, but also quite different, and I personally think they are more complimentary than competitive. However, the people who specified oData are Microsoft – so the “anti-competitive” label is one which sticks easily. It’s a lazy criticism in my opinion, but that’s up to the commentator.

More serious is the problem Miguel raises: while there are a number of free software oData consumer libraries available already, there are limited options for producing oData services. This is a major issue. As relatively light-weight as oData is, it’s still a pretty broad specification: your service needs to be able to produce both XML and JSON, and there are particular schemas and URL structures you have to follow. I’m tempted to start to write an oData producer for PHP, but it’s likely to be a lot of effort for not much immediate gain.

Another problem I’ve seen is that authentication and authorisation is basically not mentioned at all; the nearest we get is in section 8 of the overview:

“The Open Data Protocol does not define a new scheme for authentication or authorization. Instead, implementers of OData services may opt to use the authentication and authorization technologies that fit best with their target scenario.

“The use of authentication mechanisms to prevent the insertion or editing of resources exposed by an OData service by unknown or unauthorized clients is recommended but not required.”

This is a particular problem for me, because the immediate itch I have that this could scratch would need authentication. If one oData service uses HTTP basic auth, and another uses a cookie-based system, that’s an issue – it hinders interoperability. In a way, I understand why they did it – it’s a somewhat orthogonal issue, and once you start prescribing features like that there’s no logical reason to prescribe other HTTP features like if-modified-since, but it does seem to me to be a pretty key issue. Not all data wants to be public.

All that said, I’m planning on digging deeper into oData. It’s extremely interesting, and I think of large potential value in the future – and being honest, there is nothing else like it immediately available. The JSON format alone is of huge value, since it means that browsers can access all this data immediately. There’s just a fair amount of work for it to become useable…

Slightly more depressing than all of these, though, are the plans put forward for 2010. Development for 3.1 seems to be about making updates from 2.x less painful, and making some of the features better – all things which 3.0 should have been, in all honesty (upgrading from 2.x to 3.0 has put a number of people I know right off Tbird, to the point they’ve switched to something else). The plans to put Thunderbird on an economically sustainable footing also look staggeringly underdeveloped: Mozilla Messaging has been around since September 2008, and from the look of it there is still absolutely no vision about how this is going to happen. What is going to happen is a series of “experiments”, but it’s not really clear to me how you can judge the potential of a business model on that basis.

My specific worry about this is that by trying a series of experiments, they’re basically going to do a prototype-y half-assed version of each, none will work, and the whole thing will come crumbling down. This is specifically why businesses do market research: they test the market before they develop the product, rather than put effort in a direction which isn’t going to be successful. More than this, ideas for development of Thunderbird have been terribly unexciting so far: more experiments in the “web 2.0″ direction may be interesting for some people, but I struggle to see how people are going to pony up for any of this.

There has also been seemingly no effort to bring into the core the crucial Thunderbird feature which pretty much everyone clamours for: the Calendar. Yes, the plugin exists, and yes it’s pretty good. But in all honesty, there is absolutely no way on earth I would deploy that setup in a business right now with Tbird auto-updating itself, because at some point something will go wrong on update and people’s calendar plugin will stop working. So either I turn off updates, or I don’t use the plugin, and the balance doesn’t weigh in favour of the plugin.

Joe Brockmeier has written some thoughts of his own on the economic future, which involves basically setting up as a mail service for people to use Thunderbird against. I would worry it’s a little bit late in the game for that; businesses willing to pay for that kind of thing already have plenty of options available to them and it’s difficult to see how Mozilla Messaging can add significant value in that area without carrying horrendous costs.

My take: personally, I would want to see them focus on deployment and management of Thunderbird. Specifically, that means some kind of management system for Windows-based networks, whereby I can control updates, configure accounts, control user’s settings centrally, etc. That’s something critical to broad deployment of Tbird in large organisations, and doesn’t really exist right now. It would also be something worth paying for.

Whether or not enough “things worth paying for” can be created, though, is an open question. Fundamentally, there is a problem with giving away the client for free: it is a development cost, and in order to recoup that cost you have to create value in ways which wouldn’t be possible without the client. Every business model that doesn’t rely on that client being available for free as leverage doesn’t recoup the cost, it shoulders it. And that is the fundamental problem facing “open source business models”.

To reprise some of the facts in the reports;

1. BBC News mentioned “a sophisticated and targeted” attack, but then later says that Google pointed the finger at phishing and malware scams rather than security problems.
2. The reports are that Gmail accounts were mainly targeted, and these Gmail accounts were of known dissidents.

Now, 2) is quite believable, but 1) is not at all. Phishing and malware is nothing new, there’s not a lot you can do to stop it, and it’s certainly not sophisticated and targeted unless the Chinese Government was intercepting legitimate Google traffic. Even then, with SSL, that’s a difficult proposition.

Wikileak’s twitter account added a couple of other suspicions:

1. “China has been quietly asking for the same access to google logfiles as US intelligence for 2-3 years now.”
2. “Gossip from within google.cn is Shanghai office used as CN gov attack stage in US source code network.”

With this kind of affair, it’s usually instructive to consider the adage of Cui bono. Sure, Chinese intelligence probably could use more information about dissidents and would probably like log file access and things like that. Almost certainly they try to access gmail accounts too. I have little doubt that Google would have immense trouble detecting this from the more general problem of phishing, and to that extent it’s really not their problem – it’s a social engineering problem.

There is a far larger prize at stake, of course. If Google source code is under attack, which seems reasonable, this presents two major issues. The first, that Google code could be used by China: there is the issue of straight-up rip-off, which devalues Google at the very least. However, Google is already #2 and is well behind Baidu, the native search system. There is motivation to do this of course, but it’s not exactly the biggest prize on offer.

The larger prize is access to code to work out security issues. Google does not develop code in the open, and while most of it is probably secure there are doubtless issues that a determined attacker could find more easily with access to code. And, once you start getting access, you start being able to gain the stuff of real value: the information stored on Google’s systems, in Gmail, in Google Docs, in Postini, as well as the various logs and other behavioural data associated with advertising.

Put like that, Google simply cannot afford to work in China. In one sense, China is lawless: there is a certain class of “criminal” who is state-sponsored and therefore can do as they please. There is no good technological defence to this, there is only the question of whether to participate or not. And what are the potential costs of participating? Essentially, limitless. Major US and EU firms on Google Apps will not want their business information readable by the Chinese authorities. More than that, firms doing business with other firms using Google Apps will not want their information readable too.

On Facebook, I gave the example of Jaguar Land Rover as one company who use Google Apps for everything. Will they like the idea of the Chinese authorities being able to see what they’re up to? No. Even if it’s not happening, it will put the wind up them: potentially, it could destroy their business. And lets remember, there are now millions of businesses on this platform.

This highlights one danger of cloud computing: not only do you have to trust the provider, but you also have to trust that the aggregation of data in one place doesn’t become a sufficiently juicy target for someone else. And Google is a very, very juicy target.

Let me speculate further on a few potential issues in the future (none of which are problematic at this point today):

• Google controls large amount of “dark fibre” and “private internet”. That’s a juicy target.
• Google are putting Android into many handsets. Yum, yum, another juicy target!
• Google maps / street map / other raw data. If, somehow, the collection of data could be controlled by another agent – well, that’s quite a useful tool to have.

This doesn’t even go into the potential issues of having hardware controlled by another agent in your data centre or in your phone, which isn’t outside the realms of practical possibility for the Chinese Government either.

Let’s be clear about this: all Governments have secret services, and the Chinese are by no means the most adept or technologically advanced. However, they may be the most dangerous and the most likely to work clandestinely. Google must know already that they have spies working for them, not just in China but in all their major offices. Most good industrial espionage is internally undetectable, because it’s acquired information out only. The Chinese spies clearly have been up to many detectable activities, which puts them in a very different class.

Update: Wired has a very good article up with more details about the attack. In short, there was a specific piece of malware targeted at Google to pull their source code out of the organisation. It doesn’t say what, but it does say that the large amounts could be sent and doesn’t say how quickly they detected in. Which is exceptionally scary. I would have thought the Windows-based attack would limit the scope of what could have been lifted, but this doesn’t explain many of the other rumours about Google’s Chinese offices, and doesn’t (on its own) explain Google’s seeming decision to withdraw. Possibly, Google were attacked in other ways too.

So, what are the problems? Jason from “MonoNoNo” gave his thoughts here. While I disagree with much of his analysis – e.g., the Media Pack issue is essentially irrelevant for free software users, and the GPLv3-hate is also basically not a problem – many of the points raised are valid. I don’t think they make Moonlight non-free itself, but they prevent people re-using the code, which is not ideal.

I also raised the issue on fedora-devel-list, and received a somewhat limited reply from Tom Callaway. The commentary on what lawyers are willing (or not) to do is relatively interesting, although I don’t think is entirely apropos. It would be simple for someone to say “these permissions are the minimum that we need” regardless of any specific license, which I haven’t seen anyone do with respect to patents. It’s not a huge step to go beyond that and check off whether each permission has been properly granted.

That all said, I think there are a few key issues here:

1. Versioning. I haven’t seen anyone else discuss this, but the Covenant is issued for versions of Moonlight which do not yet exist as far as I can tell. So in one sense, all of this discussion is basically moot.
2. End users vs. distributors. I don’t understand why the Covenant attempts to differentiate these cases, but it does seem to put people such as Red Hat in a situation where they are specifically not covered. Why? This just seems mad.
3. End dates are not far in the future. This isn’t going to instil confidence in people relying on these agreements.

Unless those issues are sorted out, it seems pretty clear to me that Moonlight is not going to get into Fedora. Of course, there are plenty of people who do not want it in either way, so the effort that might go into fixing these problems is likely to be less than minimal.

It’s sad for a number of reasons: first, because it would be something that I think is easy to fix. Microsoft, if they are serious about Silverlight, could issue a covenant which covers Moonlight properly, without the silly restrictions and time limits, and prove to people that they want it to succeed so much they are willing to give up control of who can implement it.

Second, because Silverlight is technically extremely appealing. Free software players for Flash are not great, and the development tools are terrible. HTML5/SVG/JS etc. is in a similar position; the “players” (browsers) are much better quality (although the user experience is variable) but the development tools are non-existent. And Moonlight is not the only Silverlight implementation on the way: apparently Intel are also working on a completely different implementation.

I doubt anyone from Microsoft reads this blog, but they are the only ones who could fix this. I’m surprised they don’t see the value in doing it.