Interview with Stefano Fornari – CTO

Interview with Stefano Fornari – CTO – Funambol

Interviewers: Scott Swigart and Sean Campbell

Interviewee: Stefano Fornari

In this interview we talk with Stefano the CTO of Funambol. In specific, we talk about:

Sean Campbell: Give us a little bit of background on you and on the company.

Stefano: All right. I am a cofounder as well as the current CTO of Funambol (the company). We started out in Italy at the end of 2002, and a while later Fabrizio, the CEO, relocated to the US to found the corporation, where the headquarters of Funambol is currently located. I am the current CTO.

Before that, I worked for a couple of years in a company called ATG, which at that time developed an application server. I was based in Reading, which is a little town close to London, and I acted as consultant for the region.

Before that, I had a very short experience with Compaq in Italy, during a period when they wanted to branch out into professional services on the software side. It was a very good experience for me to get familiar with mobile devices such as PDAs and so on, and I quickly became a reference for that kind of technology within Compaq in Milan.

Before Compaq, I worked at a software house in Italy that developed websites and stuff like that. That company was co-founded by Fabrizio, and I was actually an employee there.

Scott Swigart: Tell us a little bit about the open source project that you’re working on and what the software does.

Stefano: When I was working in ATG, Fabrizio and I had been thinking about what technology would be most important in the next five to ten years. We wanted to start a company that would innovate around that technology.

We wanted to be innovative in many ways–not only in terms of the technology itself, but also about how to develop software, and about the business model. Of course, one of the most evident technology directions at the time was mobile computing.

When we started to think about mobile computing and requirements we could meet to help drive its future, it became evident to us that mobile phones need to have local data storage to run their applications.

A very simple example is the address book, because at that time, but even today, you want to make sure that your phone applications continue to work smoothly, regardless of whether or not it has network connectivity. You must also make sure that your application doesn’t break dramatically if you run out of battery.

Thinking along those lines, we recognized that most applications will be mobilized, so we need a framework to make it possible for those applications to have a local database on the mobile phone, and that they can synchronize with a server.

The server, then, can in turn synchronize data with many other things, including Outlook, CRM, or an enterprise application server. As we moved forward, the first thing I researched was whether there was already a technology or a product to provide this service, or whether we should start from scratch.

At that time, the SyncML protocol had just kicked off, which is basically a synchronization protocol that attempted for the first time to standardize data synchronization among different sources.

After a while, that protocol was adopted by the OMA–the Open Mobile Alliance–which is one of the most important standardization bodies in the mobile area. Since there was already a protocol in place, we decided not to start from scratch and reinvent the wheel. We just needed to implement that protocol, so we focused on how we wanted to do that.

Open source was starting to become more visible and prevalent, and Fabrizio and I had always been very supportive of open source, so we decided to go that route to implement the protocol.

That was the real origin of the product, and today, the open source project has two primary parts. There’s a synchronization platform with a server side component that we like to call a mobile application server, and there’s a client component for the devices that have a SyncML client on board.

On top of these, we developed over time a more complete application suite, and today we have what we call a MobileWe, the open source and multiplatform MobileMe. It is a kind of Apple Mobile Me, but open source, with support for a very broad variety of devices.

Scott: You mentioned a client side portion. Does it include a client type database or is it really more focused on the sync protocol on the server side?

Stefano: Today, we are most concerned with synchronization. That is the reason we mainly took the approach of trying to integrate with existing applications on the mobile phone.

We synchronized the data that those applications already stored in the database. There is one remarkable exception, which is a J2ME email client,which instead implements a full email client for Java mobile; in this case, we could not count on an existing application into which we could plug in, and we developed the storage too.

Scott: What are some of the key applications?

Stefano: Mostly the PIM and email applications that are on the phones–calendar, email, tasks, and usually also notes.

Scott: Tell us a little bit about the server-side component of this and what that synchronizes out to.

Stefano: SyncML is a data-agnostic synchronization protocol, so you can really synchronize everything you want with that one protocol. In fact, our SDKs–both on the server side and the client side–also allows you to begin an application from scratch that is able to synchronize with whatever you want.

In a complex server deployment, the server will consist of many blocks. First of all, we have the data synchronization service, which is physically the block that receives the SyncML requests. This component also includes the synchronization protocols, the synchronization logic, and the connector architecture that allows us to delegate to connectors the actual access to the data.

This allows developers to develop their own connectors, without knowing anything about synchronization or mobile phones. They just implement a very simple Java interface that will be called when the synchronization takes place.

This connector architecture allows the decoupling of synchronization logic from the data access logic technology. We implemented our own connectors for our PIM personal information management database and email.

These will be enough for a simple synchronization scenario.

Scott: I imagine that synchronizations become much more interesting when you introduce the push side of the synchronization.

Stefano: That’s correct. This aspect allows us to make the synchronization completely invisible to the user. It means that if the user changes something on the device, the change is automatically synchronized to the server. If something changes on the server, the change is automatically synchronized to the device. That’s the part that is more interesting.

These are what we call the client server push, which is automatic synchronization from the client to the server, or server to client push, which is the synchronization from the server to the client. In order to achieve this synchronization, we need additional components that are able to detect that there are changes into the backhand.

We call these component listeners, and out of the box we provide the ready made email listener, which we call the Inbox Listener Service. This service is able to monitor user’s inboxes and detect when there are new emails.

There is another service called the PM listener service, which detects changes in our PIM database. When one of these two listeners detects a change, they know to which user the change relates, and they tell the Data Synchronization service to notify the clients used by the user, that there is something new to synchronize. This notification could be done in many ways. It’s very dependent on the kind of device, because different devices and operator networks have different capabilities.

Scott: What are the mechanisms that initiate these server-to-client push actions?

Stefano: We have three ways of doing it. The first is through SMS. If you are an operator, you already have a way to send SMSs, so we can send an SMS as a trigger to start a new synchronization.

Most of today’s mobile phones have a SyncML client on board, so we don’t have to install any software on them. They work out of the box with SyncML and usually also have this kind of notification implemented.

When this type of solution is not implemented, as in the case of Windows Mobile to take a very common example, we provide our client software that is able to address the other two types of server to client push: connection oriented push and connectionless oriented push.

Connectionless oriented push is when the device is able to start in a TCP/IP listener on a particular port and the operator network gives to the device a routable IP address: in other words, an IP address that the server is able to access directly.

If this is possible, then the server connects to the client and delivers the notification. This is our preferred way of doing push, because it’s least demanding on the battery since it doesn’t keep any connection open. When there’s something new, the server connects to the client and tells the client to start the synchronization.

The drawback of this method is that the IP address of the client must be addressable from the server, and not all networks give devices an IP address that is routable. It may not be a public IP address, there might be a firewall in the middle, or in the case of a WAP connection, there might be a gateway in the middle.

In those cases, you are not able to connect the device directly, so our client starts a connection to the server and keeps it open, so that the server can write the notification package when there is something new. The client keeps the connection open in a read mode, and when it reads the notification sent by the server, it can start the new synchronization.

In order to do this, there’s an additional component called the Connection oriented push service, which the client connects to.

Scott: Now that we have that architectural description in place, let’s switch gears a bit and talk about the open source nature of the project. How much of it is developed by you as a company versus by the community? What benefits do you get from having the project be open source?

Stefano: We get many benefits from the open source community, particularly with regard to the mobile space. We serve a big variety of devices and operators in different countries and so on.

One of the most important benefits that we get from the community is people using the software all over the world. They test our software in many countries, and they report issues and successes.

In a more traditional company, you would have to either test in every country or pay a lot of money to one of those mobile testing houses that have a pretty good coverage of the many different environments.

Another area of benefits, of course, is to the code itself. We have gotten very significant contributions, even though I would say that the majority of the code is still from employees.

Of course, that fact is partly because in many cases, people make those contributions after we’ve hired them, using the project as a sort of recruiting mechanism. It’s been a great help in finding and selecting people that want to work with us.

We had very remarkable contributions from developers that wanted to develop something on their own and found something useful in our software, so they contributed to our software–in particular on the client side–to improve the client SDK for example, or to port it to different platforms.

We also get great contributions from companies that are using our software and that want to contribute back code that they have built; they want to work to develop features together with the community.

So you see, the benefit is not only the code that is being contributed, but it is also building an ecosystem around the core of the project. We have a whole architecture that includes the connectors and so on, so people can build different applications based on some pieces of our code.

When people who use our software help us to validate it in another environment, we also consider that a contribution. They use it; they test it, and they help us improve it.

Scott: One of the areas where open source does really well is where there are lots of variables such as different devices and carriers. It would obviously be very difficult, if not impossible, for one software company to support all of those combinations.

You’ve got a great community that really helps test all of those different cases and contribute to the code, and of course, a lot of times it isn’t a major change to get it to support something else. Do you find that someone can contribute a lot to the project by doing just a little bit of work to get it to work better for a particular device?

Stefano: Absolutely, that’s the way we see it, and at Funambol, we try to encourage that as much as possible.

For example, we launched a program that we call the “device sniper,” where we give a very small amount of money to people to test a specific device based on a test script that we provide and to report back to us. This approach has worked well, and we have found a number of issues.

Scott: When someone contributes a patch, how is it looked at to determine whether it is of sufficient quality to be included?

Stefano: For small contributions, patches, and stuff like that, we ask people to file the bug and attach the fix as a patch file (a diff) so that it can be reviewed and then maybe integrated into the trunk.

The core developers review the patch, and if it’s good, they just include it into the trunk; if not, they ask the contributor to make the changes that they think are needed.

For larger changes, the process could be similar, but in that case, the core team will be more interested in having the contributor stay around and maintain it. In some cases, that type of contributor even becomes one of the core developers of the project.

In cases of those larger changes, we need to work much more tightly with them, and so they have to be much more active. They have to present their proposed changes more deeply, and they have to discuss with the other developers the associated design and architectural changes.

When they have developed the trust of the core developer team, we give them the write access to the code repository so they become part of the enlarged team that works on the code, and they can contribute directly into the trunk.

It is a very meritocratic process. Once we see that someone is really committed to the project, and that we share a common set of goals, they can make the transition to become core developers.

Scott: Synchronization in general is a hard problem. There’s a lot of logic that goes into synchronization, especially to handle issues like what to do if the same thing has been changed on both ends. Talk a little bit about some of those challenges.

Stefano: I’m glad you ask, because I think that some people have the perception that synchronization is an easy thing. Assuming it works properly, of course, at the end your address book in Outlook matches the address book on your phone, and so you take it for granted. Working seamlessly just means that it works well, though, and not that it is simple.

There is actually a great deal of complexity in doing this well, because you must not lose data nor create duplicates. Some challenges are related to the protocol itself, and others are due to different interpretations of the protocol or even with bugs that the phones may have.

In order to address this challenge, we implemented what we call the synclet technology. Before incoming SyncML messages get processed by the synchronization engine, they pass through what we call an input synclet pipeline.

The pipeline is basically a pipe of synclets that are executed based on the specific phone that is synchronizing. It gives us a hook to attach specific processing for a specific device. Thus, for example, if we know that a particular device has a bug in handling the addition of new items, then we can fix some of those things into a synclet.

We basically can do the same in output for outgoing messages, so we have an output synclet pipeline as well, such that if we send a message to a device and we know that a particular device, for example, interprets the protocol differently from others, we can fix the message before it gets sent to the mobile.

The same is true for the representation of contacts, for example, or events. There are standards, but there are also different interpretations, as well as bugs. For instance, a vcard may work on one phone but not be accepted by another phone. We fix this kind of thing in our pipeline.

Scott: What about issues around the actual data on the phone? For example, what if I have the contact “Stefano” on my mobile phone and “Stefano” in Outlook?

Stefano: That does happen, and moreover, when you synchronize different devices into a single address book, we need to detect what is actually the same information, even if there are different data.

That’s challenging, because for example, you may detect a person that has the same or a very similar name, but they are not the same person. You might also have different data for different people, such as a home phone number and a mobile phone number.

There are a number of challenges here that people usually don’t see, but that are quite interesting.

Scott: Synchronization has always struck me as a very complicated engineering challenge with a lot of problems that there aren’t necessarily great answers for. Thanks a lot for taking the time to chat with us about what you do and about the project.

Stefano: Thank you.

Bookmark this: