After 10 years, I'm stopping my work on sabre/dav
March 9, 2017
Almost 10 years ago in 2007, I started a project called sabre/dav. I originally was looking to scratch an itch and solve a real problem we had in our company.
A lot of people ended up being pretty excited about it. In 2010 I got to a point where doing consulting around this project allowed me to travel around the world, working for various companies and get paid enough to not have to do any other jobs. Life was pretty good! One of these gigs actually brought me all the way to a beach in Australia! (Thanks Ben!)
In 2012 plenty of businesses relied on this project for either a side-feature, or at the heart of their product, including various ISP’s, product companies and open source vendors like Owncloud.
At this point I started working with Dominik Tobschall and we opened the doors to a business named fruux in Munster, Germany. We got a bunch of funding and we would try to build a consumer and small-business product. Fruux also used sabre/dav at it’s core for synchronization and became the owner of the project.
I also started working with CalConnect to help drive forward the actual calendaring and scheduling standards that sabre/dav and many other vendors implement. It was really awesome to work directly with the people behind Apple’s iCal and iCloud, Mozilla’s Lightning (hey Philipp!), Google Calendar and many other industry leaders. Instead of just being disgruntled about a bug (or feature) I could just ask the developers directly and work things out together!
We were unable to grow fruux quickly enough, so in 2014 we made a pivot and try to focus on professional services around sabre/dav. We got burned with the incredibly long sales cycles, so later in 2015 we had to wind this business down and find alternative income streams while still passionately working on this project.
Pictured above: the original fruux team
Unfortunately over time the alternative income streams slowly became the main ones leading me to September 2016, in which I started a new full-time job at a company in Toronto called Turnstyle. It’s a great change of pace after having worked remotely and contracting for half a decade.
This leads me to today. I recently read a blog post titled “What it feels like to be an open-source maintainer” by Nolan Lawson, which kind of hit home. This made me realize that after nearly 10 years, my work on this project has turned from something I was very excited about into something a bit more like a chore.
I’m not really using my own project(s) anymore. I don’t get paid, but I’m really the only maintainer. Lots of businesses depend on it, there are lots of open bug reports, feature requests and pull requests but I can’t find the time and motivation to work on it. According to packagist, it’s been downloaded 27000 times in the last 30 days. I think I would still love it if it were my full-time job and I had coworkers also working on it, but it all comes down to me.
This has caused two big effects:
- I feel constantly guilty that I don’t work on these things. There’s people waiting on me and making reasonable requests, but I just can’t seem to get it done.
- This guilt is preventing me from starting new things that excite me, because I feel bad starting the next thing if I haven’t finished the last.
It was a gut-feeling that took a while to sink in from around January. I finally realized that I need to make a change. This is pretty personal and emotional and it sucks to have to make this decision.
So, starting today:
- I resigned 100% from fruux
- I resigned from CalConnect
- I’m shutting down the sabre/dav mailing list (go to github instead)
- I’m looking for new maintainers
The affected projects are:
I’ll continue to maintain the following three projects because they are simple and small:
For the first 5 I’m looking for suitable new maintainers. I do care about the future quality of these projects, so I won’t just hand it over to anyone. If you’re interested, let me know what you’re planning to do with it. I’ll probably hang out and guard quality control for a while before I fully step down, but I am more than happy to provide mentorship during this transition. It’s easier to answer questions than to do the actual development ;).
If I don’t find new maintainers within a month or so, I will advertise these projects as being ‘unmaintained’ and unsubscribe from any notifications.
I am super grateful for the doors this project has opened for me, and the adventures I’ve had. Working on an open source project has allowed me to work in 8 countries on 4 continents, and it wasn’t possible without all the people who stopped by, cared and decided to make the project better. It’s been really amazing! It’s super scary to think that 10 years have passed and all the things that have changed :O
Peace out and onto the next adventure!
New Desktop Client 2.3.0 release out now!
March 3, 2017
It features many improvements under the hood as decreased memory (up to 300% !) and CPU usage as well as better time/bandwidth estimation during sync. In the frontend you might notice two big improvements concerning the sync of external storages (integrated storages like Dropbox, Google Drive, Samba etc.) : You can now easily deny or allow the sync of external storages – both on initial setup as well as later on in the settings. Just like you already could handle large folders to sync or not to sync.
External storages are furthermore shown with a separate icon in the folder list to easily spot the folders located on secondary storages. Another really big improvement can be found when right-clicking on a file to share. Public share links can now be transferred to your standard mail client directly after creation (Button ‘Mail link’) which delivers a massive increase of productivity. To keep your password only for personal access, the new client version also allows to work with app-specific credentials that users can generate in the web interface.
ownCloud Desktop Client 2.3.0 additionally introduces Qt 5.6.2 on Windows and Mac (Linux upcoming as well!) as well as improved error messages for users. Another great security feature the release includes is support for SSL client certificates that provide an additional layer of security by empowering admins to distribute certificates to users and restrict access thereby (in addition to usual passwords).
The full changelog can be found at https://owncloud.org/changelog/desktop/. Make sure to update today to get these awesome new features!
ownCloud is part of Google Summer of Code
March 1, 2017
Yesterday we received our confirmation to be part of this years GSoC. We are very proud to be chosen among various other well know and highly reputated FOSS projects. It’s a great honor and we will do our utmost to properly mentor our students.
During the day we already received the first students applications as well as we reached out for mentors within our engineering team. There is a list of great projects awating and we are thrilled by the additional ideas we got offered by our candidates.
We love to invite you to be part of GSoC at ownCloud. Discussion about your project idea is opened. Feel free to submit it on https://central.owncloud.org. A complete timeline for GSoC is available at https://developers.google.com/open-source/gsoc/timeline.
LetsEncrypt Support for openSUSE
February 28, 2017
The Elevator Pitch
“Imagine setting up encrypted websites and services was as simple as setting up your web server. Our aim is to provide that simplicity in openSUSE.”
This will take some dry background, please bear with me: Until recently, encrypting websites, mail traffic, etc through TLS certificates was a pretty painful process: You either had to purchase a certificate from a Certificate Authority such as Comodo, GoDaddy, Symantec, and others. Their job is to verify that you are in posession of the hostname (e.g. www.mydomain.com), and only issue a certificate if that is the case. In return, they are demanding a (sometimes pretty hefty) fee. That’s because they underwent procedural and technical audits to be accepted in the major browsers, but also e.g. Java. Members of this exclusive club can issue different kinds of Certificates, we only care about Domain Validated (DV) ones. Other forms include Extended Validation (EV), where CAs actually check Company Records and take more effort. This is however not important for most website owners.
On top of being expensive, some CAs have shown that even though they are making good money, recently incidents have shown that the reputation of a “Notary” is not warranted. We have seen everything: bugs in the validation process, gross technical incompetence and even deception. The latter has caused all major browser vendors to distrust the Root Certificates of WoSign and StartCom, both of which have been issuing free Certificates (although at least StartCom charged a fee for identity validation). And every year or two, certificates need to be swapped for new ones, which means spending more money and effort just to get your communication channels secured.
Whoever refused to go that way either had to create a custom CA, and publish the Certificates to all their users/employees, or ship a so called self-signed certificate. Both can (rightfully) lead to pretty scary browser warnings.
The web has been idling in this state until Edward Snowdens’ relevations made is clear that the unencrypted web is dead. However, it was clear that if ubiquitous encryption was to succeed, a new approach would be required. So Mozilla and the EFF, along with several commercial Sponsors created the non-profit Internet Security Research Group (ISRG). IRSG in turn runs LetsEncrypt, a new CA that provides proof-based certificates through the ACME protocol. Contrary to previous approaches, ACME requires a proof of (administrative) ownership of the actual host (more specifically: Port 80), which is a much stronger proof than just ownership of any email address associated with a domain name (e.g. retrieved through whois records). At the same time, this process is repeatable, allowing for automatic renewal.
Finally, the beauty of ISRGs efforts is that both client and server implementations are open source, so anyone could start an ACME-based CA (of course, they would still need to get their root certs accepted by the browser vendors).
Acquiring a Certificate through ACME
In essence, ACME clients first create an account, i.e. registers with LetsEncrypt. Optionally, it’s possible to provide an email address. It will be used by the CA to warn about expiring CAs in case the automatic renewal has failed. For both initial issuance and every renewal, a challenge-response protocol is performed via HTTP on port 80. The LetsEncrypt CA will verify that an agreed-upon token is available in .well-known/acme-challenge. If this succeeds, it will issue the certificate for the requested domain names.
Implementing the ACME protocol ourselves was out of scope for this project. Mostly because there already are quite some client implementations. So the first task was to pick an implementation that was concise, suitable and simple to package. Certbot, the official client currently developed by EFF is a dependency hell. Remember, we want encryption to become ubiquitous. Then there is acmetool, which has quite some nice features. Unfortunately, it is written in Go, which is notoriously hard to package. So we went with dehydrated (formerly “letsencrypt.sh”), which only depends on bash, openssl, curl and diff.
Even before hackweek 15 started, I had started to package up dehydrated for openSUSE (and SLES, and other RPM based distros). Thanks go to Roman Drahtmüller and Darix for improvements.. This includes providing default location handling for .well-known/acme-challenge for Apache (and nginx/lighttpd with limitations).
Through the course of the hackweek, we added a JSON-based status output, which might go upstream after some cleanup.
Next was a Yast-Interface for requesting and managing certificates. The real challenge was that neither Klaas nor I had done Yast hacking before, so we knew nothing about YCP widgets, the ecosystem, etc. Also, my Ruby knowledge was really rusty, and Klaas had never done any Ruby before. But nothing can stop a fearless Perl-Veteran! Also, the Yast module tutorial proved truly useful to get started.
Can be found in this OBS repository. It contains a patched dehydrated, along with the yast(2)-acme module. The module can be used to request certificates.
The Work Ahead
The Yast ecosystem turned out to be a bit more complex than anticipated. Since we had to start from square one in a few places, there is much to be done to make this a really smooth experience:
- Account Setup
- Integration with e.g. the yast-http-server and yast-mail modules
- Certificate revocation
- Auto tests
- Provide a stub responder on Port 80 in case no web server should be installed
However, with the initial success we plan to pursue this project after hackweek. I hope you will join us. Please get in touch with either me or Klaas.
The FAQ: Why not call It Yast-LetsEncrypt?
After Comodo tried to register a trademark for LetsEncrypt, ISRG had to start protecting its trademark. Hence they cannot allow any non-official project to use the name “LetsEncrypt”. This is why we resorted to “ACME”, the name of the protocol.
Portknox Update February
February 22, 2017
Direct Menu added
This top rated app provides easy access to all apps in the header. Go to your apps menu, activate it and give it a try. (There are plans to add this menu directly into Nextcloud core.)
Contacts update v1.5.3
This minor update brings back the addressbook export. Here is the full changelog.
Calender update v1.5.0
My most used app gets many UX improvments and bugfixes. Check the full changelog.
Nextcloud update 10.0.3
We are updating Nextcloud to version 10.0.3 (changelog) which is a requirement for your upgrade to Nextcloud 11. As usual we slowly update all clouds, by the end of next week all clouds should be up2date.