So, today we released SSSD 1.0.3. We fixed a few bugs, but more importantly we did it in an open way.
I generally assume that anyone reading this blog has heard of open-source before. If not, I suggest you log on to the Internet more. More eloquent bloggers than I have done a better job explaining the open-source concepts. The SSSD is more of a case-study in why open-source works. In this last week, we’ve done a bit of work on our own inside the core SSSD team headed in the direction of our next feature release, but at the same time we were working with outside developers.
One of these developers took a look at the SSSD and decided that it might come in handy for use on embedded devices like smart routers. So he tried to build the SSSD on the ARM processor. This failed, because most of our development on the SSSD takes place on i686 or x86_64 systems (with some limited testing done on PowerPC). Here we have the first example of why open-source works: someone came in from Outside with an idea: that the SSSD might have a place beyond personal computers. Beyond that, with the source code available to them, they began the effort of implementing this idea. Unfortunately, in its current state of development, the SSSD was unable to run on the ARM platform. This developer then took it upon himself to dive into the code and identify the source of the problem (if you care about the details regarding alignment of memory, feel free to look at our git history. I’m not going to bore you any more than I have to). Once he identified the issues, he created a patch and submitted it to our mailing list. We reviewed it and included it in the 1.0.3 release today. Open-source works because people like this not only identify new ideas, but they have the ability to run with them as well. In a traditional, closed-source development team, the process would have looked more like this: 1) Open a bug. 2) Wait to see if the company developing the product agrees with this idea. 3) Wait to see if the company has resources to expend on implementing the idea. 4) Wait for a release including this fix. With open-source, even had the SSSD team decided not to release 1.0.3 for weeks or months, this gentleman’s patch was available for anyone to apply atop our public source and get to work on.
The second story I want to tell is about the benefits of cooperation between distributions. Another prominent GNU/Linux distribution recently began work on updating their SSSD package to 1.0.2 (previously they had been running a very old and buggy 0.5.0). They ran into a bit of trouble and contacted us through the usual channels to help them track down what was going wrong. It turned out that one of the differences between these two distributions was this (and I apologize, but there’s no real way to avoid going into a little bit of detail on this): on Fedora, when you link against a shared library, you automatically inheret any link that this library has. In our case, we linked against libldb, which in turn linked against libkrb5. On the other distribution, however, there is no implicit linking. All links need to be made explicitly. So we tracked down where we needed to link properly and added that. “But Steve,” you ask. “How is this an example of distro cooperation improving the product for both distros?”. The answer is this: working with this other distribution helped us to avoid a painfully embarrassing situation in the coming months. The reason for this is because one of the features coming in Fedora 13 is the very same requirement for explicit linking. So thanks to the developers from the other distribution, we were able to fix this ahead of time and save ourselves a lot of trouble (and support calls!) when Fedora 13 arrives.