Ever heard of Paul Erdős? The 20th century Hungarian mathematician is not only known for his numerous contributions to Mathematics, but also for his multiple collaborations, engaging more than 500 collaborators. Frequently, he would just show up on their doorstep, work with them for some hours, and then get a joint paper out of that. A low Erdős number indicates academic closeness to Erdős, and is something one can brag about at academic venues. Yet, if today, Paul Erdős knocked on your door, and asked whether you would like to work with him, you should avoid any collaboration with him – if you work in Software Engineering, that is. Why is that?
The International Conference on Software Engineering, or ICSE for short, is the flagship conference of the field of Software Engineering. If you want to publish and present your greatest work, this is where you submit it. An ICSE submission is reviewed by three peer researchers, whose assessment eventually determines whether your work is accepted or not. Even if your work gets rejected, you at least get detailed reviews and high quality feedback.
Over the years, ICSE has observed that there were authors who apparently were way more interested in the reviews than in getting their papers accepted; authors who would submit up to ten papers, of which none got in; but the authors would at least get thirty reviews, all for free. This motivated ICSE to install a new limitation: Any single author can now appear only on up to three papers. If you have four papers ready for submission, then you are supposed to select the best three.
The ICSE program chairs argue that few authors and even fewer acceptances would be affected by this decision. But the problem with this decision is not the factual impact. It is the potential impact. What if a modern Paul Erdős knocked on your door and offered you to work with him? You'd have to say no, because he would have too many co-authored submissions already. What if you could not submit to the past conference, because you were the one organizing it, and still have work that wants to get published? What if four of your students all have great results at the same time, results that should be shouted out to the world? Well, too bad: you can only submit three of them, causing depression in the fourth student how is left out. None of these is likely to happen, but the fact that it could happen is causing concerns and anxiety, and rightly so. An open petition asking ICSE to revert its new rules has gained dozens of supporters overnight. (Disclaimer: me too.)
The Software Engineering community has members who have literally devoted their lives to Software Engineering research. They have no spouses, no kids, they work day and night. The boys would be out for a skiing weekend, and the girls would be out in their summer clothes – these folks are busy on the paper that they hope will make them famous. They serve on program committees, they write reviews, they organize conferences, they help others on their PhD theses. They are amazingly productive both on their own work as well as on the work of others. And these are the men and women whom the new ICSE rules send the message: Thank you, but no, thank you.
The problem of ICSE – and our community in general – is not so much an abundance of papers. It is the lack of reviews. It is our publications that determine our academic worth; much less so teaching; and even less so service. Great papers get you tenure and a raise, whereas great reviewing might get you a committee dinner. Rationally thinking, why should one spend time on reviews while one might just write papers that would get reviewed by others? Fortunately, the large majority of our community is still driven by the Categorical Imperative: We profit from the reviews of others, so we review their papers, too. What we don't like is members who game the system by not only submitting lots of papers, but also not participating in the review process.
Therefore, what our community needs to do is twofold. First, we need to think about reviewing processes that scale well and get high-quality reviews. The ICSE program board model is a step in the right direction; a VLDB-like journal model might be even better. Second, we should not penalize researchers for their own productivity; but instead create incentives for researchers who spend great effort on reviews and service. Rule by the carrot, not by the stick.
Such incentives for service should not be monetary (these wouldn't motivate researchers anyway); nor should they result in a different reviewing or acceptance process (this would be perceived as unfair). But how about raising the limit of submissions if you have a co-author who is also a frequent reviewer? Or allowing reviewing volunteers to apply for a one-day extension to the conference deadline? (You'd get plenty of applications on the last day :-) Or provide "fast track" journal reviewing for those authors who sport a status of "distinguished reviewer"? With such incentives, if a prolific reviewer like Paul Erdős knocks on your door, you would not boot him, but embrace him instead.
2016-04-17
2016-04-09
Four security flaws illustrated, all on one conference registration site
When you're organizing a big scientific conference – conventions where scientists from across the world would convene to exchange their latest and greatest –, you have to think about zillions of different things: rooms, projectors, food, coffee, budget, accommodations, badges, speakers, leaflets, dinners, just to name a few. It is impossible not to make mistakes, but it is generally possible to fix them once you know. The worst mistakes, though, are the ones you never thought they could be made.
Some time ago, I registered for one of these scientific conferences. The process is simple: You enter your details, select optional packages, finally enter your credit card data, and you're done. This being a computer science conference, you would think your data is all secure in the hand of experts. As I can now tell you from experience, this assumption is wrong. Very wrong. This single registration system contained not just one security flaw, but four – all independent of each other.
The link was a bit unusual, because it would not contain any other "secret" information or token other than my participant number, though. (You might assume it would encode my name, my ZIP code, or some other information tied to me only.) So I asked myself: What would happen if I change the link from "?parm1=1" to, say, "?parm1=2" – that is, participant number two? I entered the link into my browser, and immediately, I saw the registration screen of Lars Grunske, a colleague of mine in Stuttgart, Germany.
Now having the same privileges as Lars, I would be able to read and change all data at will. The idea arose to have him buy a few extra dinner tickets at his expense, but only briefly so. Trying the same for further participants gave the same (Hi Abhik!, ¡Hola Yasiel!).
In 2011, a similar mistake was made by UNESCO, who also used consecutive numbers for its internship applicants, and who thus leaked hundreds of thousands of applicant records on the Web. (German Article on Spiegel.de) What do you do when you discover such a problem? To protect the integrity of participant data, I dutifully reported the problem to the organizers, who immediately replied the issue would be fixed as soon as possible.
Lesson 1: When handling personal data, set it up such that access requires a secret that cannot be easily guessed.
Okay. I went to the site, and it indeed now requested that I enter my ID and password.
Problem solved? Not at all. I sent the above mail to my Post-Docs Marcel and Juan Pablo "JP" Galeotti, whom I had talked about the problem the day before. Minutes later, Marcel Böhme sent me back an intriguing message:
Incredible. Could one really attack the system this way? Ten minutes later, JP chimed in with
Ha! Indeed, this worked like a charm. Eventually, I would simply enter "2' -- " as my ID, and any string as my password – and again, I would be Lars Grunske, and would be able to alter his data at will. Likewise, anyone with the above trick could do the same to my data.
How does this work? Internally, the conference registration system uses a database that is controlled by so-called SQL commands. When I enter my ID, say, "1", and my password, say, "1234", the system selects my data from the database using a SQL command looking like this:
SELECT * FROM REGISTRATIONS WHERE ID = '1' AND PASSWORD = '1234'
Note how the number I entered as ID ("1") becomes part of the command. By entering "2' -- " as ID and "whatever" as password. we get the command
SELECT * FROM REGISTRATIONS WHERE ID = '2' -- 'AND PASSWORD = 'whatever'
In a SQL command, anything starting with two dashes "--" is treated as a comment and ignored. So the system simply fetches the data from the registrant whose ID is 2, ignoring the password. This is known as a SQL injection attack, and the standard way to avoid these is to filter out all characters that would have a special meaning in SQL commands (like "'" or "--").
Refining my ID to, say, "2'; DROP TABLE REGISTRATIONS; -- ", I might even have been able to delete all registration data. (I hope they do backups!) How could one set up a SQL-based system and never have heard about SQL injection? Now this was beginning to get embarrassing.
Lesson 2: When setting up a publicly accessible service, identify common attack vectors and protect against them – for Web sites: buffer overflows, SQL injection, cross-site scripting, etc.
The password listed was Lars' password; saving it would allow me to log in with his user ID and password. I could easily have skimmed all passwords of all participants and I could have logged in long after the SQL vulnerability had been fixed.
But storing passwords in the clear is a bad practice for many more reasons. It gives the administrator access to all passwords, which provides an opportunity for thefts. Plus, and this is probably the worst: Many people tend to use the same passwords for different sites. Had Lars indeed changed his password as requested, and for instance chosen the same password he would use for Amazon or eBay, I would be able to log in at these sites on his behalf, and happily order stuff.
Had Lars used the same password he also uses for his mail, I could have accessed all of his passwords, everywhere – a simple click on "I have forgotten my password" links would have triggered "password reset" mails to his account, which I could easily have skimmed. I'm a nice guy, so I did none of this. (Plus, I have a cool joint research project with Lars.)
To cut a long story short: I sent another urgent report to the organizer, and hours later, the SQL vulnerability was closed. The one we had found, that is. No idea whether other vulnerabilities would be hidden somewhere in there, or how the system had been tested for security, if at all.
Lesson 3: Passwords should never be stored, displayed, or transmitted in the clear. Store hashes instead; and if a user requests a new password, create a new one instead.
Was it really the case that Lars had ignored the instructions and kept his original password? After all that had happened, I thought that maybe someone had done the same that I had done, and thus now had access to my conference password. So I decided to change it online. However, it turned out that changing the password did not work – you would always retain the old one, which would still be happily displayed for you. The good news was that this way, nobody would have been able to reuse existing passwords – and anyway, had I really wanted my password changed, another mail to the organizers might have done the trick. At this point, I decided not to further stress the relationship between the organizers and their software developers and leave this be.
Lesson 4: Always allow your users to reset their access data if they fear it may have been compromised.
All was well that ended well: The conference was truly magnificent, and as far as I know, nobody's data got compromised in any way. Of course, anybody could have gone through the steps described above, skimming data without ever reporting. But luckily, the first registrant (me) pointed out the issues before some fraudster could have spotted it, and of course, any of my colleagues would have done just the same. When your customers are nice people, consider yourself lucky.
Final Lesson: When deciding between building and using a system, consider all risks and associated costs. If you build a new system, thoroughly test it for security. If you use an existing system, be sure it is well tested.
Some time ago, I registered for one of these scientific conferences. The process is simple: You enter your details, select optional packages, finally enter your credit card data, and you're done. This being a computer science conference, you would think your data is all secure in the hand of experts. As I can now tell you from experience, this assumption is wrong. Very wrong. This single registration system contained not just one security flaw, but four – all independent of each other.
 |
| My Registration Screen |
Security Flaw #1: The identifiable ID, or How I would be able to access the data of every conference participant
The fun began when I got my confirmation e-mail. Apparently, I was the first person to have registered with the conference – because my participant number was one. ("Hey – look at me; I am participant number one!" I said.) In my e-mail, I also got a link with which I would be able to access my registration. Following it would immediately lead me to the above registration screen.
The link was a bit unusual, because it would not contain any other "secret" information or token other than my participant number, though. (You might assume it would encode my name, my ZIP code, or some other information tied to me only.) So I asked myself: What would happen if I change the link from "?parm1=1" to, say, "?parm1=2" – that is, participant number two? I entered the link into my browser, and immediately, I saw the registration screen of Lars Grunske, a colleague of mine in Stuttgart, Germany.
 |
| Lars Grunske's registration screen |
Now having the same privileges as Lars, I would be able to read and change all data at will. The idea arose to have him buy a few extra dinner tickets at his expense, but only briefly so. Trying the same for further participants gave the same (Hi Abhik!, ¡Hola Yasiel!).
In 2011, a similar mistake was made by UNESCO, who also used consecutive numbers for its internship applicants, and who thus leaked hundreds of thousands of applicant records on the Web. (German Article on Spiegel.de) What do you do when you discover such a problem? To protect the integrity of participant data, I dutifully reported the problem to the organizers, who immediately replied the issue would be fixed as soon as possible.
Lesson 1: When handling personal data, set it up such that access requires a secret that cannot be easily guessed.
Security Flaw #2: The Unsanitized input, or How I easily bypassed password checks
The next day, I got a new mail from the organizers. In addition to lots of high end security stuff (which would not protect from guessing a participant number), they now had introduced a secret word only known to the registrant, commonly known as a password.
Okay. I went to the site, and it indeed now requested that I enter my ID and password.
 |
| Revised login interstitial screen |
Incredible. Could one really attack the system this way? Ten minutes later, JP chimed in with
Ha! Indeed, this worked like a charm. Eventually, I would simply enter "2' -- " as my ID, and any string as my password – and again, I would be Lars Grunske, and would be able to alter his data at will. Likewise, anyone with the above trick could do the same to my data.
How does this work? Internally, the conference registration system uses a database that is controlled by so-called SQL commands. When I enter my ID, say, "1", and my password, say, "1234", the system selects my data from the database using a SQL command looking like this:
SELECT * FROM REGISTRATIONS WHERE ID = '1' AND PASSWORD = '1234'
Note how the number I entered as ID ("1") becomes part of the command. By entering "2' -- " as ID and "whatever" as password. we get the command
SELECT * FROM REGISTRATIONS WHERE ID = '2' -- 'AND PASSWORD = 'whatever'
In a SQL command, anything starting with two dashes "--" is treated as a comment and ignored. So the system simply fetches the data from the registrant whose ID is 2, ignoring the password. This is known as a SQL injection attack, and the standard way to avoid these is to filter out all characters that would have a special meaning in SQL commands (like "'" or "--").
Refining my ID to, say, "2'; DROP TABLE REGISTRATIONS; -- ", I might even have been able to delete all registration data. (I hope they do backups!) How could one set up a SQL-based system and never have heard about SQL injection? Now this was beginning to get embarrassing.
Lesson 2: When setting up a publicly accessible service, identify common attack vectors and protect against them – for Web sites: buffer overflows, SQL injection, cross-site scripting, etc.
Security Flaw #3: Plaintext Passwords, or How I would now also steal personal passwords from all participants
But the embarrassment was not over yet. Remember how the e-mail above asked users to set up their own passwords? It turned out that the passwords were actually stored and displayed in the clear, as seen on Lars' revised registration screen:
 |
| Lars Grunske's registration screen, now with password |
The password listed was Lars' password; saving it would allow me to log in with his user ID and password. I could easily have skimmed all passwords of all participants and I could have logged in long after the SQL vulnerability had been fixed.
But storing passwords in the clear is a bad practice for many more reasons. It gives the administrator access to all passwords, which provides an opportunity for thefts. Plus, and this is probably the worst: Many people tend to use the same passwords for different sites. Had Lars indeed changed his password as requested, and for instance chosen the same password he would use for Amazon or eBay, I would be able to log in at these sites on his behalf, and happily order stuff.
Had Lars used the same password he also uses for his mail, I could have accessed all of his passwords, everywhere – a simple click on "I have forgotten my password" links would have triggered "password reset" mails to his account, which I could easily have skimmed. I'm a nice guy, so I did none of this. (Plus, I have a cool joint research project with Lars.)
To cut a long story short: I sent another urgent report to the organizer, and hours later, the SQL vulnerability was closed. The one we had found, that is. No idea whether other vulnerabilities would be hidden somewhere in there, or how the system had been tested for security, if at all.
Lesson 3: Passwords should never be stored, displayed, or transmitted in the clear. Store hashes instead; and if a user requests a new password, create a new one instead.
Security Flaw #4: Compromised Forever, or How nobody would be able to change their passwords
Lesson 4: Always allow your users to reset their access data if they fear it may have been compromised.
Post Scriptum: The Horrible Homebrew, or Why it may be better to build on well-tested platforms
This brings me to the meta lesson to be learned here – and this tells something about process rather than product. If you set up a system from scratch, be it a conference management system, a shop, a student registration system, whatever, be aware of the many risks this entails, and be sure to have independent and thorough security testing. Using an existing, established, well-tested system instead may lower risk and overall cost, even if it may cost more upfront. When the damage is done, you wish you had decided differently – but then, it may be too late.
Final Lesson: When deciding between building and using a system, consider all risks and associated costs. If you build a new system, thoroughly test it for security. If you use an existing system, be sure it is well tested.
2016-03-10
Mining Sandboxes for Security
For the past three years, my students and I have worked on a novel and general approach to address software security. This week at CeBIT, we're happy to spread some good news.
The concept of "Mining Sandboxes" protects against unexpected changes of software behavior and thus drastically reduces the attack surface of software systems. Our "Boxmate" prototype automatically mines program behavior by executing generated tests, systematically exploring the program’s behavior together with the accessed resources. The collected behavior rules form a sandbox, which at production time prohibits behavior not seen during testing. This brings several compelling features:
Want to get a brief overview of how it works? Here's a video, narrated by yours truly:
Conceptually, the techniques of Mining Sandboxes scale to arbitrary code size and can be applied to mobile apps, embedded systems, and server software alike. Mining sandboxes is fully automatic, such that vendors, developers, and users can mine, inspect, compare, and exchange sandboxes at any time. And for the testing researchers among us: This research leverages the incompleteness of testing to turn it into an advantage; and to actually produce guarantees from testing.
No unexpected behavior changes. The mined sandbox prevents behavior changes caused by latent malware, vulnerability exploitations, malware infections, or targeted attacks.
Closing the backdoors. The mined sandbox protects against backdoors that would not be discovered during normal usage.
No malware patterns required. The approach assumes no information about earlier or future attacks; it protects against known and novel attacks alike.
No training in production. In contrast to anomaly detection systems, all “normal” behavior is already explored during testing. The program is protected even before its first deployment.
No code required. We require no knowledge about source or binary code, and thus can handle obfuscated, obscure, or adverse programs.
Want to get a brief overview of how it works? Here's a video, narrated by yours truly:
Conceptually, the techniques of Mining Sandboxes scale to arbitrary code size and can be applied to mobile apps, embedded systems, and server software alike. Mining sandboxes is fully automatic, such that vendors, developers, and users can mine, inspect, compare, and exchange sandboxes at any time. And for the testing researchers among us: This research leverages the incompleteness of testing to turn it into an advantage; and to actually produce guarantees from testing.
At this point, all of this is still research, so you cannot yet buy this in a shop near you. And as with any big set of benefits, there's also drawbacks, in particular with legitimate functionality not found during testing – and there's still loads and loads of things to do. But our first results with our prototype on real-world apps are more than promising; we have a nice paper coming up at the ICSE conference in May 2016, Austin, Texas. And I am even more excited about this work than any other pioneering work of ours before, even more than say, Delta Debugging, or Mining Software Repositories – because if it succeeds, it would not only impact the lives of software developers, but actually address many of the software security problems we see in the news every day.
If this has captured your attention, you can read more about the project at its site: http://www.boxmate.org/. Or you can visit us at the CeBIT computer fair in Hannover between March 14 and March 18 (Hall 6, Stand D 28); I will be on site Monday and Tuesday. I'd love to get engaged in discussions!
2015-03-15
If you ran an EasyChair conference in the past, here's how to shut down access to past data
If you have published or reviewed computer science papers in the past years, you may have ran across EasyChair. EasyChair is a conference management system, storing and managing submitted papers, reviews, and final decisions. It is a great tool for anyone organizing a conference, and it is extremely popular: According to its own data, it has served over a million registered users since 2007.
The problem with EasyChair, however, is exactly that it is so popular. Again since 2007, I have acted as reviewer in more than 50 conferences and workshops organized through EasyChair. All their data is still there: As a reviewer, I have access to all papers and all reviews written for each of these conferences. This opens up interesting possibilities for misuse. For instance, I could download all reviews written by my colleagues, train a classifier on their writing styles, and identify them for my past and future papers. I could also check for papers of my colleagues submitted and rejected several years ago, and confront them with the sins of their youth.
This CACM article by Mark D. Ryan neatly summarizes the problem, but also points out that there may be benign uses of all this data. Hence, the scientist in me thinks that deleting all this data may be a bad idea for future historians. What we can and should do, though, is to limit access to it. As a starter, after the conference is over, every program chair should take means that its submissions and reviews can only be accessed by a minimal set of people – in particular, excluding past reviewers to extract all data. Here's how to do this for EasyChair:
The problem with EasyChair, however, is exactly that it is so popular. Again since 2007, I have acted as reviewer in more than 50 conferences and workshops organized through EasyChair. All their data is still there: As a reviewer, I have access to all papers and all reviews written for each of these conferences. This opens up interesting possibilities for misuse. For instance, I could download all reviews written by my colleagues, train a classifier on their writing styles, and identify them for my past and future papers. I could also check for papers of my colleagues submitted and rejected several years ago, and confront them with the sins of their youth.
This CACM article by Mark D. Ryan neatly summarizes the problem, but also points out that there may be benign uses of all this data. Hence, the scientist in me thinks that deleting all this data may be a bad idea for future historians. What we can and should do, though, is to limit access to it. As a starter, after the conference is over, every program chair should take means that its submissions and reviews can only be accessed by a minimal set of people – in particular, excluding past reviewers to extract all data. Here's how to do this for EasyChair:
- Log in as program chair.
- In the top menu, go to "Administration" → "Configure".
- Under "Access to Submissions", set
- "Are submissions anonymous?" to "Yes"
- "Can non-chairs see information on submissions not assigned to them?" to "No"
- Under "Paper bidding and assignment", set
- "Is paper bidding enabled?" to "No"
- "Is viewing bids of PC members by chairs enabled?" to "No"
- "Is assignment of submitted papers to program committee enabled?" to "No"
- Under "Reviewing", set
- "Are reviewer's names visible to PC?" to "No"
- "Status menu is" to "disabled"
- "Review menu is" to "disabled"
- "Permit PC members to enter reviews" to "No"
- "Permit non-chairs see and discuss reviews" to "only their own reviews"
To check the effect of these settings:
- In the top menu, go to "PC".
- Select any regular PC member and click on "login as" (the rightmost item)
- All the PC member should now be able to see are the submissions initially assigned to him or her.
You as a PC chair can still access all papers and reviews, and via the "Configure" menu, you can also re-enable access (for whatever reason). If you configure the settings as above, though, the risk of data leaks will be greatly diminished.
If you have similar instructions for other conference management systems, let me know and I will link or include them here. And if you as a reviewer find that your conference management system still grants you access to everything, tell your PC chair about this page. Thanks a lot!
2014-10-07
Wie Universitäten die "Industrie vor Ort" unterstützen können: Firmen gründen, statt Firmen nachzueifern
Forscher stehen unter Druck, Probleme der Industrie vor Ort zu lösen. Dies verkennt jedoch die Rolle der Universitäten. Würden Länder und Universitäten aber Firmengründungen besser unterstützen, wäre allen geholfen, meint Andreas Zeller.
Ein Kollege von mir hat sich unlängst an einer deutschen Universität auf eine Softwaretechnik-Professur beworben. Im Bewerbungsgespräch ging es neben zukünftiger Forschung und Lehre vor allem um die Frage, "wie er denn der lokalen Industrie helfen könnte". Die lokale Industrie: das ist ein Mix von mittelständischen Unternehmen, die vor Ort Produkte wie Bleistifte oder Autoteile produzierten. Mein Kollege gab wahrheitsgemäß zur Antwort, dass seine Forschung vorwiegend in der Software-Erstellung eingesetzt werde; er wäre dementsprechend international ausgerichtet. Diese Antwort schien der Kommission aber nicht zu gefallen; und so erhielt er eine freundliche Absage.
Die Frage, "was man denn für die lokale Industrie tun könnte", ist mir als Forscher schon mehrfach begegnet. In Verhandlungen für eine Professur an einer norddeutschen Universität wurden mir stolz die fünf Büroräume präsentiert, die für die "vielen lokalen Projekte" reserviert waren, die ich sicherlich "bald akquirieren würde". Die Landesregierung des Saarlandes hat die hiesige Informatik durch die Blume wissen lassen, dass sie es trotz aller Erfolge der Saarbrücker Informatik gerne sähe, wenn es mehr Kooperationen "vor Ort" gäbe, von denen die "lokale Wirtschaft" profitierte.
Die Forderung nach "Kooperation vor Ort" ist zunächst einmal nachvollziehbar. Hier bin ich, der Leiter eines mittelständischen Unternehmens, und ich habe große Probleme mit meiner IT. Zufälligerweise gibt es nur wenige Kilometer entfernt eine große Universität, voll mit Informatikern, die Ahnung haben. Da liegt es doch nahe, zu fragen, ob die nicht helfen können. Und da die Universität meistens aus Landesmitteln finanziert wird, die zudem aus meinen Steuern kommen, könnte das Land doch entsprechend Druck ausüben, richtig?
Diese Denkweise verkennt jedoch die gesellschaftliche Rolle einer Universität. Universitäten haben zum einen die Aufgabe, Forschung zu betreiben – und sich mit Fragen zu beschäftigen, die in der Regel zu abseitig oder zu risikoreich sind, um damit unmittelbaren wirtschaftlichen Gewinn zu erzielen. Es kann Jahre, gar Jahrzehnte dauern, bis Forschungsergebnisse außerhalb der Universitäten aufgegriffen werden. Immer wieder aber gelingt der eine oder andere Durchbruch, der ohne langjährige freie Forschung gar nicht möglich gewesen wäre, und davon profitiert die Gesellschaft als Ganzes.
Damit die Gesellschaft aber Nutzen von Forschung ziehen kann, müssen Forscher wissen, welche Probleme es zu lösen gibt. Als Informatiker muss ich mich damit auseinandersetzen, wie ich komplexe, vernetzte Systeme sicher und verlässlich mache, wie ich wichtige Daten schützen kann; und ich muss über kurzfristige wie langfristige Lösungen nachdenken. Im Gespräch mit der Industrie bekomme ich einen Eindruck davon, welche komplexen Nebenbedingungen es gibt, und welche Lösungen zumutbar sind; auch dies ist ein wichtiger und wertvoller Teil meiner Forschung. Geht es jedoch darum, die konkreten Probleme "vor Ort" zu lösen, muss ich mich fragen, inwiefern ich aus einer Lösung ein allgemeines Prinzip ableiten kann.
Wäre ich Maschinenbauer in Braunschweig oder IT-Forscher im Silicon Valley, hätte ich vor Ort jede Menge "lokaler" Industriepartner, bei denen dies problemlos ginge – Firmen nämlich, die im Kernbereich meiner Forschung produktiv tätig sind, und die daher meine Interessen teilen, innovative, tragfähige, und möglichst allgemeine Lösungen zu finden. Kümmere ich mich jedoch um die konkreten Probleme der Anwender, etwa der Bleistiftfirma, die ihre IT neuorganisieren muss, geht Zeit und Energie für die allgemeinen Lösungen verloren – und das sind die, die zu finden ich bezahlt werde.
Wenn ich es will, kann ich natürlich "vor Ort" auch mit IT-Anwendern arbeiten. Ich mache einen Schwung Beratungsverträge mit der lokalen Industrie, und stelle billige Doktoranden ein, die dann die Probleme vor Ort lösen (und "nebenher" irgendwie promovieren). Ich generiere jede Menge "Drittmittel" aus der Industrie. Ob dies zu einem allgemeinen Erkenntnisgewinn führt, bleibt hintenangestellt – Hauptsache, die Zahlen stimmen. Will ich das, und warum?
Die zweite Aufgabe der Universitäten ist es, junge Leute zu bilden – oder weniger vornehm, auszubilden. Meine Kollegen und ich haben den Anspruch, Menschen zu produzieren, die die jetzigen und kommenden Herausforderungen der Informatik meistern können. Wir tun dafür, was wir können – und mit Erfolg: Unsere Absolventen können sich in der Regel aussuchen, wo sie arbeiten; und sie gehen dorthin, wo sie die beste Arbeit bekommen. Firmen wie Google oder Microsoft sitzen nicht nur an angesagten Orten, sie zahlen auch sehr gut; und sie sorgen dafür, dass sich unsere Absolventen um nichts kümmern müssen, einschließlich Wohnung, Mahlzeiten und Wifi-Shuttle. Unsere besten Absolventen sind weltweit begehrt, und sie wissen das.
Dies wiederum macht der "lokalen Industrie" zu schaffen, die nicht mithalten kann oder möchte. Ein örtlicher Vertreter einer großen deutschen Telekommunikationsfirma hat mich vor kurzem besucht, und gefragt, wie es denn sein könne, dass so wenig unserer Absolventen sich bei ihnen vor Ort bewürben – schließlich sei es doch eine spannende Herausforderung, das Zusammenspiel von nicht weniger als zwölf Alt- und Neusystemen zu orchestrieren. Ich fragte zurück, ob er mit den Sozialleistungen etwa von Google mithalten könne. Nun ja, sie würden nach Tarif bezahlen, hat er geantwortet, und Essen und Massage – nein, das sei nicht drin. Und da ist das Problem.
(Was das ganze noch pikanter macht, war die Forderung eines IHK-Vertreters, wir mögen unsere Ausbildung weniger international gestalten, damit die Firmen "vor Ort" mehr Chancen hätten, unsere Absolventen anzuwerben. Muss ich das kommentieren?)
Was die lokale Industrie will, ist die Lösung ihrer Probleme. Das ist völlig legitim. Was sie vermeiden möchte, ist einen Marktpreis dafür zu zahlen. Es gibt sehr gute Absolventen, die ein Problem nach dem anderen lösen, doch die kosten Geld – und schlimmer noch, sie verlangen gute Arbeitsbedingungen und das Gefühl, etwas wichtiges zu tun. Es gibt hervorragende Beratungsfirmen, deren Problemlösung man einkaufen kann; doch die kosten noch mehr Geld. Wer fordert, Forscher an den Universitäten mögen doch bitte die Probleme "vor Ort" lösen, verlangt staatlich subventionierte Dienstleistungen – die in Konkurrenz zu Absolventen und IT-Industrie stehen.
Ich habe nichts gegen Subventionen, wenn sie als Investition dienen, also langfristig Gewinn versprechen. Wenn ein Land, eine Universität, aber etwas langfristig Gutes für die Industrie "vor Ort" tun will, und dabei freie Forschung nicht nur nicht behindert, sondern unterstützt, gibt es einen anderen, weit besseren Weg, nämlich aus der Universität heraus Firmen zu gründen. Eine Neugründung kann einerseits spannende Forschungsergebnisse vermarkten, und so Teil der Industrie vor Ort werden. Sie kann aber auch Dienst- und Beratungsleistungen vor Ort anbieten, und so der Wirtschaft weiterhelfen. Eine Neugründung kann sich die Arbeitsumgebung schaffen, die die richtigen Absolventen anzieht. Das Land freut sich über Arbeitsplätze und erhöhtes Steueraufkommen; die Universität profitiert durch Lizenzeinnahmen und einfacherer Legitimation ihrer gesellschaftlichen Relevanz.
Bin ich als Forscher mit einem Startup assoziiert, muss ich mich nicht fragen, wie ich Anfragen der Industrie im Universitätsalltag lösen kann; ich kann einfach auf die entsprechende Firma verweisen. Ich habe ein Ohr an den zu lösenden Problemen, und kann meine Forschung anwendungsnäher gestalten, ohne den Anspruch auf Allgemeinheit aufzugeben. (Wenn dabei eine neue Forschungs- oder Firmenidee abfällt, um so besser.) Und ich kann den Absolventen, die nach ihrem Abschluss weiterhin spannende Arbeit machen möchten, die Startups "vor Ort" empfehlen. Jeder kümmert sich um seine Aufgaben: Die Universität schafft Wissen, das Startup schafft Umsatz.
Wer also "vor Ort" wirken will, soll Firmengründungen unterstützen – zum einen durch Fördergelder, vor allem aber durch das Schaffen von Strukturen, die das Gründen vereinfachen. Dazu gehören Anlaufstellen für Beratung und Information; Netzwerke und Veranstaltungen zum Finden von Mentoren, Mitstreitern und Investoren; bezahlbare Firmensitze in Uni-Nähe; und generelles Werben für die Fortführung der eigenen Ideen in einer eigenen Firma. Spezielle Kurse für Firmengründer. Mix-and-Match-Veranstaltungen zwischen Forschern und Betriebswirtschaftlern. Treffen mit erfolgreichen Gründern. Macht Eure eigene Firma auf – und tut was "vor Ort"!
Eine Universität soll gründen, statt sich selbst als Firma aufzuspielen. Wenn sich dieser Gedanke in den Hochschulleitungen durchsetzt, werden zukünftige Bewerber vielleicht gefragt, ob und wie sie helfen können, Firmengründungen zu unterstützen. Und das wäre nicht das schlechteste.
Andreas Zeller ist seit 2001 Professor für Softwaretechnik an der Universität des Saarlandes, einer EXIST-Gründerhochschule in Saarbrücken. Seine mehrfach ausgezeichneten Test- und Analyseverfahren werden in zahlreichen Unternehmen eingesetzt. Die von ihm 2013 mitbegründete Testfabrik AG, ein Startup zum automatischen Testen von Web-Anwendungen, siegte 2014 im Europäischen Ideenwettbewerb für Startups.
Die Firmengründung wurde durch den Gründer-Campus Saar an der Universität des Saarlandes unterstützt und durch einen EXIST-Forschungstransfer mitfinanziert. Die Firma sitzt derzeit in einem der drei Starterzentren der Universität. Neue IT-Gründungen profitieren zudem vom IT Inkubator der Max-Planck-Gesellschaft und der Universität des Saarlandes.
Ein Kollege von mir hat sich unlängst an einer deutschen Universität auf eine Softwaretechnik-Professur beworben. Im Bewerbungsgespräch ging es neben zukünftiger Forschung und Lehre vor allem um die Frage, "wie er denn der lokalen Industrie helfen könnte". Die lokale Industrie: das ist ein Mix von mittelständischen Unternehmen, die vor Ort Produkte wie Bleistifte oder Autoteile produzierten. Mein Kollege gab wahrheitsgemäß zur Antwort, dass seine Forschung vorwiegend in der Software-Erstellung eingesetzt werde; er wäre dementsprechend international ausgerichtet. Diese Antwort schien der Kommission aber nicht zu gefallen; und so erhielt er eine freundliche Absage.
Die Frage, "was man denn für die lokale Industrie tun könnte", ist mir als Forscher schon mehrfach begegnet. In Verhandlungen für eine Professur an einer norddeutschen Universität wurden mir stolz die fünf Büroräume präsentiert, die für die "vielen lokalen Projekte" reserviert waren, die ich sicherlich "bald akquirieren würde". Die Landesregierung des Saarlandes hat die hiesige Informatik durch die Blume wissen lassen, dass sie es trotz aller Erfolge der Saarbrücker Informatik gerne sähe, wenn es mehr Kooperationen "vor Ort" gäbe, von denen die "lokale Wirtschaft" profitierte.
Die Forderung nach "Kooperation vor Ort" ist zunächst einmal nachvollziehbar. Hier bin ich, der Leiter eines mittelständischen Unternehmens, und ich habe große Probleme mit meiner IT. Zufälligerweise gibt es nur wenige Kilometer entfernt eine große Universität, voll mit Informatikern, die Ahnung haben. Da liegt es doch nahe, zu fragen, ob die nicht helfen können. Und da die Universität meistens aus Landesmitteln finanziert wird, die zudem aus meinen Steuern kommen, könnte das Land doch entsprechend Druck ausüben, richtig?
Diese Denkweise verkennt jedoch die gesellschaftliche Rolle einer Universität. Universitäten haben zum einen die Aufgabe, Forschung zu betreiben – und sich mit Fragen zu beschäftigen, die in der Regel zu abseitig oder zu risikoreich sind, um damit unmittelbaren wirtschaftlichen Gewinn zu erzielen. Es kann Jahre, gar Jahrzehnte dauern, bis Forschungsergebnisse außerhalb der Universitäten aufgegriffen werden. Immer wieder aber gelingt der eine oder andere Durchbruch, der ohne langjährige freie Forschung gar nicht möglich gewesen wäre, und davon profitiert die Gesellschaft als Ganzes.
Damit die Gesellschaft aber Nutzen von Forschung ziehen kann, müssen Forscher wissen, welche Probleme es zu lösen gibt. Als Informatiker muss ich mich damit auseinandersetzen, wie ich komplexe, vernetzte Systeme sicher und verlässlich mache, wie ich wichtige Daten schützen kann; und ich muss über kurzfristige wie langfristige Lösungen nachdenken. Im Gespräch mit der Industrie bekomme ich einen Eindruck davon, welche komplexen Nebenbedingungen es gibt, und welche Lösungen zumutbar sind; auch dies ist ein wichtiger und wertvoller Teil meiner Forschung. Geht es jedoch darum, die konkreten Probleme "vor Ort" zu lösen, muss ich mich fragen, inwiefern ich aus einer Lösung ein allgemeines Prinzip ableiten kann.
Wäre ich Maschinenbauer in Braunschweig oder IT-Forscher im Silicon Valley, hätte ich vor Ort jede Menge "lokaler" Industriepartner, bei denen dies problemlos ginge – Firmen nämlich, die im Kernbereich meiner Forschung produktiv tätig sind, und die daher meine Interessen teilen, innovative, tragfähige, und möglichst allgemeine Lösungen zu finden. Kümmere ich mich jedoch um die konkreten Probleme der Anwender, etwa der Bleistiftfirma, die ihre IT neuorganisieren muss, geht Zeit und Energie für die allgemeinen Lösungen verloren – und das sind die, die zu finden ich bezahlt werde.
Wenn ich es will, kann ich natürlich "vor Ort" auch mit IT-Anwendern arbeiten. Ich mache einen Schwung Beratungsverträge mit der lokalen Industrie, und stelle billige Doktoranden ein, die dann die Probleme vor Ort lösen (und "nebenher" irgendwie promovieren). Ich generiere jede Menge "Drittmittel" aus der Industrie. Ob dies zu einem allgemeinen Erkenntnisgewinn führt, bleibt hintenangestellt – Hauptsache, die Zahlen stimmen. Will ich das, und warum?
Die zweite Aufgabe der Universitäten ist es, junge Leute zu bilden – oder weniger vornehm, auszubilden. Meine Kollegen und ich haben den Anspruch, Menschen zu produzieren, die die jetzigen und kommenden Herausforderungen der Informatik meistern können. Wir tun dafür, was wir können – und mit Erfolg: Unsere Absolventen können sich in der Regel aussuchen, wo sie arbeiten; und sie gehen dorthin, wo sie die beste Arbeit bekommen. Firmen wie Google oder Microsoft sitzen nicht nur an angesagten Orten, sie zahlen auch sehr gut; und sie sorgen dafür, dass sich unsere Absolventen um nichts kümmern müssen, einschließlich Wohnung, Mahlzeiten und Wifi-Shuttle. Unsere besten Absolventen sind weltweit begehrt, und sie wissen das.
Dies wiederum macht der "lokalen Industrie" zu schaffen, die nicht mithalten kann oder möchte. Ein örtlicher Vertreter einer großen deutschen Telekommunikationsfirma hat mich vor kurzem besucht, und gefragt, wie es denn sein könne, dass so wenig unserer Absolventen sich bei ihnen vor Ort bewürben – schließlich sei es doch eine spannende Herausforderung, das Zusammenspiel von nicht weniger als zwölf Alt- und Neusystemen zu orchestrieren. Ich fragte zurück, ob er mit den Sozialleistungen etwa von Google mithalten könne. Nun ja, sie würden nach Tarif bezahlen, hat er geantwortet, und Essen und Massage – nein, das sei nicht drin. Und da ist das Problem.
(Was das ganze noch pikanter macht, war die Forderung eines IHK-Vertreters, wir mögen unsere Ausbildung weniger international gestalten, damit die Firmen "vor Ort" mehr Chancen hätten, unsere Absolventen anzuwerben. Muss ich das kommentieren?)
Was die lokale Industrie will, ist die Lösung ihrer Probleme. Das ist völlig legitim. Was sie vermeiden möchte, ist einen Marktpreis dafür zu zahlen. Es gibt sehr gute Absolventen, die ein Problem nach dem anderen lösen, doch die kosten Geld – und schlimmer noch, sie verlangen gute Arbeitsbedingungen und das Gefühl, etwas wichtiges zu tun. Es gibt hervorragende Beratungsfirmen, deren Problemlösung man einkaufen kann; doch die kosten noch mehr Geld. Wer fordert, Forscher an den Universitäten mögen doch bitte die Probleme "vor Ort" lösen, verlangt staatlich subventionierte Dienstleistungen – die in Konkurrenz zu Absolventen und IT-Industrie stehen.
Ich habe nichts gegen Subventionen, wenn sie als Investition dienen, also langfristig Gewinn versprechen. Wenn ein Land, eine Universität, aber etwas langfristig Gutes für die Industrie "vor Ort" tun will, und dabei freie Forschung nicht nur nicht behindert, sondern unterstützt, gibt es einen anderen, weit besseren Weg, nämlich aus der Universität heraus Firmen zu gründen. Eine Neugründung kann einerseits spannende Forschungsergebnisse vermarkten, und so Teil der Industrie vor Ort werden. Sie kann aber auch Dienst- und Beratungsleistungen vor Ort anbieten, und so der Wirtschaft weiterhelfen. Eine Neugründung kann sich die Arbeitsumgebung schaffen, die die richtigen Absolventen anzieht. Das Land freut sich über Arbeitsplätze und erhöhtes Steueraufkommen; die Universität profitiert durch Lizenzeinnahmen und einfacherer Legitimation ihrer gesellschaftlichen Relevanz.
Bin ich als Forscher mit einem Startup assoziiert, muss ich mich nicht fragen, wie ich Anfragen der Industrie im Universitätsalltag lösen kann; ich kann einfach auf die entsprechende Firma verweisen. Ich habe ein Ohr an den zu lösenden Problemen, und kann meine Forschung anwendungsnäher gestalten, ohne den Anspruch auf Allgemeinheit aufzugeben. (Wenn dabei eine neue Forschungs- oder Firmenidee abfällt, um so besser.) Und ich kann den Absolventen, die nach ihrem Abschluss weiterhin spannende Arbeit machen möchten, die Startups "vor Ort" empfehlen. Jeder kümmert sich um seine Aufgaben: Die Universität schafft Wissen, das Startup schafft Umsatz.
Wer also "vor Ort" wirken will, soll Firmengründungen unterstützen – zum einen durch Fördergelder, vor allem aber durch das Schaffen von Strukturen, die das Gründen vereinfachen. Dazu gehören Anlaufstellen für Beratung und Information; Netzwerke und Veranstaltungen zum Finden von Mentoren, Mitstreitern und Investoren; bezahlbare Firmensitze in Uni-Nähe; und generelles Werben für die Fortführung der eigenen Ideen in einer eigenen Firma. Spezielle Kurse für Firmengründer. Mix-and-Match-Veranstaltungen zwischen Forschern und Betriebswirtschaftlern. Treffen mit erfolgreichen Gründern. Macht Eure eigene Firma auf – und tut was "vor Ort"!
Eine Universität soll gründen, statt sich selbst als Firma aufzuspielen. Wenn sich dieser Gedanke in den Hochschulleitungen durchsetzt, werden zukünftige Bewerber vielleicht gefragt, ob und wie sie helfen können, Firmengründungen zu unterstützen. Und das wäre nicht das schlechteste.
Andreas Zeller ist seit 2001 Professor für Softwaretechnik an der Universität des Saarlandes, einer EXIST-Gründerhochschule in Saarbrücken. Seine mehrfach ausgezeichneten Test- und Analyseverfahren werden in zahlreichen Unternehmen eingesetzt. Die von ihm 2013 mitbegründete Testfabrik AG, ein Startup zum automatischen Testen von Web-Anwendungen, siegte 2014 im Europäischen Ideenwettbewerb für Startups.
Die Firmengründung wurde durch den Gründer-Campus Saar an der Universität des Saarlandes unterstützt und durch einen EXIST-Forschungstransfer mitfinanziert. Die Firma sitzt derzeit in einem der drei Starterzentren der Universität. Neue IT-Gründungen profitieren zudem vom IT Inkubator der Max-Planck-Gesellschaft und der Universität des Saarlandes.
2014-07-07
This day in my history: The 1974 World Cup Final as seen from Beirut, Lebanon
Today exactly 40 years ago, on May 7, 1974, my family and I watched the Football World Cup Final between Netherlands and West Germany on a tiny TV in Beirut, Lebanon. 1974 was the last year before the civil war broke out, and Beirut was still a wonderful post-colonial middle-east city with clear Western (and mostly French) influence; it also was a major tourist destination for Westeners. I remember Beirut as chic, white and golden, the Beeqaa Valley as green and incredibly fertile, and the Roman temples of Baalbek as white and green – it was about the first time my then nine-year old self fully realized the beauty of landscapes and architecture. All the charms and beauty of Beirut would get lost in the 16 years of civil war that would ignite only a few months later, and well-armed soldiers on every major crossing were a sign of things to come.
How would we get to Beirut, you may ask? At the time, my father was a German teacher in Bangui, Central African Republic, and we lived there in a nice house with a lavish garden; every Summer, we would return to Europe, though, and on some of these return trips, we would include stopovers in locations on the way. At the time, the Western and Eastern blocks were still fighting for dominance in Africa, and consequently, the Central African Republic was well-connected – both by Western Airlines (UTA and Air Afrique), as well by Soviet Airlines (Aeroflot). With Aeroflot being cheaper than the others, we would use the saved money for stopovers, which is how we ended up for short trips to Moscow, Russia; Cairo, Egypt; and, in 1974, Beirut, Lebanon.
The flight crew and us were in the same hotel, and my father and the crew had already made acquaintances during the trip from Africa. It turned out that this very day was the finals of the 1974 Soccer World Cup in Munich, with the Netherlands playing against West Germany. The crew also knew that we were Germans – and one of their rooms had a TV! So at breakfast in the restaurant, they approached us and told us that they wanted to watch the finals later today. Would we like to join them? Of course, my parents gladly accepted.
So my sister and I found ourselves in a stuffy Beirut hotel room with our parents and a Russian flight crew, in front of a tiny, blurry, black and white TV screen with the audio in a language I did not understand (Arabic? Russian?). It was even hard to distinguish the teams, although the light grey team seemed to be the Germans, and the darker grey team seemed to be the Dutch. And I occasionally got the words "Beckenbauer" and "Cruyff", whom I identified as the main protagonists of their respective teams. On every goal shot, vodka bottles were passed, and the crew's eyes got more and more watery. The game lasted for 90 minutes, and at the end, the Germans won.
At this time, I was a nine-year old boy, and you might think I would have been super enthusiastic about watching the World Cup Final, captured by the game, and knowing each single player in the team. Unfortunately, this wasn't the case. Having spent the past year in Africa, I knew nothing about German football, its teams, or its players; nor did I know how the world cup went so far. All the news we had were a weekly news magazine, Der Spiegel, which normally would arrive one to three weeks late; occasional short-wave radio news; and French Newsreels, to be shown in the local cinemas.
Still, I was glued to the screen, like my parents, like the crew with their wide open, bright blue eyes. But in this moment, what I found thrilling was not so much that Germany was just about to win the World Cup. It also wasn't that I was in a hotel room in Beirut with a bunch of Russians on my way back from Africa. It was that I was looking at real live TV.
How would we get to Beirut, you may ask? At the time, my father was a German teacher in Bangui, Central African Republic, and we lived there in a nice house with a lavish garden; every Summer, we would return to Europe, though, and on some of these return trips, we would include stopovers in locations on the way. At the time, the Western and Eastern blocks were still fighting for dominance in Africa, and consequently, the Central African Republic was well-connected – both by Western Airlines (UTA and Air Afrique), as well by Soviet Airlines (Aeroflot). With Aeroflot being cheaper than the others, we would use the saved money for stopovers, which is how we ended up for short trips to Moscow, Russia; Cairo, Egypt; and, in 1974, Beirut, Lebanon.
The flight crew and us were in the same hotel, and my father and the crew had already made acquaintances during the trip from Africa. It turned out that this very day was the finals of the 1974 Soccer World Cup in Munich, with the Netherlands playing against West Germany. The crew also knew that we were Germans – and one of their rooms had a TV! So at breakfast in the restaurant, they approached us and told us that they wanted to watch the finals later today. Would we like to join them? Of course, my parents gladly accepted.
So my sister and I found ourselves in a stuffy Beirut hotel room with our parents and a Russian flight crew, in front of a tiny, blurry, black and white TV screen with the audio in a language I did not understand (Arabic? Russian?). It was even hard to distinguish the teams, although the light grey team seemed to be the Germans, and the darker grey team seemed to be the Dutch. And I occasionally got the words "Beckenbauer" and "Cruyff", whom I identified as the main protagonists of their respective teams. On every goal shot, vodka bottles were passed, and the crew's eyes got more and more watery. The game lasted for 90 minutes, and at the end, the Germans won.
At this time, I was a nine-year old boy, and you might think I would have been super enthusiastic about watching the World Cup Final, captured by the game, and knowing each single player in the team. Unfortunately, this wasn't the case. Having spent the past year in Africa, I knew nothing about German football, its teams, or its players; nor did I know how the world cup went so far. All the news we had were a weekly news magazine, Der Spiegel, which normally would arrive one to three weeks late; occasional short-wave radio news; and French Newsreels, to be shown in the local cinemas.
Still, I was glued to the screen, like my parents, like the crew with their wide open, bright blue eyes. But in this moment, what I found thrilling was not so much that Germany was just about to win the World Cup. It also wasn't that I was in a hotel room in Beirut with a bunch of Russians on my way back from Africa. It was that I was looking at real live TV.
2014-07-02
if you plan to invite me for your upcoming event, please avoid nightmares like this one
I frequently get invitations to give talks at conferences, summer schools, and other events. Normally, it is an easy thing: I check my availability, agree, book travel and hotel, prepare and give a talk, have fun, get reimbursed. Not so with this recent summer school in France, though.
January. I get an invitation to lecture at a summer school in France. Sounds fun and exciting, but it is in our exam week. I go for a compromise: I accept, but will be able to join only for one day. As usual, I don't get paid for such events, but the trip will be taken care of.
February. The organizers ask all speakers for a flight connection, such that they can book a flight for us. I spend an hour looking up possible flight connections on Expedia, only to find that the plane will be cumbersome and expensive. I send the quote, adding that going by train will be cheaper and faster, an assessment shared by the organizer.
February. The summer school asks me for a quote of the train ticket. This is not possible yet, as the ticket can only be booked three months in advance. I give an approximate price based on next month's connections.
March. I send title and abstract and state my availability for the lecture (Tuesday or Thursday). Everything is fine.
April 17. The summer school produces a flight itinerary and asks me to confirm the booking. Flight? I reply stating that we already agreed to have me travel by train; I again retrieve and provide a quote for the train ticket. As the flight itinerary assumes that the talk be on Wednesday (which does not fit me), I ask that my talk be moved according to my availability. The organizers agree.
April 17. In return, the summer school produces a train itinerary, again asking for confirmation. The itinerary also assumes my talk is on Wednesday. I cannot confirm the itinerary, repeating that the date does not suit me and that my talk date will be moved to either Tuesday or Thursday.
April 22. I get a tentative program, where my talk is scheduled on Wednesday morning. This is the day on which I am not available, and I curse between my teeth. I again ask for the talk to be rescheduled. The organizers apologize for their mistake and schedule my talk for Thursday.
April 29. I get an electronic train ticket. This booking is still the same itinerary as on April 17, assuming my talk would be on Wednesday. I am pretty upset and state that the ticket neither fits my schedule nor the revised schedule of the summer school. Rather than exchanging more mails, I suggest I book the ticket myself, saving time and money.
April 30. The organizers apologize for their confusion, and ask me to please book a ticket myself.
April 30. I book a train ticket on the SNCF site. This takes me 10 minutes. I send the itinerary to the organizer, who again apologizes. All seems to be set.
May. The administration asks all speakers for bank account information, address, and passport copy, which I all provide.
June 5. I get a hotel voucher for my stay.
June 27. The organizers ask all speakers for rechecking the information on their Web site. I am busy in a PC meeting and postpone the check for a few days.
July 1. The organizers urgently ask me if it would be okay for me to chair a session on Wednesday morning. Wednesday? I will be traveling on Wednesday morning, so no. I remember the earlier message to recheck all information. It turns out that on the Web site, my talk is still scheduled on Wednesday, and my hotel is booked wrongly, too. As I realize this, I jump up and scream, literally banging my head against the wall; my secretary comes in and asks whether everything is okay.
July 1. As I cool down, I write to the organizers. I repeat my travel details and for the last time, ask the organizers to reschedule my talk as confirmed multiple times. The organizers again deeply apologize for the confusion and promise that the schedule will be fixed.
July 2. [Update] I cancel my participation, wishing all the best to the summer school, and bearing the ticket expenses myself. I feel relieved and relaxed. All is well that ends well.
Lesson learned #1: While this trip has easily caused me more trouble than all my other trips combined, let me state that almost all of my business trips are painless, including all my trips to France so far. Also, other lecturers at the same event report that their booking all went well, so I guess I just had a long series of unfortunate events which is not typical for France at all.
Lesson learned #2: If you organize an event, make sure you have a single point of contact – there should be precisely one person to talk to the invitees, who keeps track of all information and (possibly) interacts with the administration. Do not have your administration interact with the invitees directly, bypassing you; likewise, keep the administration updated at all times.
January. I get an invitation to lecture at a summer school in France. Sounds fun and exciting, but it is in our exam week. I go for a compromise: I accept, but will be able to join only for one day. As usual, I don't get paid for such events, but the trip will be taken care of.
February. The organizers ask all speakers for a flight connection, such that they can book a flight for us. I spend an hour looking up possible flight connections on Expedia, only to find that the plane will be cumbersome and expensive. I send the quote, adding that going by train will be cheaper and faster, an assessment shared by the organizer.
February. The summer school asks me for a quote of the train ticket. This is not possible yet, as the ticket can only be booked three months in advance. I give an approximate price based on next month's connections.
March. I send title and abstract and state my availability for the lecture (Tuesday or Thursday). Everything is fine.
April 17. The summer school produces a flight itinerary and asks me to confirm the booking. Flight? I reply stating that we already agreed to have me travel by train; I again retrieve and provide a quote for the train ticket. As the flight itinerary assumes that the talk be on Wednesday (which does not fit me), I ask that my talk be moved according to my availability. The organizers agree.
April 17. In return, the summer school produces a train itinerary, again asking for confirmation. The itinerary also assumes my talk is on Wednesday. I cannot confirm the itinerary, repeating that the date does not suit me and that my talk date will be moved to either Tuesday or Thursday.
April 29. I get an electronic train ticket. This booking is still the same itinerary as on April 17, assuming my talk would be on Wednesday. I am pretty upset and state that the ticket neither fits my schedule nor the revised schedule of the summer school. Rather than exchanging more mails, I suggest I book the ticket myself, saving time and money.
April 30. The organizers apologize for their confusion, and ask me to please book a ticket myself.
April 30. I book a train ticket on the SNCF site. This takes me 10 minutes. I send the itinerary to the organizer, who again apologizes. All seems to be set.
May. The administration asks all speakers for bank account information, address, and passport copy, which I all provide.
June 5. I get a hotel voucher for my stay.
June 27. The organizers ask all speakers for rechecking the information on their Web site. I am busy in a PC meeting and postpone the check for a few days.
July 1. The organizers urgently ask me if it would be okay for me to chair a session on Wednesday morning. Wednesday? I will be traveling on Wednesday morning, so no. I remember the earlier message to recheck all information. It turns out that on the Web site, my talk is still scheduled on Wednesday, and my hotel is booked wrongly, too. As I realize this, I jump up and scream, literally banging my head against the wall; my secretary comes in and asks whether everything is okay.
July 1. As I cool down, I write to the organizers. I repeat my travel details and for the last time, ask the organizers to reschedule my talk as confirmed multiple times. The organizers again deeply apologize for the confusion and promise that the schedule will be fixed.
July 2. [Update] I cancel my participation, wishing all the best to the summer school, and bearing the ticket expenses myself. I feel relieved and relaxed. All is well that ends well.
Lesson learned #1: While this trip has easily caused me more trouble than all my other trips combined, let me state that almost all of my business trips are painless, including all my trips to France so far. Also, other lecturers at the same event report that their booking all went well, so I guess I just had a long series of unfortunate events which is not typical for France at all.
Lesson learned #2: If you organize an event, make sure you have a single point of contact – there should be precisely one person to talk to the invitees, who keeps track of all information and (possibly) interacts with the administration. Do not have your administration interact with the invitees directly, bypassing you; likewise, keep the administration updated at all times.
Subscribe to:
Comments (Atom)