Slashdot Mirror
SourceForge Drifting
Zocalo sent us a story running at FSF Europe talking about SourceForge's Drifting. Talks about the fact that they are releasing a closed-source version of the code commercially and various copyright related things. Obviously VA owns both SF and Slashdot so I'm skewed, but my personal opinion is that VA is doing what they need to do to make a buck while still providing the SourceForge.net website to the Open Source community. And I think their decision to sell a closed-source proprietary version of the code would be hypocritical, except that they aren't a 100% open-source company any more. And *that* is the part that makes me the most sad.
I would like to point out that despite what's said in the drifting piece - Sourceforge.net does run on Free software. Sourceforge 3.0 Enterprise Edition has non-free components to it, the major part being the access into Oracle.
Yeah, I'm that guy.
Step 1: Start an open-source based company
Step 3: Profit!
Apparently Step 2 is "completely change the business model of this corporation so that it may actually make money."
Bitter pill to swallow, but giving away IP just doesn't work.
Considering that no one is exactly sure if VA can make it as a business selling proprietary extensions to Source Forge has anyone thought about what will happen to Freshmeat and Source Forge if (or is it when) VA goes under?
I know that a couple of projects have started mirroring their Source Forge content in case anything happens but are there any credible replacements being worked in case both these extremely useful sites lose their their parent company? Specifically are there any sites that are viable replacements to either Freshmeat or SourceForge? Currently we have multiple Linux distros so the death of one, two or more companies in that area would be sad but not devastating on the other hand the dissappearance of VA considering how much of a central repository for Open Source apps SourceForge and Freshmeat have become would be devastating.
If people out there take serious issue with Source Forge's turn to the proprietary, then take the last release of open source code and start your own Source Forge. I mean isn't that supposed to be one of the magical things about open source, that folks who want to go proprietary cannot because the community will hijack it.
Of course if you want to set up your own Source fFrge you have to have the money to run all of the servers, bandwidth, etc. Don't have the cash? Well I guess that's what Source Forge was running into as well.
Personally I think that Source Forge being open source itself was cool but rather secondary to the fact that source forge provides a great place for people to collaborate on projects. If they have to close the source to make it financially feasible to continue to provide the service, so be it. Which would be worse for the community: Source Forge running on proprietary software or Source Forge shutting down?
Unless the FSF is going to fund an open alternative to Source Forge they should get off their high horse.
This sig has been temporarily disconnected or is no longer in service
Note that the FSF, which does like all things free, is more concerned about the possible GNU GPL violations that might be occuring, and "appropriation" of contributors' work. While I'm not an GPL-junkie, this does seem to be a valid point from the FSF, with SF walking a thin, grey line.
People I work with have been in contact with VA regarding deployment of SF Enterprise Edition...
The cost comes out to ~ $300K/year for 900 users... Not very economical, expecially considering I have an 80% functional install running off of the last (GPL'd) release - v2.61
my $.02
After visitng linuxworld and drilling their sales reps we came to the conclusion that Sourceforge can't compete with free alternatives. (by 'we' I mean the software Co. I'm working for)
Bugzilla/bonsai/tinderbox provides a more complete solution. We were even able to modify the trio to deal with java, our many different build scripts (make is rather lacking for java), and our test automation.
What we found was that Sourceforge provided discussion groups which we got using exchange or INND, bug tracking which wasn't nearly as feature rich as bugzilla, and cvs integration which bonsai provided just as well. It was still lacking the automated builds, and by the time they got back to us after linuxworld we had allready deployed the bugzilla solution (partly thanks to some nice debian packages put together by Remi Perrot).
One large drawback is that bonsai relies on glimpse as its fulltext indexer. Glimpse used to be free but since then has gone commercial. We were, however, able to find some old glimpse source (which may have been GPL or artistic license - perhaps we should redistribute the old code as GNUlimpse).
We have made our own tweaks to bugzilla/tinderbox/bonsai and contributed a few of them back to the mozilla developers (in the future probably all will be recycled into the public implementation).
I see some posts from people who are basically asking, "What's the big deal? They're just doing what they need to survive."
The fuss is that for the last few years ESR et al has been CathedralBazaaring (if you'll pardon my verbization) this idea that Open Source software actually makes MORE economic sense than closed source software, because you get the benefits of the "community". Source Forge has basically rejected this idea, and said "screw this ivory tower theory, it's not working and we need to make money".
I'm not ready to declare the experiments a total failure. I believe Stronghold does pretty well with their commercial version of Apache (not sure though), and IBM is certainly putting a lot of effort toward open source. Of course, IBM is hoping to sell hardware, so it's not quite the same.
In fact, ESR has been pretty quiet lately. Considering he was a board member of VA, has he put out any opinions on this move to closed source? Has he resigned from the board?
Sometimes it's best to just let stupid people be stupid.
My name is Patrick McGovern and I manage SourceForge.net. I wanted
to take a moment to address the issues that Loic raised in his
recent article.
As a background: SourceForge.net is a website within the
Open Source Developers Network (OSDN), owned by VA Linux Systems.
SourceForge.net provides free hosting for Open Source software
development projects via its web site at http://sourceforge.net
and http://sf.net
SourceForge.net, OSDN and VA Linux systems are committed to the
Open Source community. Two years ago (almost to the day)
SourceForge.net was started to provide a way for Open Source
developers to collaborate with each other and make great software.
This mission has not changed. Today VA spends a tremendous amount
of money and resources to provide excellent service to 30,000 projects.
Loic brings up a number of points that are simply not accurate.
* SourceForge (not SourceForge.net) is a collaborative software
development platform. The SourceForge software originated as the
foundation of the SourceForge.net service, and is now the basis of
a number of products offered by VA Linux Systems. SourceForge
Enterprise Edition is the commercial product released by
VA Linux Systems last week. SourceForge is a software platform.
* SourceForge.net is a service provided freely to Open Source
software development projects. SourceForge.net is not running
the SourceForge Enterprise Edition software. SourceForge.net is
a web site, which provides a service to the Open Source community.
* SourceForge.net provides free hosting for Open Source Software
development projects. SourceForge.net is not now, or nor has it
ever been, exclusive to free software -- we accept hosting requests
from projects licensed under any OSI-approved Open Source License,
and projects whose licenses have not been directly approved,
but comply with the OSI Open Source Definition.
* Data Export: The ability to export data from SourceForge.net
has not changed. There is no conspiracy to 'lock projects in'
to SourceForge.net. Every project has the ability to download
a nightly tarball of their CVS code. If people have any concerns
about their code, we recommend they set up a cron job to download
the latest version. Eight months ago we did have a XML API that
allowed project admins to download bug report data. The API broke
earlier in the year when we enhanced the SF.NET code (version 2.5)
to include the tracker (a tool that unifies all 'ticket-related'
systems). Until recently, we didn't receive a lot of interest from
the community to re-introduce the feature... so we have been focusing
on other aspects of the site. We are now re-examining the issue.
In the mean time, there are third-party programs which will collect
the content directly from the site and extract that data.
* Mailing Lists: One area we concentrating on, which Loic alludes to,
is mailing list archives. This, historically, has been one of the
weakest areas of SourceForge.net. We are currently working on a new
solution, which directly integrates the mailing lists with
SourceForge.net, as opposed to Geocrawler. We have just entered the
initial beta phase for this project. It is still being worked on,
but you can see it here in action:
http://sourceforge.net/forum/?group_id=27464 (look at the last
four forums). We are essentially using the SourceForge Forum code;
the same code base that has been available to the community for
some time.
--
Developers are choosing SourceForge.net because of the excellent
resources and service we give the community. The site is currently
growing at over 60 new projects and 700 developers a day. We just
added new personnel and purchased 70 new servers to make sure we
retain our excellent quality of service. We have added new download
servers to make sure the community can get Source code as fast
as possible. We have been adding additional hardware to
the compile farm. (OS X systems were added last month).
Finally, SourceForge.net is a free service. It's a service I believe
greatly enhances the Open Source Developer's ability to write and
release great software; and have it seen by a lot of people. If you
feel that SourceForge.net is not for you, that is okay too. There are
alternatives out there, and it's better to host your code where you
think you will be the most productive.
If you have any questions or concerns, please feel free to write me:
pat at sourceforge.net
Thank you,
Pat-
Patrick McGovern
email: Pat at SourceForge.net
Director, SourceForge.net
I'm not the first to mention it, but this bears repeating: this isn't a sign of VA * abandoning their ideals; they are doing the best under the circumstances. It's really a sign of them struggling for their lives in a hostile environment.
The recently posted their quarterly income statement, and my analysis is that it looks very bad. They posted a net profit of negative $290 million. Most of that is imaginary money, so let's look at the rest of the figures to get an idea what is actually going on.
To project the long term viability of the company, we will look at the burn rate, and try to extend that against their short term assets, accounting for any factors that will change their revenues or expenses.
The balance sheet shows that their current assets continue to drop. Particularly disturbing is the continued drop in cash and equivalents and short term investments. These have gone down by about $17 million, indicating that as their burn rate. Inventory has also decreased, presumably as they sell off what remains from their hardware business. This provides a revenue stream that has basically finished this quarter. Since the $8 million drop there is about half of the total revenue, we can expect revenue next quarter to be about half of what it was this quarter.
Long term assets are also dropping. Reductions in long term capital are likely due to exiting the hardware business and getting rid of associated facilities. They are also writing off huge amounts of goodwill and intangibles. Neither of these is important, since the money was already spent and does not affect their long term viability. The only thing to note is that the poor economy now means that the money spent acquiring these assets is not giving much of a return, and they would have been better just sticking it in the bank.
Although their liabilities are increasing, they do not explain why, categorizing the increase as "other liabilities". We can't factor this into any calculations directly.
It appears that the current burn rate is $17 million per quarter, against reserves of about $97 million. With revenues expected to fall to half of the $16 million they are now once the remaining hardware inventory is sold, we expect the burn rate to increase to $25 million. At this rate we can expect the company to survive four quarters, just one year.
In that time frame, there really isn't anything that we can expect to make them viable. Revenues from SourceForge On Site will likely ramp up, but that will be a slow process that can not offset much of the projected loss. Further, aggressive cost cutting measures will reduce the burn rate, but it is unlikely they can cut it enough to survive long, particularly with the conflicting goal of building the SourceForge brand and ramping development and sales.
I really don't see a future for VA. Look for them to sell off unprofitable assets (likely including Slashdot, unless the changes Rob discussed can make it profitable). Developers with projects on SourceForge should make offsite backups just in case they remove it suddenly and don't give developers sufficient time to withdraw their code. Think also what the rush on the site will be when they announce its closing and everybody tries to checkout their projects at the same time.
Even Slashdot wants to hide some things
The following post isn't meant to be a flame. I'm just sharing what I knew to be true about my own experiences with VA regarding System 12, the embryonic form of what later became SourceForge. Hell, we even came up with the name "SourceForge" back in May of '99..
To quote from the article:
Finally, VA Linux[1] has become rather underhanded in their attempts to grasp exclusive control of contributors' work.
What sold VA on our idea, originally, was that the company was ultimately going to be in a position to assert a great amount of influence over the design of people's apps in the end. In the months prior to System 12's inception, I was asked by Trae McCombs to provide what amounted to a "proposal" he could hand to the people calling the shots, to justify setting up a box for us and others on the team to work with. The details of that proposal went something like this:
System 12 was going to offer "components"... Nice bits and pieces of graphics, sounds, and code that could be fused into pre-existing Linux apps, and perhaps more importantly, used to build new ones from scratch. The idea was to make the Linux developer community dependant upon System 12. Originally, the primary benefit of this was that all Linux apps would have had a similar behavior and appearance, and i'm sure we'd all agree that such a thing was good--But later, a more interesting benefit emerged, in that we (as System 12) and VA, as our parent, would be able to dictate how people were to develop their apps by controlling the components these apps relied upon. We didn't want to view the project that way -- Asserting control was a secondary benefit. VA viewed it as a primary benefit.
Needless to say, Management at VA apparently liked the idea. They liked it enough to set up a dual P3/500 with 50GB of space on it, sitting on a wide open T1. An enormous machine by 1999 standards.
Essentially, VA would have been able to express their desires as a company via your apps. To this day, VA views SourceForge as a tool to advance the interests of the company. Suppose your code relied upon a component provided by System 12. At any point, VA could alter the structure of that component so as to make your code behave nicely with VA-produced software (ala Internet Explorer & Word), or more amusingly, run a banner ad at the bottom of your apps. This was our idea, and its the idea we sold VA on. System 12, the base predecessor to SourceForge, was designed to exert a measure of control over the direction of Linux application development, SO AS TO BENEFIT THE COMPANY. We wanted to become powerful enough as a central development resource that VA would have some interest in hiring us on as permanent employees versus community volunteers. That never happened. We got shoved off the map before we knew what hit us.
Rather than letting us continue development, they essentially co-opted us, and put pre-existing VA employees on the task of developing the idea. "Grow the garden to attract the bunnies, then lock the gate to the garden and sell rabbit meat." The gate got locked a month or so ago when VA announced they're moving SourceForge into proprietary waters.. Soon, (if not already) VA will trying to co-opt those who participated in the garden. I tried to warn you guys, but nobody listened. I got called insane instead, for suggesting VA had something other than purely altruistic motives. I used to be just as big a flag waver as you when it came to VA, but I learned my lesson fairly early on in the game. I'm afraid the rest of you are just now getting a taste of the same lesson we learned.
To milk the community for the gain of the company was part of the plan from Day 1, folks.
You would be VERY wise to move your project and your work off of SourceForge as soon as possible.
Bowie J. Poag