Pieter Hintjens will give a talk about OpenAMQ at FOSDEM 2009.

Could you briefly introduce yourself?

Like Kuifje (Tintin), I search for the truth, defend the weak, and stand up to bullies. Unlike Kuifje, I don't have a white dog, and I get older each year. My work is designing and writing software systems: large architectures that solve complex problems. I'm also a student of human nature and its manifestations in politics, economics, and society. Software design is about overcoming human, not technical, limitations. I've been a free software developer since 1991, and active in various political issues like software patents. I've been writing various books on and off for a decade but those seem to take too much bandwidth, so now I stick to short writing (www.aliopacto.com, www.devilswiki.com).

What will your talk be about, exactly?

I'll talk about three things, at least. First, AMQP, a new protocol, which we'll cover further in this interview. Second, OpenAMQ, a free implementation of AMQP, which is interesting for a couple of reasons that I'll keep as a surprise. Lastly, RestMS and Zyre, which are respectively a specification for, and implementation of, a RESTful messaging service that interoperates with AMQP. However, this won't simply be a technical briefing, I'll present a more holistic view of what it takes to make a project like OpenAMQ work.

What do you hope to accomplish by giving this talk ? What do you expect?

I want to promote our open source products and try to convince those listening that there are good reasons to look at AMQP, OpenAMQ, RestMS, Zyre, and the other designs we've made. Sturgeon's Law applies to software as to no other field, and it's often hard to be heard above the cacophony of "Bigger! Better! Newer!", especially for small teams like ours.

So it's a privilege to get a chance to speak at FOSDEM. I'll do my best to keep the sales talk off the stage and instead stick to useful lessons we learned, which could help other teams.

Which problems does AMQP solve?

It is, today, relatively cheap to make applications. It's still expensive to connect them together. AMQP is the first serious attempt at a standard protocol that does that. Until AMQP, each product that promised connectivity did it their own way. So AMQP does what any free and open digital standard should do: gives customers maximum choice of suppliers. It should do to messaging what SQL did to databases.

Why would a large company, being able to afford commercial messaging products, choose for an open source AMQP product?

Even - especially - large companies love to save money. AMQP offers choice of suppliers which means the lowest possible costs for licenses, support, and material. The competition means that AMQP products are faster and need less hardware. The openness means that AMQP skills are cheaper. No more Wizards. The euro difference between traditional commercial messaging and OpenAMQ is as much as a hundred times.

Switching messaging infrastructure can be very risky. We're talking of critical systems, like Dow Jones Company, who are now running the Dow Jones Industrial Average on OpenAMQ. One really does not want data to be lost, received late, or more than once! The risk is offset by the huge gains, so much that we've seen firms where OpenAMQ was the first ever open source product they used.

If the AMQ model for a business messaging server is so simple, why hasn't it been invented before?

In fact AMQP is not as simple as it could be. This summer I spent a long time looking at complexity that remains in the protocol, and designing ways to remove that. The result is RestMS, which does much the same as AMQP but is considerably simpler.

Simplicity is thus the destination, not the departure point. Initial designs are complex, since complexity is cheap. Any fool can build a complex system. It takes skill, and time, to build a simple system (which does real work, of course).

AMQP solves problems until recently only seen by large firms. The whole concept of joining dozens or hundreds of arbitrary applications together does not interest most protocol designers or FOSS developers. So AMQP could only emerge when large banks like JPMorganChase decided they needed it, and paid experts like us to make it.

Despite appearances, software technology moves slowly, and things happen when the time is right. AMQP's time is now right: there is a market for this technology.

One advantage of AMQP is that it's language-independent. In which programming languages do AMQP implementations exist? How does it compare with Stomp, which has implementations in more than ten languages?

Stomp was actually written as a response to AMQP, and is the wire level format of a single product, ActiveMQ. James Strachan worked for a couple of weeks with me on AMQP at the very start of the project, then decided to make Stomp. There is one Stomp implementation (the ActiveMQ server) and clients in ten languages. Stomp belongs to ActiveMQ, and reflects the needs and capabilities of that product. A business that uses Stomp does not get any real benefit, they are dependent on a single vendor.

AMQP was written without regard for any particular product, and we've seen five or six independent server implementations of AMQP plus clients in C, C++, Python, Ruby, Java, C#. AMQP has larger ambitions than Stomp, and lives independently from any implementation. Businesses that use AMQP immediately get a choice of multiple competing products.

This is the main reason for a free and open digital standard: choice. A documented format is better than none, but it's not the same as a free and open standard.

What is the unique selling point of OpenAMQ compared to other AMQP implementations? And what parts of AMQP are not implemented in OpenAMQ?

OpenAMQ does not implement persistent messaging (queues on disk). We consider that to be complex, unreliable, and for most cases, unnecessary. We focus on speed and reliability. Recently we found what appears to be the last stability bug: after 2^31 socket operations, the server would crash due to an array index error. Always use uint for array indices! But 2^31... that's a lot of messages. We hit that after six hours at one client. The server now runs forever without any issues, and can process around 600,000 512-byte messages per second (in and out combined).

This kind of robustness comes from simplicity. It comes from understanding where traffic builds up, and preventing that. It comes from very fast multithreaded client APIs. It comes from not doing certain things, and so in OpenAMQ we're not driven to add features but rather to make what we have more stable, faster, and easier to use.

So, federation and failover work with a single command line option each. I like this kind of essential simplicity. Also, OpenAMQ spreads into areas like RestMS, which opens the door for whole new messaging possibilities. Imagine: connect your AJAX web application to an AMQP data feed, with no special programming.

How big is the OpenAMQ community? How many persons of this community are working for iMatix?

On the dev mailing list I count 85 people, but few of them are contributors to the core code. There are reasons for that, mainly that we use a lot of meta programming and that keeps people out. When we get a subproject where people want to contribute we spin it off as an independent project on Github. And people help a lot with bug reports, suggestions, the usual stuff. The iMatix OpenAMQ team is about 5 developers, and several more support people. All of us work on multiple projects, not just OpenAMQ.

You are a regular speaker at FOSDEM, how was the response to your talks the preceding years?

Oh, people find the talk of software patents to be depressing. It's like when you ask someone "how are you?" and they tell you their cancer story. Sure, it's important, but it's not the stuff of parties.

Still, I found the FOSDEM participants to be surprisingly tolerant of this guy who keeps popping up and saying, "BEWARE! They want to steal your software!" For that, thanks! I promise to not do it again.

This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.

Martin Odersky will give a talk about Scala at FOSDEM 2009.

Could you briefly introduce yourself?

I'm creator of the Scala language and a professor at EPFL in Lausanne, Switzerland. Much of my work is about combining object-oriented and functional programming concepts. I co-designed Pizza and GJ, which eventually became the foundation for Java generics. I also wrote the original code of the current javac compiler.

What will your talk be about, exactly?

It gives an introduction and overview of Scala.

What do you hope to accomplish by giving this talk ? What do you expect?

I expect some parts of the audience will not know Scala yet. I hope my talk will give them some good ideas what it is and will motivate them to find out more. Others might already have used Scala a bit. I hope those will get a better sense of what more you can do in Scala, and what its design philosophy is.

What are the biggest advantages of Scala? And for which tasks should the language definitely be considered?

The three biggest advantages are productivity, reliability, and ease of conversion. Compared to Java, Scala reduces code size on average by a factor of two to four. Less code tends to require less work writing and maintaining it and also tends to have fewer defaults. Scala's strong static type system encourages solid designs and catches many errors already at compile time. At the same time, Scala is relatively close to Java. You can write Scala in the same style as Java, and gradually add more functional elements at your own pace. Scala is sometimes criticized by purists that it does not force a functional programming style on programmers. I think that's an advantage, and it certainly does make conversion easier.

For which tasks to consider the language? I'd say any task in a Java environment; the more challenging the better. Particular strengths of Scala come to play in support for concurrency, XML, GUI programming, or domain-specific languages. It can also do a decent job at scripting, but I would not use it in a job that requires only scripting and nothing else.

Functional programming is not yet a standard topic in computer science curriculums. Is the industry ready to use this programming paradigm?

I think the industry realizes more and more that a certain amount of functional programming is inevitable, if multicore computers should be used efficiently. Those who have made the jump also find that functional programming is a win in terms of productivity and reliability. So it's a classic adoption cycle, which starts out to be application-driven and continues because of design advantages. Object-oriented programming underwent a similar adoption cycle when it first came out. At first, it was the technique of choice for GUI programming, but very quickly the benefits of object-oriented modeling became a second and more important reason for adoption.

What are the biggest disadvantages of Scala at the moment and how will these be addressed in future versions?

The .NET version of Scala currently lags behind the JVM version. For instance, there's no Visual Studio support yet. The good news is that we have received funding from Microsoft for our ProgLab project, some part of which will be about improving Scala on .NET.

Is there good IDE support for Scala, for example in Eclipse or NetBeans?

There is now a fair degree of support for Scala in all three major IDE's: Eclipse, IntelliJ, and Netbeans. All three plugins are still rapidly developing, with new functionality being added at a quick pace.

In Erlang, multiple processes can share the same data within the same VM because the data are immutable. In Scala, pointers to (mutable) objects are sent between actors. So Erlang guarantees safe access to shared objects, while Scala doesn't and is thus prone to race conditions. Why this decision?

In Scala like in Erlang, it's usually immutable data structures that are sent between actors. The difference is that in Erlang this is enforced by the language, whereas in Scala it is a generally accepted programming policy. Why does Scala not enforce immutability of all data like Erlang does? The easy answer would be: Because Scala is interoperable with Java, it must deal with Java's mutable data structures such as arrays or hash maps. So global immutability is not an option. The more complicated answer is: Sometimes mutability is necessary to get really high performance. Imagine an image processing pipeline, where each stage is implemented as an actor. You don't want to copy images when sending them from one actor to the next; it would be too expensive. We are currently experimenting with effect systems that would let you better characterize what gets changed and what stays immutable. But that's still in the research stage.

Are there differences in what you can do with Scala on Java or .NET because of the underlying architecture?

Currently no, except for differences in native libraries. In principle, we could make use of .NET's reified generics, which keeps type parameters around at runtime. But it would mean forking the language, and there are some incompatibilities between .NET's generics model and Scala's. So we will probably keep things as they are.

What are the next steps in Scala language evolution?

In 2009 we plan to release version 2.8, which will likely have several additions to the current standard. For instance named and default parameters, trait parameters, virtual classes, and redesigned collections. We also hope to improve performance by specializing generic structures to primitive types. Beyond that, the focus will be on concurrency support. How can we program multicore computers and cloud services efficiently and reliably? Scala's actors will be an important part of this, but other constructs will probably come into play as well.

This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.

Rob Savoye will give a talk about Gnash at FOSDEM 2009.

Could you briefly introduce yourself?

Sure, I'm a long time free software developer for 20 years, initially a cross tool chain and embedded systems hacker, then renewable energy projects, and now Gnash. I've primarily worked from my home way up in the mountains of Colorado at 9000 feet the entire time.

What will your talk be about, exactly?

This talk isn't so much about Gnash, as about some of the reverse engineering done for the Gnash project. Adobe supports a family of networking protocols called RTMP that was wanted to support, but there were no available documents. So this talk is about how that protocol was reverse engineered.

What do you hope to accomplish by giving this talk ? What do you expect?

I thought it would be useful to others to see how you can go from hex dumps to implementing code for a something you know nothing about. It's also interesting to see how much information can be extracted from raw hex dumps as well.

What are the most important Flash features that Gnash doesn't support yet? When will Gnash fully support SWF v8 and v9?

Fully supported? Some of the ActionScript classes that rarely get used may not get implemented for a long time. Gnash already has decent v8 support, and a v9 parser, but our the ActionScript 3 library is a bit limited still. An important feature that has been missing for a long time is RTMP support. Now that I've reverse engineered it, that will finally be appearing in Gnash. Other than that, the big thing we are lacking are more complete ActionScript libraries, although we support all the commonly used ones.

The next Gnash release will have all of the new v9 support, which while under heavy development, is now stable enough to release. It'll also include the new RTMP support that I'll be talking about, plus it'll be the alpha release of Cygnal, a free media server similar to Adobe's FMS 3. We've been busy. :-)

What are the biggest obstacles the Gnash developers are facing? Are these obstacles technological or legal?

These days it's primarily legal. Technically, we've pretty much figured out alot of things about how flash works internally. Legally, we can't distribute a fully working executable due to issues around our usage of ffmpeg for video & audio codecs.

The Gnash project recently got funds from the Linux Fund to support RTMP streaming media. How dependent is the project on funds?

We had good funding the last few years, and it let us make better progress than is usually seen for a free software project. Since we recently lost most of our existing funding due to the economic crisis, it's important that we can find other sources of funding if we want to continue with the rate of progress we've been making. We're not dependent on funds, but make better progress when we can work on Gnash full-time. The Linux Fund donation is actually not much more than supporting one developer for 2 months to work on RTMP support in Gnash, so more donations are always appreciated. Most of us currently working on Gnash are doing it for free as volunteers like most free software projects.

The goal of the Gnash project seems to have been evolved from creating a free software Flash implementation to an open media platform. When and why did you decide this? And what will we see from this evolution in the near future?

Gnash isn't a media platform, it's part of one. We want to free-up the entire user space for flash based applications. So we've also been maintaining the Ming project, which we use as our flash compiler, and I've been lately working heavily on a media server that speaks ActionScript and RTMP and can support video conferencing and groupware applications. Over time, we plan to modify these tools from the creation side to the server to the client to predominately use patent free codecs. We'd also like to put a nice simple GUI on Ming, as now all our flash creation tools are command line oriented.

Adobe released the Linux version of Flash 10 at the same time as the Windows and Mac OS X versions. Do you think this means Adobe will care more about multiple platforms in the future?

I think Adobe has to, as we don't live in a world were everyone runs Windows on Intel architectures, even if certain big companies would prefer things that way.

Your main reason for starting Gnash was to create a free Flash solution for embedded and CE devices. Now that Adobe announced to release a full Flash 10 player for ARMv6 and ARMv7 processors, will this make Gnash less important?

Not really, what is important is that we have free software that enables us to access existing content in a proprietary format. Without Gnash, many of us would not be able to access YouTube, for example, from the platform of our choice. In addition, Gnash also runs on more embedded processors than the ARM, including several MIPS variants and PowerPC. (both 64 and 32 bit, big or little endian)

You have been working on free software for more than 20 years. If you look back at the evolution of free software in those two decades, what do you consider the biggest difference?

The biggest difference is that free software is much more accepted these days as good business sense, and not just a bunch of crazy people. A long time ago if you worked on free software, people thought you were a homeless bum. These days, you're just as likely to discover all sorts of people run free software for all sorts of tasks, and it's nice to see we've had a positive impact on the world over the last 20 years.

This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.

Download PDF with this info to print: http://tmp.fosdem.org/PracticalInformationForSpeakers.pdf

Dear FOSDEM speaker,

You receive this mail because you are scheduled to give a talk at FOSDEM 2009 in Brussels, 7 & 8 February 2009. This page contains some important practical info about the event.

• Hotel booking
• Saturday evening dinner
• Schedule
• Transportation
• Practical information

Hotel booking

Here is the exact address of the hotel you will be sleeping at:

  Novotel Brussels Off Grand' Place
  120, rue du marché aux herbes
  B-1000 Brussels
  (Contact: Céline Snauwaert / Karin Stegeman)
  Tel: +32 2 500 3721

If you encounter any issues at the hotel call Philip: +32 486 114 720

We will leave an envelope with more information at the hotel desk. When you arrive at the hotel, the receptionist should give it to you. If not, please ask for it.

The first thing to check is the hotel booking. The dates in the table below are the arrival and departure date & time to & from Novotel.
Most of you will be arriving at Novotel on the 6th and leave on the 9th of February. That means 3 nights have been booked (6->7 , 7->8, 8->9). Breakfast is included.
Extra reservations have also been made. You should get a separate mail if this is the case for you.
As a reminder, FOSDEM is reimbursing travel and hotel expenses for those 3 nights only.

Here is the list of the noted arrival dates and departure we have in our database

name	arrival_date	departure_date	remark
Brion Vibber	2009 02 06	2009 02 09	(null)
Steve Hardy	2009 02 07	2009 02 08	double room
Pieter Hintjens			No travel costs No hotel costs
Rob Savoye	2009 02 06	2009 02 09	will be staying longer in belgium. They are taking care of their own hotel later
Martin Odersky	(null)	(null)	(null)
Max Spevack	2009 02 06	2009 02 08	double room
Joe brockmeier			no hotel
bryan Ostergaard	(null)	(null)	(null)
H. Peter Anvin	2009 02 06	2009 02 09	(null)
Theodore Ts'o	2009 02 05	2009 02 10	double room
Kris Kennaway	(null)	(null)	(null)
Leslie Hawthorn	2009 02 04	2009 02 09	double room
Bdale Garbee	2009 02 06	2009 02 09	(null)
Mark Surman			Hotel with Mozillians
Simo Sorce	2009 02 06	2009 02 09	(null)
Victor Stinner	2009 02 06	2009 02 08	(null)
Matteo Meucci	(null)	(null)	(null)
Lenz Grimmer	2009 02 06	2009 02 08
Scott James Remnant			no hotel booking and no travel costs
Matteo Meucci	2009-02-07	2009-02-08
Martin Odersky	2009-02-06	2009-02-08

(null) means we don't have the information. An empty field means there is no need for a reservation.
Can you please confirm the booking is correct or let us know if it is not?
If you are not on the list, that means that no room has been booked for you!

Saturday evening dinner

We are organizing a dinner for FOSDEM speakers and staff and volunteers. There will be dishes that should please everyone, vegetarian or not. As a speaker you are allowed to bring a (single) friend but we will ask 25 EUR participation. Speakers and partners don't have to pay of course.

Please fill in this form to choose your meal: http://fosdem.org/speakers/dinner
Final deadline on 31 January

Schedule

The schedule has been published at http://fosdem.org/schedule If there is a problem, or a conflict, please let us know ASAP.

Transportation

Info from Novotel

How to get to the hotel by public transportation:
You have to take the train to "Bruxelles-Central" and walk to the hotel. It's just a one minute walk. A map with the walk description.

How to get to the hotel by car:
There is no parking at the hotel, but there is a public parking next to the hotel. We will reimburse the parking cost of course, please keep all proofs of payments. The hotel address can be found at the top of this mail.

How to get from the hotel to FOSDEM:
We will arrange taxi cabs to bring you from the hotel to FOSDEM. Please ask the receptionist at the hotel to call the company "Taxi Verts" (they will have the number). In the envelope given to you at the time of arrival, you will find a taxi-cheque and detailed address information which you can give to the driver of the company "Taxi Verts" as payment.

Here is the address where FOSDEM is taking place:

  Université Libre de Bruxelles
  Campus du Solbosch
  Avenue Franklin D. Roosevelt 50
  B-1050 Bruxelles

Practical information

Very important : we would like to maintain the schedule. There's nothing more annoying for speakers, visitors and organizers than a schedule that is not respected.

When arriving at the ULB/FOSDEM location please first go to the infodesk to announce you have arrived. It is important to keep track who is there or who is missing.

There will be a FOSDEM staff member in each room who will inform you when you only have 10 minutes left before your time is up. You have approximatively 50 minutes for the talk and Q&A. Each talk is followed by a 10 minute break to allow people to move from one room to another in order to attend another talk.

The beamers have a resolution of 1024x768, more not guaranteed. We might be able to test your laptop in combination with the beamer if you want (at lunch time for example), but please let us know at the Infodesk.

In case you encounter a problem, you can contact us by phone:
FOSDEM Infodesk : +32 (0)2 788 74 74

Finally, remember that this event is organized by volunteers, and is made possible thanks to the support of our sponsors, but also thanks to the numerous donators. We are doing our best to make of this event a success and we would like to thank you again for having accepted our invitation.

Thanks for coming!

The FOSDEM organization team.

The old mails

• Bio and Talk description
• Plane
• Hotel
• Talks and tutorials duration
• Interviews
• Slides
• Sponsorship

Bio

Could you please e-mail me :

• Your bio (or a link to it)
• A picture of yourself (or a link to it)
• A short abstract of what you will talk about during FOSDEM

You should be able to find some more information about the event on our website: http://fosdem.org/2009/.
And for previous editions: http://archive.fosdem.org/2008/ and http://archive.fosdem.org/2007/

Travel/Plane/Visum

We are asking you to book your plane yourself. Don't forget that FOSDEM is a non-commercial and sponsored event, so please book your flights early in order to prevent too expensive flights.

Please keep your proof of payment. We will ask you to fax it to us after the event, as well as your bank account details, so that we can reimburse you.

If you're outside of Europe check the regulations concerning Visum for visiting Belgium. Contact us if you have problems or need some info

Hotel

We are managing the bookings of the hotel !
We are paying for bed and breakfast for up to three nights, ie Friday night, Saturday night and Sunday night so that you can leave as late as possible on Monday after a visit of Brussels. However, we absolutely need you arrival and departure day and time. Without this information we can't book the hotel for you.
If you already know this information you can already email it to us.

Here is the exact address of the hotel you will be sleeping at:

  Novotel Brussels Off Grand' Place
  120, rue du marché aux herbes
  B-1000 Brussels
  (Contact: Céline Snauwaert / Karin Stegeman)
  Tel: +32 2 500 3721

If you encounter any issues at the hotel call Philip: +32 486 114 720

Talks and tutorials duration

Your talk will last 50 minutes, and will be followed by a 10 minutes break before the next talk in order to allow people to go to another room if they want to. We usually suggest 40 minutes talks, with 10 minutes of questions and answers.

All talks will be filmed and recorded under a Creative Commons License for later publishing on the internet. If you have any objection, please tell us before the event, so that we can take the appropriate action.

If you have not sent your abstract/picture/bio yet, please do not wait too long. This info will make your talk a lot more attractive to the visitors of our website.

Once we have a schedule we will inform you about this.

Interviews

Everyone of you will receive en e-mail asking to respond to a number of interview questions — you can expect it in the coming months.
We are asking you to answer those questions as soon as you can. As you already know, FOSDEM is a sponsored event, and we do not conduct extensive marketing campaigns. FOSDEM is well-known thanks to the word-of-mouth, and interviews are a way for us to attract publicity.
Good quality interviews get published on various websites, helping spread the word about FOSDEM, but also about your project.

You will be notified when the interview is published, and you are encouraged to promote it on you project's website.

Slides

Many people are requesting the slides of the talks. Please mail us a URL pointing to the slides of your talk so that we can put them online after the event.

Sponsorship

If your company is sponsoring part of your trip (typically the plane and/or the hotel nights), please remind it to us in this e-mail.

Thank you again and don't hesitate to contact the staff during the event, or before it, if you have any questions.

You can contact Christophe Vandeplas by phone at +32 486 64 10 33, or e-mail us at any time if you have questions, or doubts.

Every edition of FOSDEM, we conduct a short interview with the main track speakers.

FOSDEM 2009

• Rob Savoye (Gnash)
• Martin Odersky (Scala)
• Pieter Hintjens (OpenAMQ)
• Victor Stinner (Fusil)
• Simo Sorce (FreeIPA v2)
• Max Spevack (Fedora Project)
• Leslie Hawthorn (Google Summer of Code)
• Brion Vibber (MediaWiki)
• Lenz Grimmer (MySQL High Availability Solutions)
• Scott James Remnant (Upstart)
• Mark Surman (freedom, openness and participation)
• H. Peter Anvin (Syslinux)
• Bdale Garbee (Debian)
• Bryan Østergaard (Exherbo)
• Theodore Ts'o (Ext4)
• Jasper Capel (Cobbler)
• Kris Kennaway (FreeBSD performance)
• Matteo Meucci (secure software development)
• Joe Brockmeier (openSUSE)

FOSDEM 2008

• Bill Hoffman (CMake)
• Robin Rowe (Linux in Hollywood)
• Kohsuke Kawaguchi (Hudson)
• Stéphane Magnenat (Globulation2)
• Patrick Michaud (Perl 6)
• Kurt Pfeifle ans Simon Peter (klik)
• Mark Finkle (Mozilla Prism)
• Matthias Rechenburg (openQRM)
• Andrei Zmievski (PHP6)
• Steven Knight (SCons)
• Pieter Hintjens (status of software patents)
• Ian Pratt (Xen)
• David White (Battle for Wesnoth)
• Garrett J. Woodworth (CakePHP)
• Charles Nutter (JRuby)

FOSDEM 2007

• Jim Gettys (One Laptop Per Child)
• Aleksey Bragin (ReactOS)
• Federico Mena-Quintero (Gnome, Profiling desktop applications)
• Øyvind KolÃ¥s (GEGL)
• Kristian Høgsberg (AIGLX)
• Ronald G Minnich (LinuxBIOS)
• Peter Saint-Andre (Jabber)
• Kern Sibbald (Bacula)
• Andrew Morton (Linux kernel)
• Joe Hewitt (Firebug)
• Georg Greve (FSFE)
• Pieter Hintjens (FFII, software patents)
• Tom Baeyens (JBoss BPM)
• H. D. Moore (Metasploit)
• Simon Phipps (Sun Microsystems, Java)
• Jeremy Allison (Samba)
• Keith Packard (X.org)
• Miguel De Icaza (Mono)
• Paul Everitt (Plone)
• Pete Herzog (OSSTMM)