Table of Contents The SpiderOak Mobile Client Open Development Project What's All This, Then? Project Plans Application Implementation Why Open Source? Open Development Process How Can I Get Involved?

SpiderOak is working on its next-generation, HTML5-based mobile client in an open development process. We consider this mobile client to be SpiderOaks' mobile future, and open source to be the best development avenue. (It well may be a key part of our desktop client future, as well).

Our first milestone for the open project was establishing the open project, itself. This document, and a blog posting based on it, are the remaining steps - in order to consider the open development process *started*.

The first major release milestone is to replace the existing native-code iOS and Android mobile clients, including most or all of the existing functionality. We are aiming for an end-of-the year deadline.

Once the current native mobile clients are replaced, our aim is to implement the full functionality in this mobile client that you find in our desktop clients, and more. This includes the ability to read from and write to the local device filesystem, in order to synchronize, share from, and backup the devices. We will also include other secure collaboration features that are emerging in our service at time of writing.

We aim to implement as much functionality as possible in HTML5 / Javascript, and have signs that some substantial cryptography functionality can be done at that level (well before the HTML5 security standards are anywhere near implementation).

The application is primarily implemented as HTML5 / CSS / Javascript. Native functionality that is not yet available via the pure HTML5 approach is implemented using an open hybrid facility, PhoneGap.

We maintained a substantial description of the architecture, and other technical details, as these details were implemented: HTML5 Client Code - Technical Details. This is the canonical guide to the application code, providing an extensive overview of the architecture, build provisions, and other technical details.

Simply enough, we want to make our mobile client more immediately and thoroughly accessible to those interested. We want you to have access to, and be able to participate in and help shape that development, as it proceeds.

Ultimately, we want this work to be as useful as possible for people who depend on SpiderOak, and also to others who have are concerned with the development of the constituent technologies. The mobile client is about enabling access to our services. We want to maximize that access, and make it easier for interested parties not just to use the services, but to contribute suggestions and complaints, documentation, and even fixes and enhancements, as development is happening.

Further, some of the functionality we plan to implement will rely on innovations, like Javascript-based cryptography, that will be most useful to us, as well as to others, if they can be taken up and strengthened by widespread use. An open development process can be crucial to promoting that kind of action.

More generally, SpiderOak's founders and the team members they've gathered have strong open source backgrounds. Open source applications play key roles in many aspects of SpiderOak's operation. SpiderOak depends on open source in key ways, and have made some essential technologies openly available since the start. We are continuing to increase the depth of our involvement by releasing key technologies in the open, like nimbus.io, and by conducting development of this mobile client in the open.

As a company, releasing the client fits with the model described by Tom Preston-Warner's GitHub screed, Open Source (Almost) Everything, fitting into the category of things that best serve us - as a company, and as committed, enthusiastic developers - as open source.

SpiderOak will lead development of the client. We are not just throwing the code over the wall. We have a developer who will continue to be dedicated to the task, just as before we established it as open source.

In the style of some of the best open development processes (one of our favorites, Python, for example) we are reserving "benevolent dictator" discretion in conducting the effort. That said, our plan is to maintain maximum transparency, using the repository issue tracker for organizing project tasks and the repository wiki for documentation.

For our collaboration methodology, we are subscribing to the Fork & Pull collaborative development model, better suited to a wider collaboration process than the Share Repository model.

We chose the Apache License, v2 for a variety of reasons, covered in this tracker issue. Briefly, a permissive license is suitable to maximize proliferation, and the Apache 2 license maturity, popularity, and incidental compatibilities generally fit our purposes.

There are many things that pending, including some infrastructure to makes trying it out easy. At this point, you have to run from local files in order to exercise it, and that requires special browser provisions. (We hope to soon establish a facility so people can try the latest version of the code from a regular browser session. People wanting to work on the code will need to run from local files, for expedience.) We can use suggestions, feedback, and contributions for many aspects of the application:

Technical testing and feedback

Try it out, register issues

Documentation and general conduct suggestions and questions

The documentation needs proofreading for simple mistakes and more general comprehensibility, coverage of missing stuff, etc, etc.

Coding

Contribute - Fork & Pull

Code review, suggestions, questions

Tests!!

Convert method comments to formal scheme

... ... ...!