You can find the packages on the download pages of the Kolab Sync for Outlook und Kolab Sync for Android projects.

Please use the issue trackers there for feedback.

Using this software you will be able synchronize your contacts and calendar to any IMAP folder. Every item is saved in a separate Email using the Kolab Storage Format. This allows for interoperability with other Kolab Clients.

Please join us on the Google code projects for the Android and the Outlook connectors.

Since there are still quite a few rough edges, this is only a developer preview to publish the already done work. Read on for a more detailed status of the development so far.

Status

• Sync Infrastructure: although the two projects are written in Java and C#, they share the basic algorithms and principles of operation. This groundwork is also shared between the addressbook and contacts synchronizers of each project. This is already stable. Some edge cases still require a second synchronization run to converge.
• Addressbook Synchronization: being the easier part of the two, this is mostly finished and working.
• Calendar Synchronization: Arthur is currently implementing the last piece here: reading and writing of recurrences.
• Managing Edit Collisions: If two copies of the same item are edited and then synchronized, there is no easy way to automatically manage the merge. On the Android the server item always wins. For the Outlook plugin we plan on implementing a conflict resolution dialog where the user can pick and choose from the conflicting items.
• Managing Duplicates: When starting to use synchronization tools, users often end up with multiple copies of the same entries (especially in the addressbook) when multiple data sources are added. Currently the only way to work around this problem is to use a third-party duplicate-detector or wipe all but one device clean before synchronizing. A way to handle this could be added similar to a edit conflict resolver.
• Multiple Calendars, multiple IMAP Folders: planned.
• Testing: Currently there are only manual test routines.

[2009-10-16 15:02:09 - ddms]Failed to reopen debug port for Selected Client to: 8700
[2009-10-16 15:02:09 - ddms]Address family not supported by protocol family: bind
java.net.SocketException: Address family not supported by protocol family: bind
	at sun.nio.ch.Net.bind(Native Method)
	at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
	at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
	at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
	at com.android.ddmlib.MonitorThread.reopenDebugSelectedPort(Unknown Source)
	at com.android.ddmlib.MonitorThread.run(Unknown Source)

[2009-10-16 16:29:40 - ddms]Can't bind to local 8600 for debugger
[2009-10-16 16:30:14 - ddms]Can't bind to local 8601 for debugger
[2009-10-16 16:30:14 - ddms]Can't bind to local 8602 for debugger
[2009-10-16 16:30:15 - ddms]Can't bind to local 8603 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8602 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8606 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8607 for debugger
[2009-10-16 16:30:25 - ddms]Can't bind to local 8610 for debugger

As it turns out, the debugger tries to connect to “localhost” which is resolved by Windows Vista via the Windows\System32\drivers\etc\hosts file, which contains the IPV6 address “::1″. Since Android’s IPv6 support is still under development, none of the development tools can cope with it, resulting in above error messages.

Substituting the IPv4 127.0.0.1 as localhost address made it work fine.

Reasons for going Open Source

• Better product
• real relationship with users
• PR
• goodwill from techies
• gratis contributions
• disrupt market (especially if product is good)

Community Health

Without a community, a project is only dead text. Important indicators for the health of a project are the usage, but not the number of one-time evaluation downloads, the number of active developers, and a constant flow of improvements and releases.

How to make it right

First Ben and Fitz’ talk about the different models how corporate Open Source projects are initiated. The biggest problem they identify: control. Without relinquishing control to the community, there is no common trust base built. But this trust base is the thing that attracts high quality contributors. Therefore they recommend to really create a separate organisation to govern the project.

A example: Ben and Fitz worked for Collabnet, the primary sponsor and founder of the Subversion project. When Collabnet hires a new programmer to work on Subversion, he had to submit patches to the mailing list for review and “prove” himself to the community before receiving commit rights. Doing it any other way would alienate contributors from outside of the company, since they are under privileged now. Going the long way for employees too, sends a message that everyone can join the community and eventually receive commit rights. This creates a trusting environment.

Word of warning

While opening the development process brings strong long-term benefits, it has to be said too, that no short term improvements should be expected. Also, founders must pay attention that the goals of the company and the community are aligned and stay that way. This can be facilitated by writing an up-front mission statement which acts as a filter for all parties.

When hiring new programmes to work in the project special care has to be taken, that they can integrate into the community and are able to work in the greater team.

Good Feedback == Improved Productivity

Using Fitz’ words: “If they’re running the wrong code, it doesn’t matter how much they are writing.” (19:30) The tight feedback loop and direct contact with users in open source projects focusses developers much more on the really needed features and really troublesome bugs.

“Build Your Community”

Under this heading, the two gave tips and tricks how to build a successful open source community. The most important factor seems to be the right choice of founding members and the establishment of a strong, respectful culture.

A successful project needs goals to attract users and contributors. Typically the founders benefit from these goals only indirectly and in the long run. To help attract the right people, a published mission statement is important. The statement should clearly communicate the core ideas and focus the community members by defining a scope.

Another important step is the preparation of the founding team (especially developers). Ben and Fitz recommend the Producing Open Source Software book from their former colleague Karl Fogel. Beside the obvious points, like communicating the structure and mechanisms of the new community, it is important to get the developers to realize that external feedback is intended to improve the product and is no personal attack.

The neccessary public infrastructure is at least a mailing list, a repository and a bug tracker. Internal mailing lists are dangerous, because they undermine the community trust and prohibit communication of internal efforts to the public. For the public mailing lists, it’s important to start with only one list to focus communication and contributors.

After the setup of the infrastructure, the last step is to publish the project and create interest in the various pertinent media to attract developers and users. As one of the very few shortcomings of this talk, they glossed over this topic only very superficially.

Conclusion

A interesting and funny talk about the genesis of open source projects in the commercial context. Packed full with tales and practical recommendations, Ben and Fitz navigate the listener through the challenges of such a founding.