User: Password:
Subscribe / Log in / New account

Leading items

A green light for free-software defined radio?

Playing around with radio-frequency transmission and reception used to be restricted to those of us with hardware skills. That has been changing for some years, though, as processors get faster and software techniques advance; now, many radio transmitters and receivers are built with simple (but flexible) hardware. The hard work of generating the signal to be transmitted is done in software. Some wireless network adapters work that way now, as do a number of other devices. There is a well-advanced project - GNU Radio - which enables experimenters to do amazing things with software defined radio (SDR) systems.

A potential problem with such devices is that users could, perhaps, modify the software and cause the radio to operate in ways which are not compliant with local spectrum-use regulations. Regulatory agencies tend to frown on such use - and on manufacturers which make it easy for their devices to be used in non-compliant ways. Fear of this sort of tampering is one of the excuses given by wireless adapter vendors for not releasing free drivers for their devices. It has also been an occasional concern for Linux distributors who include free drivers. In general, the combination of SDR and free software has long been the cause of worry and fear, and that has slowed progress on that front.

The Software Freedom Law Center has made an attempt to address that fear by doing an analysis of the U.S. Federal Communications Commission's regulations with regard to the use of free software in software-defined radio systems. The resulting white paper is a bit of a challenging reading experience (it may be clearer than the FCC regulations, but it still reads like legalese), but it is probably worthwhile for anybody who is concerned about the interaction of SDR and free software.

The white paper starts by looking at the scope of the FCC's regulations with regard to SDR systems. It is noted that many such systems (a wireless router, for example) contain full Linux distributions within them. Almost the entire distribution, however, is unrelated to the device's radio functionality and, thus, is not subject to FCC regulation. Any device software which does not interact directly with the radio is unregulated and can be free software.

Next, the SFLC points out that, by its reading, the FCC's regulations only apply to device manufacturers. They do not, in particular, apply to independent software developers. This conclusion is important: it says that distributors who ship free drivers for SDR devices are not bound by the FCC's rules unless those drivers directly operate the radio in non-compliant ways.

The down side is that manufacturers of software-defined radio devices really cannot provide free drivers if those drivers could be modified to enable non-compliant operation. The FCC expects that the security measures within these devices will be implemented in a way which resists casual tampering, and it has been clear on its worries that implementing those measures in free software will not yield a sufficiently robust solution. So, if the hardware can be easily programmed to do non-compliant things, it looks like the FCC expects the driver which programs the device to be a non-modifiable binary blob. The SFLC notes that the door is not entirely closed, and that a vendor which can demonstrate sufficient robustness with a fully free-software implementation could still get certification. But it would not be easy.

The white paper concludes this way:

The SDR rules promulgated by the FCC represent a positive development for FOSS developers working in the wireless space. The rules allow FOSS developers not affiliated with device manufacturers to continue work on their software without restriction. They allow SDR manufacturers to employ FOSS for most of the functionality of their devices, and they leave open the possibility that a device using a purely FOSS-based software platform could also pass FCC certification if it managed to demonstrate the soundness of its security strategy.

It may be a positive development, but only to an extent; as long as the FCC is saying that SDR devices must contain binary blobs to be certified in the U.S., we will not have complete control over our devices.

One should note that this document only discusses U.S. regulations. The FCC is certainly a prominent regulator, and its decisions have worldwide impact, but it is not the only regulatory body out there. Every country has its own rules, and some of them have regulatory agencies which are rather more nervous than the FCC; people who have studied the issue often note that Japan can be a very bad place to play loose with spectrum regulations. So, while a partially-green light from the FCC may be somewhat comforting, it's really only a small piece of the larger problem.

Spectrum use and regulation is an important issue; it will have an increasing impact on our ability to communicate freely as time goes by. Improving software techniques promise to open up the spectrum in interesting ways, making it possible for more bits to be carried in ways which are difficult to intercept or interfere with. It has been argued that, as a result of improving technology, the need (and justification) for heavy-handed regulation is fading, at least over broad parts of the spectrum. The success of WiFi shows what can happen when even a small bit of spectrum is freed; imagine what could happen if the full innovative power of the free software community could be unleashed on flexible, software-defined radio systems. That is why any progress toward openness on the SDR front is a good thing, even if it remains far from what we really want.

Comments (20 posted)

Pointy-haired kernel hackers?

Don Marti attended Greg Kroah-Hartman's Linux Symposium talk on the kernel development process; he wrote an informative article (titled Linux contributor base broadens) about it. The article states:

In the latest kernel release, the most active 30 developers authored only 30% of the changes, while two years ago, the top 20 developers did 80% of the changes, he said. Kroah-Hartman himself is now doing more code reviewing than coding. "That's all I do, is read patches these days," he said.

An important part of this is that Greg presented this change as a good thing. The kernel has a far broader developer base than it once did, with patches for any given release coming from almost 1000 different people. We have a growing development community which is healthy and robust.

Seeing what the mainstream media makes of things can be great fun sometimes. This time around, ComputerWorld UK picked up Don's article, running the same text but giving it a new title: Are top Linux developers losing the will to code? Slashdot picked it up under that title, then Wired chimed in with Core Linux Developers Stuck In Middle Management Mode, complete with a picture of a necktie-wearing employee wielding a stapler and a telephone. The prize must go to the Jem Report's The coders and the talkers, though; this article breaks new ground completely:

Linus' [sic] job is leaning more towards spokesman than programmer. He's been a relatively effective manager up until now, but I think that effectiveness will begin to erode rapidly with time. The further you get away from the actual work, the less you are able to accurately judge the appropriateness of other people's work. You need to stay in the game -- you need to keep your skills in condition. If you don't, you might understand the theory pretty well, but you'll get further and further away from being in touch with its application. Linus has become more of a talker and less of a coder.

It seems we have trouble here. While we weren't looking, the Linux kernel drifted into a Dilbertesque realm and is now controlled by people who don't actually create software anymore. World Domination, it would seem, is now in grave doubt.

Or perhaps all of this is just silly nonsense, an extreme extrapolation taken from a couple of sentences spoken at a Linux developer conference.

If one wanted to investigate this subject further, a good starting place might be the 2.6.22 changelog; there one can see just how many patches our pointy-haired top-level maintainers have contributed over the latest development cycle. Here's a subset:

Andi Kleen 70
Andrew Morton 79
David Miller 193
Greg Kroah-Hartman 14
James Bottomley 13
Linus Torvalds 20
Russell King 61

One could add more names to the list, but the end result would be about the same: the top-level kernel maintainers are not among the most prolific contributors (except maybe for David Miller - but, then, he's an exception in many regards), but neither are they absent from the game. They are still hacking on the code and cranking out the patches.

From some of the articles that have been posted, one might think that subsystem maintainers spend the rest of their time attending meetings and writing weekly reports. What they are actually doing is working with patches - lots of patches - and with developers. A subsystem maintainer must review code, decide whether it is appropriate for the kernel, and, if not, give the developer guidance on how to make it better. Incoming patch streams must be merged together, and decisions must be made on which ones are ready for any given development cycle. It is a task which requires the maintainers to keep their hands deep in the code. Subsystem maintainers who do not touch the code, and who do not maintain a deep understanding of how the kernel works are not likely to remain maintainers for very long.

So the broadening of the kernel development community - and the associated need for more work by subsystem maintainers - is not really costing us our best developers. They are not "losing the will to code." The things that cost us developers are elsewhere: a somewhat adversarial process which turns off some people, general burnout, or getting a job which takes their attention away from contributing to the community. All very normal stuff. In the Linux kernel community we may have our share of Dogberts, but we need not lose much sleep over the threat of pointy-haired subsystem maintainers bringing the process to a halt. Instead, they have helped the kernel development process to scale to a level beyond that of almost any other software development project anywhere; that is a good thing, not a sign of trouble.

Comments (9 posted)

An interview with Matt Asay

July 6, 2007

This article was contributed by Glyn Moody

Matt Asay (pronounced "ay-see") studied law at Stanford University - Larry Lessig was one of his professors - before he joined Lineo, a pioneering embedded Linux company. He later moved to Novell, and then to his current employer, Alfresco, which produces open source enterprise content management software. He also founded the Open Source Business Conference, and writes an influential blog called The Open Road. Glyn Moody talked to him about why he became a GPL believer and how to create a billion-dollar revenue open source company.

How did your work with Larry Lessig come about?

I had what started off as a summer internship at Lineo, and I loved it almost from day one. It turned into a full-time job which I continued doing for the last two years of law school. [Larry Lessig] was teaching a class "open sources", and I thought: "Well, I work for an open source company; surely I'm qualified to take the class."

I read his book [Code and Other Laws of Cyberspace] and thought it was fantastic, and ended up in this class with him, where I found out that he was much more persuasive in the book than he was in the class. In the class, all of these grand-sounding things about freedom and whatnot, and how good it was for the industry, didn't sound as good to me when I was trying to make a living selling the stuff: Lineo went through the first year of being just phenomenally successful, to the second year of collapsing.

At the time, what I was hearing was: "This open source software is great. Everybody loves it." And the "everybody loves it" was true, but that didn't translate into people paying for it, at least in my experience. And so I had a fundamental disagreement with him that open source had a long future ahead of it. When you can only rely on the developers to scratch their itches, and their itches may not be the itch of these big companies that buy software, how could open source have any sort of a future ahead of it?

And so we just battled constantly. But that turned into a grudging respect on my part. I wanted to write my third-year paper on open source licensing. He agreed to be my adviser for it - which sounds better on paper than it was in reality, because he was traveling like a madman and so I never actually got to see him.

In that paper [pdf], there's this mea culpa, where you effectively say: "Well, actually I've decided that I was wrong about the GPL." What made you change your mind?

I recognized that my experience at Lineo was maybe atypical for the industry. I hadn't encountered enterprise software yet. I just didn't know that that would be a different beast, but it turns out it is. In the embedded world, developers rule. Developers are happy to sustain themselves and to support themselves. In the enterprise world, for whatever reason, they'd rather save time, and spend some money. In the embedded world, they were happy to save money and spend time on the code. I think it was watching Red Hat more than anything else: Red Hat slowly proved that you can make money in open source.

How did you come to work for Novell?

While I was still working at Lineo, I contacted somebody that I had had to lay off, and said: "Will you come back? We need you back." And he said: "No, I won't, but will you come work for me at Novell?" I was just coming up on graduation, and [it] says something about how rocky the last few months at Lineo were that Novell actually looked like a stable place to land.

My initial job at Novell was trying to get hardware and software companies to support Netware, which you can imagine was a somewhat thankless task. It was about that time that I said: "The one thing that I know is interesting is open source." That's where I had just come from. So I went to our potential partners, saying: "Well, Netware is not very interesting, but Novell and Linux are." At the time, a lot of Novell's applications or infrastructure ran on Linux, such as eDirectory. So that became my story, going around talking about how they should support Novell's Linux story, even though Novell, aside from running some of its applications on Linux, didn't really have one.

I was probably one of three people in the company that had any understanding of open source, and any desire to do anything there. Fortunately, one of those three was Chris Stone, the vice chairman. In December 2002, when the Linux Business Office was formed, he asked me if I would be part of that. It was designed as a group to advise him and push the company toward open source. The unfortunate thing is that there were a lot of people that had been there for ten, fifteen years. There were people who just dug in their heels and said, "No, our software is better and our technology is better. Surely they'll realize that Microsoft technology stinks." They just didn't get it.

While you were at Novell, you set up the Open Source Business Conference (OSBC) in July 2003: what you were trying to achieve with that?

OSBC was born out of the frustration that I had with both Novell and Lineo, and played out in class with Lessig: how do you make money on this stuff that everybody thinks is so great? If it's so great, surely somebody would pay money for it, and if we could get people to pay money for it, there would be a lot more of it.

I was coming back from LinuxWorld or something, I was sitting with a friend, complaining to him about this great open source stuff that nobody knows how to make any money on. I said: "You know, I should do a conference on this, get all the smart people together." And he said: "Well, do it."

So I contacted the two people in open source that I knew had money - Jason Matusow at Microsoft and Dan Frye at IBM. They both committed $30,000 to it. So, yeah: the interesting little fact with the Open Source Business Conference is that the first person to give money to it was Microsoft.

Did you decide to leave Novell or to join Alfresco?

I decided to leave Novell about a year before I left Novell. I was still fulfilling my Novell duties, but thinking strategically in a vacuum. I started talking with a range of different open source companies; over the course of a year, I think I must have met every single open source company on the planet.

Why Alfresco?

The one thing that I didn't have at any of the companies that I'd been with was real mentorship on the business side. I felt like I knew the open source side reasonably well, but in terms of how to grow a company, I didn't really have that. So here was a company founded by the founder of Documentum, took it from zero to a billion dollars, and the former CEO of Business Objects who'd taken it from, I think, 50 million to 500 million [dollars]. Clearly, here was something I could learn from them.

When I first contacted them, I was coming over to speak at LinuxWorld UK and I thought: "Who are the open source companies in the UK? Well, I'll contact Alfresco. They look really interesting." But I thought that I wouldn't be at all interesting to them. They were these guys with this great pedigree. Clearly, they didn't need any help.

On their side, they were thinking: "We don't know anything about open source; we're an open source company. Clearly, we need a lot of help." And here's this guy that seems to know something about open source, contacting them out of the blue. I only found out later that they were really excited to get involved with me. From my side, I was thinking: "Well, I really don't have that much to offer, but hopefully they'll take me on out of charity." It was a good match.

So how did they come to launch an open source company, not knowing anything about open source?

Funny you should ask that: most of the open source companies that are out there are launched by people who don't know anything about open source, and it shows. I think the best open source companies have been those that were launched by developers first. So, arguably, that's JBoss, Red Hat, MySQL, where the community came before the company. The company was an afterthought.

In Alfresco's case, we're pioneering somewhat, because the company definitely came before the community. I think that's a really difficult thing to do. I think it's hard to fake community, but I also think it's really important [to have one].

How these guys got started, is they had actually started another company and it failed. When they tried to explain to me what the product was, I can't understand it, and they can't really explain it, so that's one reason it failed. The other thing was it just became evident to them that it was really hard to go in there and plop a million-dollar proposition on these companies.

They decided: "Look. How can we distribute our products in such a way that people can get easy access to it, and they don't have to pay these insane amounts of money?" They perceived from their efforts that this enterprise sales model, and the enterprise pricing model, was broken. It wasn't going to work very much anymore. And they said: "Oh, it's open source!"

Maybe a year after that, they said: "Why don't we start an open source content management company?" because that's what John Newton, one of the founders, knew really well. But this time, we'll do Documentum part two, and this time we'll give the product away for free. And it sounded like a great proposition, except for the free part, and that's what we've been figuring out ever since.

What was the licensing model when you first joined?

It was a Sugar[CRM] model, so 70 percent of the code was open source under the [Mozilla Public License], and 30 percent was proprietary. But that is a terrible model on a range of scores. One that was continuously coming up was: we just developed this new feature; should it be open source or should it be proprietary? We were constantly having to struggle with this.

So we moved to a model where it was 100 percent open source - but it was not really open source, because my definition of open source is that it has to be under an OSI-approved license, and this was Mozilla Public License plus Attribution, which had a contentious time out in the market. Attribution said you had to have a "Powered by Alfresco" logo on every screen with a little subtext that said: "This software will burst into flames at any second. Run screaming from the room when you see it. Or you can pay us and then everything will be alright."

Again, that worked for a little bit, but there started to be this fervor around "Attribution isn't real open source". I hadn't really thought about it up to that point. Internally, the same thing came around: why are we doing this? We thought it was open source, but now we're hearing from at least a vocal part of the open source developing community that this won't fly. So we scrapped that in June of last year, 2006.

Part of my job was going out and talking with customers, finding out why they were buying us and whether or not they would continue to pay money for the value we were providing if they weren't forced to. In the process of doing that we discovered some interesting things. A lot of companies were coming to us directly and saying: "We just want to pay you." They were sidestepping the step of using the free product and then being forced into, for whatever reason, our proprietary plug-ins or enhancements or whatnot. A lot of them had an internal policy that they wouldn't use software unless they had a support contract.

We were fortunate: most of our customers were big companies. I think that made it a little bit easier for us to make the decision to go GPL, which we eventually made last year, because our customers were the kinds that would pay for support. I think it might be a more difficult decision for some of our peers.

I know for us, the plus side of it is that our press mentions went up, our leads went up, our sales are up 140 percent, our average sales price is up - everything has gone up since we went GPL. Part of that may be that we're just becoming better known as a company, so the brand is selling it, but I credit a lot of it to the GPL. We are more developer-friendly. More developers that work at big companies or other companies are downloading us and trying us out. They can trust the code before they trust the company, because at the end of the day, they own the code. They don't have to come back to us.

Looking ahead, what does Alfresco aspire to become in the long term?

Well, I think Red Hat's going to beat us to it, but my personal goal is to be the first pure-play, open source software company to be a billion dollars in annual revenues - just prove that you can do it by giving the software away for free.

In terms of product ambition, we would like to see content management used by everybody on the planet. It depends on how broadly you define content management, and that's one of the things that we're working on. Today, it's a roughly three billion dollar market, but within any enterprise, only five percent of the people in the enterprise actually use a content management system. So we're trying to bring down the cost and [improve] the ease of use so that it's as easy to use a content management system as it is to send an email, as it is to search and Google, as it is to blog.

Are we going to see open source dominating software within ten years, say?

I think that every software company on the planet, within the next year, will be doing significant open source software within their walls, including Microsoft. In fact, Microsoft has actually been an early adopter because they perceive the threat more acutely than most.

I believe that within ten years most of the software will be delivered in open source-esque fashion, either as software as a service, or directly through open source. The general trend, I think, is that software will become a service over the next ten years. That's not to say that there won't be heavy outposts of traditional software. [But] just look around at the start-ups that are being funded: it's very hard to get a traditional proprietary software company funded right now.

What were your first thoughts when you heard about the Microsoft-Novell deal?

I was extremely disappointed because if there's any company that didn't need to do that, it was actually Novell. Because Novell has patents that go to the heart of both Microsoft's Windows Server business and its Office business. Novell was under absolutely no threat of ever being sued by Microsoft, period.

The reason they did it is to try to club Red Hat. Novell thinks it has an interest in destroying Red Hat; really what Novell needs is for Red Hat to continue to be successful and for Novell to learn how to be successful with Linux.

I just remember thinking: Here's Novell. It's best chance of surviving in the future is to move toward more of an open source model, and it's just basically told the very community that could feed it that it didn't want it. It was cutting itself off from its future. I think it's done itself irreparable harm now. I just think Novell will have a very hard time ever gaining credibility again as an open source vendor.

Are there any threats that you see facing open source as it grows in the future?

I worry that diluted forms of open source will come to be viewed as acceptable, and that's why I think the OSI is so important. When I look around at my peers, they're arguing for an expanded definition of what open source means - they want this Attribution [variant] to be accepted, they want various different licensing models to be accepted as open source.

I do worry that if we bastardize the concept of open source to make it lowest common denominator business-friendly, then we lose the power of open source. Because the greatest threat to Microsoft and to these proprietary software companies is not a weak form of open source, but it's the full, pure open source. Frankly, it's GPL'd open source.

It sounds like you've become quite religious about it.

I've come 180 degrees on it, and I am a little bit religious on it, because ultimately, coming back to the point I was arguing against Larry Lessig in law school, I think freedom does matter. What's odd is that it actually matters as much to the vendor as it does to the customer.

For the long-term success of open source vendors, they need to realize that freedom is in their interest, too. When you throw away all the safety nets, the proprietary crutches, it forces you to do business in a way that's overwhelmingly positive for customers. And if you can do that, then you'll be successful.

Glyn Moody writes about open source at opendotdotdot.

Comments (3 posted)

Page editor: Jake Edge
Next page: Security>>

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds