Journal: VA's move regarding SourceForge

The other day, before the VA piece was posted here on /., I was wondering about VA's current financial situation. I headed to their website to find out what their bussiness model was supposed to be now. I had already read elsewhere that they were pushing the SourceForge backend as a product that companies can use locally and finding it prominently on the frontpage didn't come up as a surprise (FWIW, what I read last week is different from what's up there today). Their proposition maskes sense.

You are a company with a number of developers (2, 20 or 200, it's all the same) and sooner or later you are going to find yourself setting up some sort of system to improve communication among developers, to allow them to keep track of progress on different parts of the projects they work in, to allow them to find source code as well as to find out about changes (and the reasons for those changes) made to the source, and to keep track of bugs and problem reports. If you have used SourceForge in any way, you know this is precisely what SourceForge is. At the beginning SF was an awful spaghetti tied to one particular database and with hundreths of hardcoded strings hiding everywhere in the code. It has changed a lot since then and it has evolved to the point where it's very well organized and even readable. Heck, it has evolved to the point where you can apt-get install sourceforge (thaks Lolando!).

What does that mean? That means you can install your own private copy of SF and use all its power to make your development crew more productive and efficient without having to use the real thing (mostly because your copy is the real thing). Needless to say, that's a good thing for a number of reasons: sf.net might dissapear any day (more precisely, the company might dissapear any day); if all the developers of a project are sitting within a 30m radius, it doesn't make sense to make 200ms round trips to your source repository several times a day; it makes more sense for you to have all the resources related to a group of projects available locally; or, what VA pushes, your projects are not public, which means you can't host them on sf.net in the first place.

Back to my visit to VA's website, that day I found some nice descriptions about SourceForge, specially about capabilities I didn't know it had. Reading a bit further into the docs, it became clear that these extra stuff wasn't available and wasn't going to be available, it's part of VA's "enhanced" version of SF. Which is ok, it's their code, their pick their license. Even so, the fact that you'll be hard pressed to find the source code for SourceForge on SourceForge is a bit dissapointing. Yet more dissapointing is the fact that last week the website talked about "the Open Source development model". Today it says

SourceForge is the leading collaborative software development (CSD) platform for distributed software development teams

. (I'm actually happy about something: it seems "OpenSource" is suddenly a dirty word, too)

But the cherry on top of the ice cream is ESR's explanation about this proprietary version of SourceForge. You see, it's not proprietary, it's just a change in tactics, but the "stategy" is the same. He holds that the technologists and strategy people at the enterprise "get" OpenSource (Free Software is a dirty word, and they don't have to get that, I guess). The problem is the "middle managers", they don't get it. VA sales people (who, I presume, "get it") go to your company and talk with this "middle manager" people, trying to sell them installation and support services for SourceForge-on-site, and their reaction is basically "we can download and install it ourselves, why do we have to pay you to do that?". Then ESR goes to say that that line of reasoning is stupid (IOW, these people are stupid -- which ESR carefully points out you, or the sales people, shouldn't say to them) because it's clear that VA people are experts on this stuff and it makes sense to pay them to get SF up and running at your site in a reasonable ammount of time (which I agree with). The solution? Make some part of SF proprietary and sell that. "See? You can't download it! Pay us!".

Who's to blame? The economy, of course. Since it's hard times for everyone, Big Company won't contract VA to install SF at their place because they can save money by making some local people do it instead. In other words, all that crap about "selling service, not software" he's been spouting for some time is just that, crap. What should I, Joe R. Hacker, do? I'm building my little consulting service arround that very model. I have this nifty piece of "OpenSource" (Free Software, actually) that everyone can download, but there's some functionallity I haven't implemented due to lack of time, same functionallity that Big Company wants to have. We start talking about it and we decide Big Company is going to pay me to develop it is a reasonable timeframe plus a consulting contract to provide them with support for some period of time... is ESR telling me that that doesn't work? That I should remove the source from the net and start selling it? Is that it?