Large FLOSS Study Gets the Real Facts
Hans Kwint writes "The European Commission's enterprise and industry department has just released the final draft of what could be the biggest academic interdisciplinary study on the economic / innovative impacts of free/libre/open source software (1.8-MB PDF). The study was done by an international consortium led by the United Nations University / University of Maastricht. The lead researcher, Rishab Aiyer Ghosh, has overseen a large volume of FLOSS studies in the last few years, including ones on FLOSS policies and worldwide FLOSS adoption. This academic-grade study has a very broad scope and has collected real-world information that is valuable for both companies and government bodies thinking about migration. The study is about the economic impact of FLOSS, not excluding the hidden indirect impact. It compares scenarios of open and proprietary software futures of Europe. The study looks at the FLOSS's competitiveness compared to proprietary software and also provides a few TCO comparison case-studies.
a slashvertisement here, but it is of topical interest: I am putting together a peer-reviewed journal issue on the ethics of floss - the deadline is past, but the panel will still consider papers. see the link in my sig. please contact me via the link if you have any interest.
I don't think you can compare a discussion about whether to use FLOSS or not with whether to believe in "intelligent design" or not.
Unlike with the Open Source issue, believing in evolution or not does not matter. No matter what you believe how the world was born, this will not change the past, and it will certainly have no influence on the way you work.
The benefits of Open Source are nothing you can discuss about once the research has been done. And so far we are only talking about those objective business figures. The whole subjective part of it has only been covered in a handful of books, Eric S. Raymonds "Cathedral and Bazaar" being one of it.
Now this is entirely subjective, and needs to be backed up by objective research, but I'm confident I'm not the only one:
I am 26. I started programming when I was 9. For 15 years, I was exclusively using non-free products. Since I switched to working with open source products 2 years ago, my productivity has boasted. I have more work-related contacts than ever. I participate in various projects. I learn so much every day - about programming, and especially about working with other people. Because of those contacts, I get inside scoops and information that in non-free terms would be regarded as "classified". I feel that I shape myself into someone who will be able to do quite good consulting one day. I can safely say that my knowledge has never grown this fast.
Now show me anyone who can claim the opposite: "I used free software for 15 years, now I switched to non-free software, boy my productivity sky-rocketed! And I know so many people now!" - in fact, try to twist arguments and see if the shoe still fits. I can not see free software going away, and I can not see longtime users migrating back to Windows.
This is not a question of religion. This is a question of performance and optimal work flow.
Do not trust this signature.
Well, if you look at the document properties what do you find? It was created with PScript.dll under Windows. :-/
I hope they have learned their lesson from their study themselves...
Ohne Worte
Figure 12 claims FLOSS systems used in European public bodies (900 bodies across European Governments):
46.6 % GNU/Linux
33.7 % MySQL
33.4 % Apache
26.0 % Mozilla
24.1 % PHP
21.5 % OpenOffice.org
17.0 % Samba
14.1 % Squid
10.2 % KDE
10.2 % Perl
05.5 % Gnome
04.7 % Zope
03.0 % Free/Open BSD
33.9 % other
Reading stats on open source makes me wonder whether there is some equivalent to Moore's Law that applies to expansion of the open source code base.
If you're on the commercial side of an open source company, it is imperative you read this report.
This report answers bucketloads of questions about where to approach the market and how to do so. It also provides clear impartial metrics which you can present to decision makers and strategy people at your customers. Miss this at your peril.
29 mpg. YMMV.
Now this is all very good. (Until you realize it's always the same people and it's more about networking, the money and the jobs involved). Except, again, they never ever put money into development. To me, this is shameful, all these people going after the money and getting it, and not a single eurocent to what should be the first priority if you're giving away money. But they don't have to - that's not the point. Just start USING open source and stop talking about it/studying it for once, because it's a make money quick scheme, and don't waste tax payer's money on for example 286 page studies.
Je fume. Tu fumes. Nous fûmes!
To be honest, when I first saw the line, I also wanted to make similar post.
But then - just before hitting "Reply to This" - I recalled all the nightmares of supporting M$Office documents my company have had in past. All the bugs and regressions of OO.o cannot cover experience with M$Office in networked environment.
Our favorite biggest sucker is M$O document with global system architecture spec: opening from network drive of the 20 page (about 200k thanks to diagrams) document takes 2 to 5 minutes. Always. Nobody knows what M$Word does - but it basicly hangs and then later happily pop-ups from background with open document reporting neither error nor warning. Copy the document from networked repository to local harddrive - and it opens instantly. Open it as it is supposed to be open - and locked - on servers and ... here we go. (Actually we also have several document which take ages to open regardless of where from you open them: locally or remotely. But it just everybody has to work with sys arch spec often - so it is major P.I.T.A.)
OO.o is bloated, ugly, slow, feature-poor, buggy and inconsistent. Its macro language is total and utter undocumented crap (N.B. I hate VBA - no language could be worse. Or so I thought. Before I have seen StarBasic (or whatever that thing is called)). BUT. In three years of deployment we found no single major blocker, which prevented us from using OO.o internally.
All hope abandon ye who enter here.
There's a business opportunity out there, migrating users to Open Source, and somebody is set to coin it in.
"I want to totally own you. I want to hold your data to ransom, and if you don't keep paying me, I will make it unreadable. I want to force you to upgrade your software and your equipment when I say so. I will send my hired goons around when I feel like it, just to make sure you're behaving yourself, and if I so much as suspect you're even thinking of doing anything I don't like, you'll pay" really isn't much of a sales pitch, and the only reason anyone falls for it is they don't know there is an alternative. Well, ignorance is curable.
Start by recruiting a bunch of school leavers, all of whom must hate Microsoft with a passion; just put "Send CV - NO MS WORD DOCS" on the advertisement. And mean it. You'll need one or two machines running Windows and Office; but these will be on a private network, air-gapped from the Internet, so no need for anti-virus/anti-spyware. Files will be transferred from the Linux machines on this network to the rest of your network by physically transferring hard disk drives. One of your staff must be absolutely fluent in some distribution; and it's best if you have at least one expert from each side of the deb/rpm wall.
Document conversion isn't the problem you imagine it's going to be. Most of any user's old documents only occasionally ever need to be looked at, maybe reprinted, but probably not edited. So first off, archive all those legacy documents as PostScript files. (Emulating a standard JetDirect print server is as good a way as any of doing this.) You can (and should) gzip or bzip2 the files to save space, since none of the standard Linux file viewers mind about compressed files. In the course of doing this, you will identify those documents which might conceivably need to be edited and can begin prioritising. You will also, in all probability, run into a situation where a newer version of Microsoft software has trouble with a file generated by an older version of Microsoft software. If this happens, milk the sucker.
Now work on replacing existing Office macros. This will come as a bit of a shock to the Windows power users, but: Many customers don't actually use macros for much, because they simply don't know how to. It's not uncommon to see people cutting and pasting between Word and Excel, or even dictating from a screen to another person at another terminal. And don't just go for straight work-alikes: look at the bigger picture. If data is coming in regularly by e-mail and normally gets handled by some contrived manual process, you want an end-to-end solution, beginning with a procmail recipe, that will do the whole thing automagically. "As good as" is not good enough. You have got to do better.
Some documents will need to be recreated from scratch by hand in order to render them editable. This should not be overlooked. Slightly less drastic than retyping everything is transferring as plain text, then recreating the formatting -- which doesn't take long if done properly. Don't forget you have the Postscript "reference renderings" to work against.
If you can get a foot in the door with a business that has recently been raided by FAST (and they don't suspect that the raid had anything to do with you), so much the better. Just convince them you can convert them to 100% FLOSS for half what they'd be expected to pay for licences for the proprietary stuff they're using.
Je fume. Tu fumes. Nous fûmes!
Having exstenisve experience in industry and academia, I can tell you that when it comes to software, 'acadmic grade' means 'the bare minimum to get a publication'. It can also mean 'something industry developed years ago, didn't publish, and was just rediscovered by a grad student (e.g., Grid->Web Services)'.
Anyway, snide comments aside, what really worries me about this study is that the applications cited as the most used are server applications and development tools (with the exception of OpenOffice). These are tools that matter to developers, not end users. To conclude that all software should be open source essentially screws everyone who is not a developer.