ZeroPhone and future of open-source funding
Hi! Today, I'm happy to announce a new stepping stone in this project. While it's not something I've talked about a lot recently (though you might have read my thoughts on our IRC channel), this change is inevitable and pretty much self-explanatory. There's been a set of priorities to the project that I'm reaching one-by-one - for example, a major one is self-assembly capability, something that's lead to ZeroPhone being the only phone you can feasibly assemble on your own, without any outside help. Another one is keeping ZeroPhone as open-source as possible - as a result, all software/hardware we develop is open-source from the start, and we have a goal of making it possible to replace/omit parts that are not (Pi Zero, GSM modem, WiFi), something I call "almost open-source". For example, the recent OSD3358 CPU board replacement is a part of this priority, and I will be making sure that this remains the case.
Nevertheless, all the effort put into the project comes at a cost. I'm not talking about the countless development hours I've spent thinking, designing, prototyping and testing, I'm also not talking about the cost of using closed-source firmware in this project, which tends to rear its ugly head from time to time in various problems I encounter, resulting in "solutions" for some ZeroPhone problems being essentially workarounds. I'm talking about the cost of sustainable hardware&software development and making sure that people working on it can continue their work. It's an open secret that the open-source developers are, on average, underfunded when it comes to their "proprietary software" counterparts. An example that I like to point out is FreeCAD - if you look up the Patreon pages for FreeCAD-related development and information about their donations, you'll find that the total will be, at most, cost of 5 seats for the most recent version of SolidWorks. There's no need to explain the outstanding gap between funding for open-source and non-open-source software in details, and in cases of complicated software, gaps in funding inevitably cause gaps in functionality.
So, what do we do? How do we make sure that open-source software funding is comparable to that of proprietary software? I've been thinking about this for the past two years, and both looking for and experimenting with solutions. I've also talked to people on the "proprietary" side of things - something that, I'm afraid, is not done often enough. What I've learned is that there's a myriad of approaches that companies can do, that you won't see employed in open-source, for one reason or another. So far, keeping to open-source traditions, I've come to a hybrid approach, where the development is funded both by recurrent and one-time donations, as well as future hardware sales. However, I've finally decided that we need something more radical in our approach for open-source funding, and, in our case, we have the hardware to back it up. It's no secret that freedom comes at a price, in all but the most benign situations. So far, the price for ZeroPhone's openness is also its weakness. If the project can't support itself and other projects it relies on, it's doomed to fail - and, likely, drag other projects down with it.
Today, I announce the ZeroPhone licensing program - backwards-compatible, backed by our flexible hardware and open-source software. The gist is simple - the default ZeroPhone software will have hardware authenticity checks required for it to function, and, in order to bypass these checks, you'll have to invest in the ZeroPhone project - the money will be automatically redistributed downstream, funding non-corporate-backed open-source projects that we rely on, be it KiCad, FreeCAD or various libraries that are essential for ZeroPhone as a project. I've previously told you about ATSHA204, a cryptographic authentification chip that's cheap, easy to source (even on eBay!) and easy to solder. It stores a private key inside, and can therefore be used for hardware management, authentification and counterfeit prevention. We have a mod board based on it, but it never had a concrete usecase - and now there is one. This is far from a new approach, in fact, it's a tried-and-true solution in the proprietary world - for example, that's the approach the Raspberry Pi Camera v2 uses (with the same exact IC, no less!), and after disassembling products on the costlier side of the spectrum, you'll surely spot something like ATSHA204A quite often. In private discussions of this idea, I've been told that similar projects (like MakerPhone and WiPhone) are also taking note.
I've been working on the corresponding software during the last month, which explains some of my recent radio silence - an announcement like this has to have some work behind it. For now, I've built a Python interpreter with the required cryptographic extensions - as a lot of our software is written in Python, it makes perfect sense to plant the hardware verification code in there. However, under GPL, we're required to provide *all* of the source, which would kind of defeat the point of this initiative - the major problem that I've been working on. This is a tough task, but, thankfully, the proprietary world is there to help and show the way. We've seen examples of companies solving this problem in non-conventional ways, the most popular of it is providing the software as a web-hosted service, where they're not obligated to share their changes. This is likely the end goal, and I'm already experimenting with it - it appears that Python bytecode is easy to compress and transfer over the Internet, which means that, were we to make an Internet-hosted Python interpreter (going as far as running the entire UI on our servers), there will hardly be any UI latency noticeable to the user. As a result, an Internet-tethered ZeroPhone is the route we're likely taking in the end - which also has an ecological advantage, as we can cache results for the most common operations that the UI performs and not waste CPU cycles on re-drawing the UI from scratch, again and again.
I'm having a lot of fun playing with the ATSHA204-augmented ZeroPhone prototypes - it seems that there's a lot of good we can achieve. Apart from actually, finally, funding the ZeroPhone project and the projects we rely on, there are large-scale societal problems that we can't currently solve - that we can finally tackle with some good old cryptography. For example, the recent news about legality of hosting of Tor nodes in Germany might make you think about the power we're giving to people when providing them with open-source software - power that can be easily abused once it gets in the wrong hands, and it's not always easy to tell which hands are the wrong ones. Next year, it's planned to have each ZeroPhone-outgoing network packet signed with its unique serial number, made possible by the ease-of-use that ATSHA204 provides. This way, we can finally hope to reach the levels of national security that, for now, only proprietary OSes like Windows and OS X can help maintain.
This is a large milestone for the ZeroPhone project and, I expect, open-source software as a whole. I hope that, in the future, people will remember 1st of April as the date when open-source hardware and software finally got a chance to realise its true potential. Thank you for staying with the project. There's a lot of new stuff in the pipeline, a newsletter is coming * very soon*.
Cheers!
Arsenijs
P.S.
If you have any suggestions, comments, project ideas or wishes - you can fill out the survey, reply to this e-mail, reach me on Hackaday or Reddit, maybe comment on the Hackaday project - whatever works for you!
If you're new to this project, absolutely do check out ZeroPhone Wiki, as well as newsletter archives - and don't forget about the Hackaday.io page!
|
