Does Linux Suck?

I have had numerous discussions around Linux, especially as a desktop OS. A lot of Windows and Mac folks like to say that Linux sucks. A lot of the diatribes against Linux usually have to do with getting laptops to functional completely. A lot of people assume that this is a Linux problem, and that Linux must "suck", because some piece of hardware don't work, or doesn't work out-of-the-box.

A lot of other complaints to Linux revolve around functionality issues. Either something doesn't work the way Windows or Mac OS X does, or some application isn't available, or they just don't like the alternative application and they way it works. Are these types of issues related to the quality of the operating system?

I would say not! Many of the issues are actually a matter of taste, versus a matter of fact. Simply not liking the way an operating system does something, doesn't mean the operating system sucks. Just that it doesn't work the way you expect, or it doesn't fit your style of working. For every person that doesn't like the way something works, there are many who probably do.

Personally, I have Linux running on an HP laptop with an Athlon 64 processor. When I first purchased it, I installed Fedora Core 3 on it. Did everything work out of the box? No. Did most everything work? Yes. Considering how proprietary laptops are, and considering that the manufactures are not working directly with a Linux distributor to make sure everything works, it is quite amazing that things work as well as they do! Windows XP came pre-loaded on the laptop, and of course everything worked. HP specifically works with Microsoft to make sure that happens. People take this for granted, and then blame Linux when things don't work. With my HP laptop, everything worked with the exception of my wireless card, and the 16x9 display would get corrupted on the console when using the Nvidia drivers with it.

The built in wireless is a Broadcom 802.11b/g 54 Mbps card, and it was just dead. Of course, Broadcom does not produce Linux drivers, except for embedded applications. You cannot download those, so I started to see what could be done about it. I found the Ndiswrapper project, and that looked quite promising, but I was quickly disappointed, because I had put the x86_64 version of Fedora Core on the laptop, so I could actually run in 64-bit mode (The Windows XP version on the laptop was 32-bit). I started to work on porting it to 64-bit, but ran into some snags in the code base. It actually assumes that it is 32-bit and 32-bit only, so the project really started to become hard. So, I decided to see what else might be out there.

Then I found a commercial product that does the same thing that NdisWrapper does, which is load the Windows driver under the Linux kernel. The company is called Linuxant, and the product is DriverLoader. Amazingly, they had 64-bit Linux support, and they had support for my Broadcom chipset with a 64-bit Windows driver! I was elated, and I quickly purchased a copy (very cheap, but I don't remember how much), installed it, installed the driver, and boom! It didn't work! It turns out that the Fedora project had built the kernel with 4k stacks. Ouch! Typical Windows wireless drivers require a 12k to 16k stack size to operate. Dead in the water again. I guess that quite a few people had problems with things like this, so the Fedora project started building the kernel again with a larger stack size. I updated my kernel, and all of a sudden I had working wireless! Yeah!

Next issue to tackle was the screen corruption on the console. Mind you, the graphical screen was fine. This was more of an annoyance than anything. I did a search on the Internet, and wouldn't you know it, someone had created a step-by-step guide to solve this problem with my laptop and published for all to see. This is one of the real strengths of the Linux community. I followed those instructions, and low and below, after restarting X, I know had a perfectly working graphical screen, and text based virtual consoles that were no longer corrupted!

So, for my two issues, where these problems with the operating system itself? Not really. The fact that Broadcom won't release a Linux driver has nothing to do with the quality of the operating system. The fact, that HP's widescreen display needs a different modeline in the X server configuration is also not a quality problem with the OS. It is merely a public specification issue by the hardware vendor.

Yes, because of these types of issues, Linux is harder to get working. Does this mean that Linux sucks? No, it is just a reflection of the current state of affairs in desktops and laptops. All the OEM's really pay attention to is making Windows work on their machines, and in the case of Apple, Apple controls the hardware and the operating system together. So if their stuff doesn't work, that's a real problem.

For me, I work very productively with Linux everyday, and I don't have to reboot. I use a wide variety of applications, and never find anything wanting. The quality is great, the stability is great, and I love the fact that it changes and matures rapidly. I don't have to wait three years to get my next rev of an operating system, and then have to pay for the privilege to use it.

Linux doesn't suck!

IBM's and BEA's Comments on JBoss

With all the rumors floating around the press lately about JBoss being acquired, there have been some interesting statements about JBoss made by competitor's IBM and BEA.

The first one I would like to address is a quote from BEA's Marge Breya. Marge Breya is BEA's Chief Marketing Officer, so we can forgive her a little for her ignorance. So here is the quote:

"JBoss is closed from a contribution standpoint–it's open source with a closed community…a bit like calling Cuba a democracy," said Breya.

Here is the link that contains the quote:

http://blogs.zdnet.com/BTL/?p=2574

This has got to be one of the most twisted statements I have every read. First, she claims that JBoss is closed from a contribution standpoint. This is the furthest thing from the truth. Open source contribution is based on a meritocracy. The best contributions are committed, and contributors earn committer status in the projects. JBoss is no different, and I can assure you that JBoss has many contributors outside of JBoss, Inc.'s paid developers. If BEA wanted to contribute, their developers would have to earn that right through valuable and good code contributions. There have been over one thousand contributors to JBoss projects, and that number will continue to grow. If you look at the forums on the jboss web site (http://www.jboss.com/index.html?module=bb) you will see a vibrant community of users and contributors (actually users are contributors too). There are thousands and thousands of posts on all the various JBoss projects. If this isn't community, then what is she talking about?

Second she tries to say that we really aren't open source because we don't have a community, and says it is like calling Cuba a democracy! What a ridiculous statement. So let's really look at this statement. We all know Cuba is not a democracy but a communist state. You would be off your rocker to make that statement. Is Marge Breya, off her rocker by saying that JBoss is not open source? Well, let's ask ourselves some questions. What license is the software licensed under? JBoss is licensed under the LGPL. Is this an approved open source license by the Open Source Initiative? Yes, it is. In fact, the LGPL specifically prohibits the code from ever being closed. We have already gone over the community question and contribution, so what is her beef? I think that it has to do with the license. More on that in a minute.

Next, we have some IBM comments from Steve Mills. Steve Mills is the head of IBM's software group, and he was quoted saying the following:

JBoss' Java application server contains a significant proprietary component even while it adheres to the Java 2 Enterprise Edition standards.

"JBoss has a lot of proprietary JBoss. It's sort of a hybrid model of open source," Mills said.

Here is the link that contains the quote:

http://news.com.com/2061-10795_3-6040916.html

Steve Mills claims that JBoss is a hybrid model of open source. What does that mean? Is some of the JBoss code closed source, and some not? Absolutely not! Are some of the JBoss projects not based on an open standard? Yes! Is JBoss not open source just because they have code that is not based on some standard? No! Having said that, are there standards for covering the things that are not based on an open standard? No! There are no open standards for object/relational mapping, with the exception of the new EJB 3.0 specifications, of which JBoss was the main contributor, and has an implementation already. There are not open standards for Aspect Oriented programming. This doesn't stop IBM from using AspectJ does it? Is AspectJ not open source because it doesn't adhere to some standard? Of course, not! This is just a bunch of hooey! Why would IBM be complaining about JBoss being proprietary? Have they open sourced their WebSphere product line? Do they have any proprietary technology in WebSphere? Of course they do. Just like JBoss, you have to solve real-world customer problems, and that means you have to have technology that is outside of any standards. Standards only cover part of the problem space for developing real-world solutions to real business problems. How many WebSphere and BEA shops use Hibernate for their persistence? Lot's of them do, because it is simply works better. I believe there are two fundamental reasons for IBM and BEA to cast disparaging remarks at JBoss.

The first reason, is the license that JBoss uses. It does not let them fork the code and make it proprietary. BSD and ASF style licenses allow, and to some extent, encourage forking the code, and taking it proprietary. This allows traditional software vendors like IBM and BEA to mine the best of open source and take it proprietary. So the open source community does the work, and IBM and BEA get the money. This sounds like exploitation to me. The second reason, is that much of the JBoss technology can run inside BEA's Weblogic and IBM's WebSphere. This must be very scary for them. After awhile, their customers might start to think, why am I paying BEA and IBM anything, when I am getting the most value from the JBoss software components. Maybe I should just adopt the entire JBoss stack instead?

In summary, they want to make it seem that JBoss is not really open source, because JBoss poses a huge threat to their traditional middleware revenues!

Software Development Productivity

I have been caught in a lot of discussions over the past year or so about software development productivity. How to measure it. What improves productivity? Does it come at the expense of quality? All kinds of things to think about. In researching this topic, along with quite a few other folks that I have worked with, I have a set of principles that I would like to discuss.

One area that concerns a lot of enterprise is the requirements process. How do you get good requirements up front. It seems like it should be easy right? Nope! It isn't easy at all. Software systems are difficult for end users to describe before they see them. I think it is one of the reasons that packaged applications have been popular versus writing the application in-house. So what can you do about requirements?

The only thing, that I believe can be done, is to follow an iterative process. That is, don't bother trying to gather requirements up front, because they will never be right, no matter what process is followed. Define some high-level goals, and write something that illustrates those goals. If the requirements cannot be written down on 3x5 cards, then you are specifying too much. Keep it simple, and get something concrete in a short two to four week cycle that the end user can actually look at. The end users will be able to articulate what they like and don't like, and how something should work only after seeing an implementation. That will get the ball rolling, and you can then do iteration after iteration to refine, add features, correct things that may otherwise go way off course.

This iterative process shouldn't be dragged on for a long time either. The entire project life-cycle should be complete within a twelve to sixteen week process at the most. Did you know that research has shown that projects that go on for six months have a less than 50% chance of being implemented! If you go all the way out to thirty-six months, the odds drop to zero! That's right, zero! Keep the projects small and managable, and release early and often, not just in your iterations, but to production as well.

For both principles above to succeed, you must work directly with the end users of what you are building. Don't fall into the trap that a lot of organizations fall into, where they have organizations dedicated to working with business people, and they will translate the requirements for developers. This is a huge expense burden on the company, and it only makes matters worse. Think about it. Haven't we all played the telephone game, where one person starts and whispers something in the next persons ear, and so on, and so on. When you get to the last person, is what the first person said ever repeated? No! Of course, not! This same principle is at work with layers of organizations that are supposedly there to help, but only serve to scramble the message. Let developers, no matter what you think of their people skills, work directly with end users. You will find that you get a better product, quicker, and you will have happier end users.

Keep team sizes small. In knowledge work, which software development is, you should never have a team size larger than seven people. Why do I say that? How did I come up with seven as the magic number? If you look at the research done by Quantitative Software Management on project team sizes, you will see that team sizes between three and seven are the most productive. Large team sizes can cost upwards of 400% more, and deliver 29% later, doing the same size work! This is dramatic. If you have a project that just seems to large to deliver with a small group, don't trust your intuition. It is wrong! Keep the team size small, and if something really is very large, break it up into sub-projects that can be delivered to production in a twelve to sixteen week period. You will deliver value quicker, and the overall project will get completed much quicker and at a much lower cost.

Where are these principles demonstrated for everyone to see right out in the open? Well, its obvious (at least to me). Open source projects work this way be default. They have small sets of contributors at the center. Even large open source communities have divided things into sub-systems that can be worked on by a very small groups with committer access. They work directly with their end users. No middle man. Requirements are not expressed in large documents. In fact designs are not documented at all! Instead, implementations that only demonstrate the overall goal of the project, is how things get started. The process is iterative, with many small releases, some labeled aphas or betas, or release candidates, while others become a "stable" release. This allows the project to get feedback from users early, and users can give feedback in the form of feature requests, bugs, etc. See the parallels to what should be happening in the enterprise?

If you adopt the open source model of development in-house, you will find a huge productivity boost for your organization, and you will find that your end users are much happier, because they will actually get what they need and want, in a reasonable amount of time, for a lot lower cost.

Think about it!

GPL 3 and DRM!

I have been coming across a lot of articles talking about the new version of the GPL (GNU Public License) lately, and specifically the issue around DRM or Digital Rights Management. One thing really strikes me about the articles. The fact that, in many cases, we are mixing multiple issues together, that shouldn't be mixed together.

DRM, in the consumer products world, is one thing, and DRM in the corporate information world, is entirely another. In the first case, we are talking about movie studios, music labels, etc. trying to control the distribution of a copyrighted work so that everyone pays for their copy of that work. While, I can understand this, as they want to be compensated for the costs of producing that work, the control mechanisms being used go far beyond ensuring that you paid for the copy. They try to completely control what you do after you have paid for the copy. These copy protection schemes, like the software copy protection schemes of the 1980's will fail, because people will not tolerate them for long.

In the other case, protecting corporate information, such as trade secrets, is certainly something that open source software needs to support. Corporations of all shapes and sizes, with all kinds of business models, have a need to protect certain information. If anyone doesn't think that corporate espionage doesn't exist, they are naive. Digital signatures, encryption, permission based controls, all have their place where protecting corporate information is concerned. In fact, these are all things that are in place, in one form or another, in open source software today. We should not mix these two forms of DRM, and put them in the same basket. If we do, then we are in jeopardy of losing the very corporations that are helping to make open source software a success.

Software licensing is not the area to be trying to combat DRM!