Weekly Edition
Return to the Front page
| |||||||||||||
Ten-year timeline part 3: The Tucows years
This is the third installment in a ten-year retrospective inspired by LWN's
tenth anniversary; those who have not yet seen them may want to have a look
at Part 1 and Part 2. At the end of the
second part, LWN had just emerged from the peak of the dotcom bubble having
made a deal with Tucows. For almost two years we operated as a part of
that company; here's some highlights from that time.
Needless to say, by this time we were happy to have found a relatively stable place to be - times were starting to look a little tough. Between the end of the Linuxcare IPO - once supposed to be the biggest and best of them all - and the fact that other Linux companies had fallen below their initial prices, it seemed that the honeymoon was pretty well over. By this time, LWN's revenue stream from advertising had pretty well dried up too. Red Hat's embedded business is a classic case of a lost opportunity. The acquisition of Cygnus should have placed Red Hat in a strong position in this sector, but, somehow, it all slipped away.
One might think it cynical and mean-spirited to point out that we're still waiting for Wine 1.0. But we'll do it anyway. The memory management issues with 2.4 were to be with us for some time, as it turned out.
Given that the 2.4.0 release was far overdue, one would think that arguments over whether a completely new filesystem should be added would be considered out of place. But they did happen, with Hans Reiser showing a level of anger and paranoia that put much of the community off of dealing with him for years. It is rare that kernel developers are accused of putting corporate interests above those of the kernel as a whole, but that happened here. It is actually worth reflecting on this a bit: kernel developers work for roughly 200 companies, many of which are direct competitors. But that competition has remained almost entirely absent from the development process. We are very good at developing common resources in a highly collaborative way while competing at different levels.
Something which was widely understood, but little talked about, during this time was the great amount of effort VA Linux put into recruiting projects to SourceForge. It was a clear effort to become the home for as much software as possible. Quite a few prominent projects moved over with great fanfare, only to drift away more quietly later on. SourceForge still hosts a great many projects, but it is seen by many now as a home of last resort.
Lest anybody think that the dotcom silliness was truly over by this point, the CueCat story should convince them otherwise. Digital Convergence spent many millions of dollars sending around free barcode scanners on the idea that people would want to swipe codes from advertisements and be taken to the associated web site. This company considered using the scanner for any other purpose to be a violation of the DMCA, and made loud threats at people distributing drivers which enabled such uses. The company's threats came to nothing, but they foreshadowed the DMCA follies to come.
The Red Hat Network was the core of what was to become the subscription services which support the company so nicely now. Back then, though, that outcome still was not clear, and Red Hat continued to experiment with a number of business ideas.
Many people had begun to worry that 2.4.0 would never come. The story of the development of this kernel, though, was not done yet.
By this point, things were looking downright scary. During the bubble days, almost anybody who wanted to work in free software development could get a job somewhere. By this point, though, quite a few people were without jobs and some of them were leaving the community altogether. The Stanford Checker was a GCC derivative which could do static analysis; for many, it was the first real demonstration of what that kind of tool could do. Despite some early reassurances, this code was never released; instead, it was used to found Coverity. The community has benefited strongly from Coverity's work, but imagine what we could have done with the source to the Checker. It is a little sad that we have been unable to develop similar capabilities in free software.
The threats against Ed Felten - who had participated on a contest put on by SDMI proponents - were a strong signal that, in the U.S., the DMCA could bite developers hard. Worse was to come, though. Meanwhile, Eric Raymond's attempts to "hack" a rather unimpressed kernel community provided a steady stream of comic relief.
Your editor has said previously that Eazel's plan never seemed (to him) to make sense; the investors finally came to the same conclusion and pulled the plug. Another plan which did not make sense was what had happened to MandrakeSoft: outside managers placed in the company by its venture capitalists had decide that Mandrake should be an e-learning company - not exactly its area of core expertise. That strategy just about destroyed MandrakeSoft before the decision to go back to its distributor roots was made. The company has taken many years to recover from that mistake.
In these difficult days, the fact that Red Hat could produce a profit - even a tiny one - offered a ray of hope. The failure of VA Linux to make it in the hardware business was a sobering counterexample, though, given that VA was once the most prominent company selling Linux-installed systems.
More than anything else, the arrest of Dmitry was a wakeup call for the community. It seemed that, in the U.S., any developer could be arrested for interfering with the business plans of large companies. As a result of this action, some developers still refuse to travel to the U.S.
We still miss Liz - but she remains a good friend.
Few people remember September, 2001, as one of their favorite months. Beyond the terrible events occurring in the wider world, the problems in the commercial Linux sector just seemed to get steadily worse. The 2.4.10 kernel release is an important point as well. Here is where the longstanding memory-management problems came to a crux; Linus responded by ripping out the 2.4.9 VM code and replacing it with a completely different implementation. What followed may be the closest we ever came to a fork in the Linux development process. Some distributors stayed with 2.4.9 for a long time - RHEL 2 systems (still supported by Red Hat) are still running a kernel which, at least, claims to be 2.4.9. The worst passed, however, and this is the point at which 2.4 started toward something resembling stability.
Tucows, which had not been helped by having launched a major new offering on September 11, laid off a number of people, including Michael. His desktop columns had been a welcome addition to LWN, and his departure was a big loss.
Initially the Mandrake Club was meant to function as a sort of tip jar. As financial problems at MandrakeSoft got worse, though, it became the storefront through which the Mandrake distribution was sold. Not everybody liked how the Club was run, but it doubtless helped MandrakeSoft to survive into the present.
The indictment of Mr. Johansen made it clear that DMCA-like problems were not limited to the USA. Meanwhile, by this time, Tucows had come to terms with the fact that its acquisition (and ongoing operation) of LWN was not helping it, given the directions its business was taking. So, after some discussion, LWN was unacquired - it was given back to its creators, with Tucows holding on to a small piece just in case. The parting was on the best of terms; it revalidated our decision to go with Tucows in the first place. But, after almost two years, it was time for LWN to venture back out into a scary world as an independent business. That was the beginning of a new phase, with its own ups and downs, which will be discussed in the next installment. (Log in to post comments)
Sourceforge Posted Jan 24, 2008 10:51 UTC (Thu) by johnny (guest, #10110) [Link] Slightly OT, but what is it that makes Sourceforge a "last resort"? I'm not asking because I feel a need to defend SF or anything, it's just that I want to know what I'm missing out on when I'm using SF (SF is the only site if its kind that I've used) instead of an alternative. In short, what are the alternatives, and in what ways can I expect them to work better for me than SF does?
Sourceforge Posted Jan 24, 2008 12:21 UTC (Thu) by epa (subscriber, #39769) [Link] The alternatives I most know of are Savannah (a Sourceforge clone run by the GNU project; your app must run on a free OS) and Google Code (pleasingly minimalist interface, but you must have a gmail login to participate). There are others.
Sourceforge Posted Jan 24, 2008 14:14 UTC (Thu) by net_bh (guest, #28735) [Link] There is Launchpad by Canonical.
Sourceforge Posted Jan 24, 2008 16:42 UTC (Thu) by tzafrir (subscriber, #11501) [Link] There's also http://berlios.de/ . Use a gforge as well. Had both and subversion and a wiki long before sourceforge had it. Generally less reliable than soruceforge.
Sourceforge alternatives Posted Jan 24, 2008 15:16 UTC (Thu) by TRS-80 (subscriber, #1804) [Link] Website and source hosting and bug tracking are commodity items these days - most of the major projects (e.g. GNOME, KDE, Samba) self-host. Sourceforge only got SVN a few years ago, while DVCS eliminates much of the need for an always-on central source repository. I've always had a special hate for SF's bug tracker, even Bugzilla is better, and its mailing list archives are horrible as well, despite being run on Mailman. Smaller projects can often find a hosting provider tailored to their needs - mozdev, freedesktop, RubyForge, Alioth, or even run their own trac install on a $10/mo shared host. The wikipedia comparison of free software hosting facilities only compares supported VCS, but gives an idea of the breadth of options available. It's been a long time since SF was the only source hosting game in town, but its features haven't kept up at all.
Sourceforge Posted Jan 24, 2008 15:16 UTC (Thu) by roblatham (subscriber, #1579) [Link] Some of sourceforge's problems relate to just how many projects they host. For a while in 2003-2005, for example, the CVS servers were just not reliable. They've addressed that. For a lot of projects, it's not a big deal to register a domain and host your own mailing lists and defect trackers. Maybe that process was more difficult back when bugzilla was all we had, but now we've got RT, TRAC, and a bunch of others. We've got SVN but also a ton of distributed revision control tools. Plus, as other comments have said, there's more than sf.net today. ==rob
Sourceforge Posted Jan 28, 2008 10:32 UTC (Mon) by KotH (subscriber, #4660) [Link] Back in the days, SF was unreliable. I don't know the exact reason but i suspect that they acquired more projects in a short time frame than their servers could cope with. The result was that their cvs server was more down than up and mails took at times over a day to be delivered over the mailinglists. The cvs issues were mitigated a bit by introducing a commit only cvs server for developers and a second read only one for all the users. Although this made development more reliable for the developers, the problems remained for the users and they got the additional problem that commits would take a day to be visible to them. As a result of these problems, first MPlayer and not much later FFmpeg moved to their own server. At that time it was interesting to see, that after FFmpeg moved their cvs repo to the MPlayer server, SF's cvs server became quite a lot faster. It might be coincidence, but still funny to see. I don't know whether SF still has these problems, i haven't used it for a very long time. But i guess that they got enough hardware and a proper scalable framework to cope with it these days.
Sourceforge Posted Jan 29, 2008 0:14 UTC (Tue) by jd (guest, #26381) [Link] Reliability issues - it had an amazing amount of downtime at one point. Sourcecode secrecy - the source was supposed to be released, but barring one early snapshot, it never was. The loss of the build farm came later, IIRC, but that made life far harder. Mirrors were often out of sync, so you had to hunt-and-peck to see where the updates were. Everyone could see uploaded files (they still can), which means any project can "steal" files from any other project until completely set up. Mailing lists are partially outside Sourceforge, so Sourceforge users can have a hell of a time resetting passwords. The mailserver on Sourceforge was unreliable, so mail sent to your Sourceforge account routinely vanished into nowhere. Oh, and the space available made quite a few projects tough at best.
Ten-year timeline part 3: The Tucows years Posted Jan 24, 2008 22:34 UTC (Thu) by aegl (subscriber, #37581) [Link] Interesting that you pick 2.4.10 as the point at which "The worst passed, however, and this is the point at which 2.4 started toward something resembling stability." since it was followed by the infamous "2.4.11-dontuse" release ... perhaps the only DOA kernel in Linux history :-)
Ten-year timeline part 3: The Tucows years Posted Jan 25, 2008 17:23 UTC (Fri) by cde (guest, #46554) [Link] Heh :-) I remember moving from 2.2.x to 2.4 with the 2.4.15 kernel, which too had a major filesystem corruption bug. This bug was triggered when unmounting a filesystem with "dirty" inodes. They released 2.4.16 just after to correct this single bug, but didn't mark 2.4.15 as dontuse.
Ten-year timeline part 3: The Tucows years Posted Jan 29, 2008 20:51 UTC (Tue) by Felix.Braun (subscriber, #3032) [Link] 2.4.11 ate my hard disc :-( I still feel the pain. In all the years that I've been using Linux this has been the only time that I've lost data due to anything else than my own fault :-)
RFC 1149 Posted Jan 25, 2008 4:05 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link] May 10, 2001: EBIZ cancels its acquisition of Linux NetworX. The Bergen Linux Users Group implements RFC 1149.I couldn't find either ``RFC'' or ``Bergen'' in that issue. For anyone else who is dying to know about the work, check out http://www.blug.linux.no/rfc1149/writeup.html.
|
|||||||||||||