Free as in Beer has caused Heartbleed (and Much More)

heartbleedHeartbleed is a bit over one month old now. A bug significant enough to have its own Wikipedia page. Today, we’re going to look into how wrong we have been in assuming that Open Source software is more secure than commercial software, because of our thinking that source code is open and that many developers are looking into it.

Free as in Beer

One of the core principles of Open Source software is, well, that it is open and that this openness is free in one way or another. This allows us developers to browse source code of third-party software and libraries for various reasons:

  • To learn from it
  • To copy it (under the terms of the respective license)
  • To modify it (under the terms of the respective license)
  • To verify it

Proprietary software often does not have the above attributes in exchange for warranties. When you read through the millions of lines of unintelligible legal Microsoft text, for instance, you will see that Microsoft gives a couple of guarantees, also with respect to security and how security flaws are remedied.

The warranty that is legally shouted at you by OpenSSL is this one:

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

In fact, you don’t have any warranties. Specifically, there is no liability for direct or indirect loss of data, as has happened because of Heartbleed.

Obviuous, right? Because it’s free as in beer, any consequences resulting from the Heartbleed bug are entirely your own fault, if you’re using OpenSSL, or any other open source software that includes OpenSSL under similar terms.

Yes. You should have known that you were vulnerable, because you actually could verify it. Did you? Of course not. Did we? No way we’re delving through all that C code. Did our “suppliers”? We don’t even know. We’re using WinSCP extensively, and check this out, WinSCP was affected by Heartbleed! The developers over at WinSCP have been nice enough to fix this issue quickly and release a new version. They didn’t have to do this. You know what? Let’s hit that donate button, right now to thank them.

“They” should pay

OK, but again, wasn’t Heartbleed supposed to never even happen? Isn’t this Open Source? Doesn’t anyone (read: “they”. Because, I don’t have time) review such code, especially if it’s that widely used? Isn’t Open Source security much better than closed source security, which is essentially security through obscurity?

Eberhard Wolff, a well-known German freelance consultant and trainer recently replied this to me:

Yes, I’m sorry, Eberhard. But that’s just the case. Security is often neglected in many pieces of software, both commercial and open source. It’s not that the openness helps anyone discover things, security issues are very hard to discover per se. Also in commercial software. Remember GOTO fail? GOTO fail also affected SSL, but only in Apple software.

The issue lies elsewhere, though. Because Microsoft somehow manages to patch all security issues in virtually no time. They fix things so fast that users get frustrated about the sheer frequency of fixes ;-)

But Microsoft has a lot to lose. Pretty much 90% of desktop OS market share, that’s what they’ve got to lose. They’re paying a high amount of insurance money, invested in security teams that are penetration testing their own software to look for leaks. Yes. The vendor themselves are doing this. And yes, it costs money. And yes, you’ve already paid that when you bought Windows (or Office for that matter).

Money that OpenSSL never had. Read this frustrated section in the following public letter by Steve Marquess:

Thanks to that publicity there has been an outpouring of grassroots support from the OpenSSL user community, roughly two hundred donations this past week[3] along with many messages of support and encouragement[4]. Most were for $5 or $10 and, judging from the E-mail addresses and names, were from all around the world. I haven’t finished entering all of them to get an exact total, but all those donations together come to about US$9,000. Even if those donations continue to arrive at the same rate indefinitely (they won’t), and even though every penny of those funds goes directly to OpenSSL team members, it is nowhere near enough to properly sustain the manpower levels needed to support such a complex and critical software product. While OpenSSL does “belong to the people” it is neither realistic nor appropriate to expect that a few hundred, or even a few thousand, individuals provide all the financial support. The ones who should be contributing real resources are the commercial companies[5] and governments[6] who use OpenSSL extensively and take it for granted.

I can feel with Steve. US$9,000 to improve OpenSSL, a software that has added so much value to all of our servers and clients. That’s hardly enough for even 2-3 bug fixes, depending on whose salaries you’re paying.

But Steve tells off the “commercial companies” and “governments” to not have paid enough. But who are these “commercial companies”?

Meanwhile, at Data Geekery

We know similar stories, of course. When we have transitioned from completely Open Source to dual-licensed, we heard a lot of complaints by users that we have never heard of up to that moment. Users who have never donated or contributed code, bug reports, manual improvements or anything. This is OK. We were giving jOOQ away for free under the terms of the ASL 2.0 as part of a extended market analysis. We didn’t expect donations.

Of course, we have also disappointed one or two people who were hoping that jOOQ would remain “free as in freedom”, who have contributed, who have participated, and who now felt deceived. And we’re genuinely sorry about that. But participation doesn’t pay for our bills, money does. So we reached out for money (luckily, we always owned the code as we paid contributors of larger contributions, and had them all sign a CLA, so we could actually do this step, from a legal perspective).

But let’s again focus on the people looking for free beer. No contributions. No feedback. Free rides. And then, when asked for money, they’re pissed (even 8 months later!).

Fair enough. Our price has risen for that particular user. From free to something. They, too, have a right to be frustrated about this change, which they might not have expected. But they, too, have taken “free” for granted without proper reason. Without verifying.

“They”

We don’t believe that “THEY” should pay for our licenses. We don’t think that “THEY” should pay for enterprise support. There is no “THEY” in free software, there’s only all of us, because who decides which project is really important enough to deserve some funding from “THEM” and which one isn’t? All attempts of “fairly” distributing money will inevitably lead to corruption, misuse, abuse, and eventually, to a lack of innovation. We’ve known that from other industries.

So, let’s simply establish two facts:

  • Free software is lying around in the streets. It is publicly acclaimed to be AS IS software. If we’re using it, it is our own risk. And if it goes wrong, it is our own fault. No one else’s. Not the big companies’ (who are already investing tons of money in Open Source software), and not the governments’ (same thing there). Stop pretending that FOSS is in any way better or less of a legal risk than commercial software. That’s just not true.
  • In fact, there is no such thing as free software. “Free” is a price we’re paying as a down payment (or non-payment). The costs will or might arise later. If we’re lucky, the thing will remain “free”. But if we’re professionals, then we’ll insure ourselves against any risk arising from free “AS IS” software. This means that we’ll give back (= “pay”) in another way. Through donations, through bug fixes, through verification.

Further reading

Bruno Borges from Oracle has expressed his very interesting views and counter measures to the current state and meaning of Open Source software in this blog post.

An Open Source License to Increase Your Street Credibility

Many of us geeks don’t really care about users, tractions, etc. when we spam GitHub with our little toy projects. I mean, who knows if we really have the time to maintain them? Certainly, there’s almost no money in it anyway, so we might just as well give it away for free (e.g. jOOX).

Nonetheless, you should choose a license to show your intent. But which license to choose? Jeff Atwood says “Any License”. He then goes on to recommend the WTFPL or Do What The Fuck You Want Public License. I mean, this is just like arbitrarily throwing software around you in the streets:

But we claim that there is another, much better license for this kind of useless little toy project. It’s called Beerware. The license text reads:

/*
 * ------------------------------------------------
 * "THE BEER-WARE LICENSE" (Revision 42):
 *  wrote this file. As long as 
 * you retain this notice you can do whatever you 
 * want with this stuff. If we meet some day, and 
 * you think this stuff is worth it, you can buy
 * me a beer in return [Your Name Here]
 * ------------------------------------------------
 */

So, when you’re in for some street credibility, give this some serious thought!

Increase your street credibility, use the beerware license
tweet this

… just kidding. Use the ASL 2.0 and/or the CC-BY 3.0

Free Open Source with Commercial Support

Have you ever thought about “Free” Open Source with commercial support vs. commercial software? We have and we found that the following is true:

Free Open Source Software with commercial support

… is the best business model for companies selling services for very complex OSS software where customers might lack skilled personnel. This includes things like

The above systems can cause terrible pain to your productive environments when they crash. You want to have extremely skilled fire fighters ready when your system goes down. Some of the above systems have been said to be deliberately complex in order to be able to pursue this particular business model.

Commercial software or dual-licensed software

… is the best business model for companies selling very simple, easy to use software where customers do not rely on skilled personnel in the event of a crash. This is particularly true for

The above software are so easy to handle and to maintain, their vendors would hardly make any money with support. Granted, support is always included in the license fees. That’s just part of the service quality.

Oracle GlassFish, or Why You Should Think About Open Source Again

Oracle’s recent announcement about the discontinuation of commercial services for JEE’s reference implementation GlassFish has caused many reactions in the community involved with JEE. The reactions reach from:

This event seems to have a big impact on the whole Java ecosystem as many of the above people are key players and influencers in our community, and they neither agree nor know what this step by Oracle means for the future of JEE.

The most interesting point of view among all of the above, in my opinion, is tomitribe’s, looking at things from a mere business point of view with respect to Open Source. They’re saying:

Open Source Isn’t Free

Or in other words, “There ain’t no such thing as a free lunch”. And to quote tomitribe even more, a very interesting thought they’re setting out is this:

What this says to me is that we as an industry still do not fully understand Open Source.

We most certainly do not understand Open Source. I’m an Open Source software vendor myself. I believe that Open Source is:

An excellent marketing tool

People look at Open Source as something “generally good”. When I talked about jOOQ at conferences and when it was an all-Open-Source piece of software (not yet dual-licensed), I got lots of opportunity to do free advertising. This has rapidly changed, now that I am offering an alternative commercial license.

A good tool enabler

I get free access to

The same here. As I’m now a “commercial” software vendor, some tools are no longer accessible to me.

The truth is: Open Source is a business strategy

It really is. And it seemed to have worked well for RedHat or Pivotal in the past. Has it worked for anyone else? We don’t know yet, as most other larger companies have such huge amounts of revenue in “classic” fields that they can simply “afford” Open Source. In fact, they’re so good at investing manpower and innovation into Open Source, it keeps the commercial competition in check, as it is hard to write a better and more complete JEE implementation than Weblogic or Websphere.

Apparently, even Larry Ellison is said to agree that the future of data centers lies within using commodity machines. At the same time, RedHat suggests “trying free” to Oracle.

No matter what the impact of the commercial unsupport of GlassFish on JEE will be, we’re only at the beginning of fully understanding what kind of impact this large scale “freemium” model will have on our world. This isn’t just about the software industry. The whole Internet has brought us “free” stuff. We get:

  • “Free” standards (compare W3C, IETF standards to ISO standards!)
  • “Free” Facebook and Twitter and GMail accounts
  • “Free” newspapers
  • “Free” music and films
  • “Free” commodity services for all sorts of work
  • “Free” work force as we can offshore anything to low-wage countries

This has been picked up recently by Tim Kreider, the author of “We Learn Nothing”, where he depicts how writing “free stuff” for the New York Times helps building “exposure”, and how that’s just nonsense as all this hard journalist work doesn’t pay anymore.

Does building “exposure” ring a bell?

Yes, I can build “exposure” by writing free Open Source on GitHub, and by answering complex questions for free on Stack Overflow. I personally use both tools to advertise jOOQ, no doubt. So I get a service (advertising) for a service (content). My deal appears fair to me. But loads of GitHub and Stack Overflow users contribute … just for the sake of contributing. To whom? To GitHub and Stack Overflow. And why? I don’t know.

So, should you contribute to GlassFish, if Oracle starts decreasing support and loosening interest as they have before with MySQL, Hudson, and other products inherited from Sun?

Let’s remember that Karl Marx has already taught us that our idea of capitalism will inevitably lead us to (citing from Wikipedia):

  • technological progress
  • increased productivity
  • growth
  • rationality
  • scientific revolution

Absolutely! There’s no way that productivity can get any better than by having loads of software developers world wide produce better and better tools (growth, progress) for nothing more than … for free!

So, don’t be a pawn of others’ Open Source strategies

So, instead of contemplating what Oracle’s move away from supporting the Open Source reference implementation of JEE means, become active yourself! Don’t just blindly consume Open Source, make it an option like any other option by consciously deciding in favour of Open Source or commercial software, depending on your specific needs.

Stop advertising their cool products for free at conferences, unless you pull out your own advantage from such an advertisement. Open Source is just yet another business model.

A Significant Difference Between Open Source and Commercial Software

A recent event has triggered a lot of interest in the debate about the good and the bad parts of Open Source. Oracle’s attack on Open Source. For large corporations who aren’t Red Hat, taking a stand on the topic is far from easy. Oracle used to sell only commercial software, but has since acquired a lot of open-sourcey companies, such as Sleepycat Software (BerkeleyDB) or Sun Microsystems (Java, MySQL). Phrasing a long-term strategy upon this legacy isn’t easy.

At the same time, Oracle is extremely successful, having surpassed IBM’s revenue, making Oracle the second largest software company in the world. The continuing popularity of its flagships Java and the Oracle database is promising, also for middleware vendors providing products such as jOOQ, for their flagships.

At Data Geekery, Open Source is also very important, just as commercial licensing has become, since recently. The change towards dual-licensing has been received rather positively on the jOOQ user group, even if it led to open questions about the continued Open Source strategy. But what’s the real difference between Open Source and commercial software? At Adobe, Dr. Roy Fielding is often cited saying that there is essentially no difference between Open Source and commercial software, and he’s quite an authority for both worlds. Both are absolutely viable business models with their pros and cons respectively (unfortunately, I cannot back this up with an actual citation).

One significant difference, however, is that low-quality open source software can heavily outlive low-quality commercial software, as it just never really dies, as no one is “losing money” on low OSS “sales”. I’ve recently blogged about how to recognise such low-quality Open Source software.

Open Source is foremost a business and marketing strategy, just as much as it is a mission. This business strategy can be a good or a bad choice for any software vendor.

10 Reasons not to Choose a Particular Open Source software

We’re all Software Engineers of one type or another. Most of us have one thing in common, though: We’re lazy. And we know that someone else was less lazy and has already solved that tedious problem that we’re on. And because we’re not only lazy but also stingy, we search for Free Open Source software.

But the problem with Open Source software is: There are millions of options for about every problem domain. Just look at web development with “modern” JavaScript. Which tool to choose? Which one will still be there tomorrow? Will it work? Will I get maintenance? New features? Plugins from the community?

While it is not so easy to find the right tool among the good ones (commons or guava? mockito or jmock? Hibernate or jOOQ or MyBatis?), it is certainly easier to rule out the bad ones.

Here are some things to look out for, when evaluating an Open Source software (in no particular order)

1. NullPointerExceptions, ClassCastExceptions

This is one of my favourites. It is very easy to google. No one is completely safe from these annoyances. But when you find stack traces, bug reports, investigate them closely.

  • Do they appear often?
  • Do they appear in similar contexts?
  • Do they appear in places where they could’ve been omitted?

It’s a matter of good design to be able to avoid NullPointerExceptions and ClassCastExceptions. It happens to everyone. But no NullPointerException should be thrown from a place that can be statically discovered by the Java compiler or with FindBugs.

Needless to say that the list of no-go exceptions thrown from a database library, for instance, can be extended with SQLExceptions due to syntax errors produced by that library.

2. Community Discussing Bugs instead of Features, Strategies, Visions

Every Open Source software has users and with Google Groups and GitHub, it has become fairly easy to interact with an OSS community.

For larger projects, the community also extends to Stack Overflow, Reddit, Twitter, etc. These next steps are a sign of popularity of an Open Source software, but not necessarily a sign that you should use them. Also, don’t be blinded by users saying “hey this is so cool”, “it just made my day”, “best software ever”. They say that to everyone who’s supporting them out of their misery (or laziness, see the intro of this post).

What you should be looking out for is whether the community is discussing visions, strategies, features, truly awesome ideas that can be implemented next year, in the next major release. It’s a true sign that not only the software will probably stick around, it will also become much better.

The converse to this is a community that mainly discusses bugs (see NullPointerException, ClassCastException). Unlike a “visionary” community, a “buggy” community will just create work, not inspiration to the vendor. But which one’s the chicken, which one’s the egg?

Another converse to this is a community that is disappointed by the false promises given by the visions of the vendor. I often have a feeling that Scala’s SLICK might qualify for that as it introduces an insurmountable language-mapping impedance mismatch between its own, LINQ-inspired querying DSL and SQL.

3. Poor Manual, Poor Javadoc

That’s easy to discover. Do you really want that? The best and most authoritative information should come from the software vendor, not some weirdo forum on the web that you’ve googled.

A good example are PostgreSQL’s Manuals.

A rant about bad examples can be seen here:
http://www.cforcoding.com/2009/08/its-time-we-stopped-rewarding-projects.html

Don’t be deceived by the idea that it might get better eventually. Poorly documented software will be poor in many other aspects.  And it’s such an easy thing to discover!

Of course, the “right” amount of documentation is an entirely other story…

4. No Semantic Versioning

Search for release notes and see if you’ll find something that roughly corresponds to semver.org. You will want patch releases when your Open Source software that you’re using in mission-critical software fails. When you get a patch release, you don’t want 50 new features (with new NullPointerExceptions, ClassCastExceptions).

5. Unorganised Appearance

Again, we’re in times of GitHub. The good old CVS times are over, where HTML was still used to share cooking recipes. Check if your Open Source software uses those tools. If they show that they’re using them. It will help you ascertain that the software will still be good in a couple of years if the vendor isn’t crushed by the mess they’ve gotten themselves in.

6. Vendor Side-Project evolving into an Offspring Product

Now that is a sign not everyone may agree upon, I guess. But after the experience I’ve made in previous jobs, I strongly believe that software that has evolved out of necessity before making it a product really suffers from its legacy. It wasn’t a product from the beginning and it has strong ties to the vendor’s original requirements, which doesn’t bother the vendor, but it will bother you. And because the vendor still has very strong ties to their offspring, they won’t be ready to make fundamental changes in both code and vision!

Specifically, in the database field, there are a couple of these software, e.g.

Note, I don’t know any of the above tools, so they may as well be awesome. But be warned. They weren’t designed as products. They were designed for a very narrow purpose originating from a pre-Apache context.

7. Generics are Poorly (or Overly) Adopted

Generics were introduced in 2004 with Java 5. Now that the heated debates about generic type erasure are over, generics are well adopted. Or aren’t they? The latest stable release 3.2.1 of Apache Commons Collections is still not generified! That must’ve been the number 1 reason why people had started shifting to Google Guava (or its predecessors) instead. There’s not much making for a lousier day than having raw types (or eels) slapped around your face.

The other thing that you should look out for, though, is over-generification. Generics can become really hard, even for top-shot Java architects. A common blunder is to strongly correlate subtype polymorphism with generic polymorphism without being aware of the effects. Having too many generics in an API is a good sign for an architecture astronaut. (or a design astronaut in this case). We’ll see further down how that may correlate with the person behind the design decisions.

8. Vendor Cannot Handle Objective Criticism or Competition

Here’s how to find out, who’s behind the Open Source software. While this isn’t important for a small, geeky tool, you should be very interested in the vendor as a person when looking for a strategic OSS addition, especially if you’re dealing with a benevolent dictator. The vendor should be:

  • Aware of competition, i.e. they’re doing marketing, learning from them. Improving to compete. This means that they are interested in being truly better, not just “convinced that they’re better”.
  • Open minded with their competition, with you as a customer, and ready to discuss various points of view.
  • Interested in new ideas, possibly putting them on a roadmap right away (but without losing focus for his main strategic roadmap).

Even if this is Open Source, there’s no point in being arrogant or conceited. The vendor should treat you like a customer (as long as you’re not trolling). Open-mindedness will eventually lead to the better product in the long run.

9. Vendor has no Commercial or Marketing Interests at All

Now, (Free) Open Source is nice for many reasons. As a vendor, you get:

  • Feedback more quickly
  • Feedback more often
  • Community (with pull requests, feature additions, etc.)
  • The feeling that you’re doing something good

True? Yes. But that’s true for commercial software as well. So what’s the real reason for doing Open Source? It depends. Adobe for instance has started opening up a lot, recently, since their acquisition of Day Software. All of JCR, JackRabbit, the upcoming JackRabbit Oak, Sling and Felix are still at Apache with the original committers still on board. But one can certainly not say that Adobe has no commercial interests.

OSS vendors should think economically and build products. Eventually, they may start selling stuff around their core products, or separate community and commercial licenses. And unlike they get too greedy (see Oracle and MySQL, vs RedHat and MariaDB), that can make commercial Open Source a very interesting business, also for the customer who will then get the good parts of Open Source (partially free, open, with a vibrant community) along with the good parts of commercial software (premium support, warranties, etc.)

In other words, don’t choose overly geeky stuff. But you might have recognised those tools before (poor documentation, no semantic versioning, poor tooling).

10. No Traction Anymore

To wrap this up, here’s an obvious last one. Many Open Source products don’t show any traction by the vendor. That goes along well with the previous point, where the vendor has no commercial interest. Without commercial long-term interest, they’ll also lose all other interest. And you’re stuck with maintaining a pile of third-party code yourself (fixing its many many ClassCastExceptions, NullPointerExceptions).

TL;DR : Conclusion

You should chose Open Source just like commercial software. Economically.

  • Open Source is not an excuse for bad quality.
  • Open Source is not an excuse for lack of support.
  • Open Source is not an excuse for non-professionalism.

If Open Source fails you on any of the above, the joke will be on you, the customer. You’ll get a bad product, and you’ll pay the price with exaggerated maintenance on your side, which you thought you’d avoid by chosing something free. Nothing is free. Not even Free Open Source. Ask the Grumpy Nerd

Jenkins (and Others) about Dropping Support for Java 5

As an Open Source developer, I’m used to trying to support as many reasonable things for my users as possible. However, this has never included support for Java 5, which itself is hardly supported by popular Java vendors anymore. Hence jOOQ requires Java 6 or more to compile and run.

There is now an interesting initiative by Kohsuke Kawaguchi, the creator of the Jenkins CI server. In a letter, he’s attempting to get other Open Source projects and developers on board with him to drop support for Java 5. While this change is rather trivial and marginal for most Open Source projects, it’s a major change for a continuous integration server such as Jenkins. With his permission, I’m citing his letter about why Java 5 should no longer be supported by Jenkins CI. If you’re an Open Source developer and you want to drop or have already dropped support for Java 5, then join this initiative:

What?

We are putting the stake on the ground: our releases after Sep 30th 2013 will start requiring Java 6 as the minimum runtime environment.

We are delivering this message to our users to give them a fair notice. To make this more effective, we are building a coalition of OSS projects. We’ll put up a simple website to advertise this, and encourage people to spread the news. Our collective project names and logos will help spread the message.

We are developers of an OSS project. To help our users use our software, we’ve been refraining from requiring Java 6 as the minimum runtime so far. But we think we did that long enough. It’s time to move on.

Why?

  • Most Java VM vendors no longer support Java 5. People shouldn’t be using it.
  • There’s no viable open-source Java 5 implementation.
  • We can’t use increasing number of libraries that require newer Java, translating into more development effort, less features and fixes.
  • It’s adding to the integration test cost. We run more tests for Java 5, when increasingly smaller number of developers actually have Java 5.
  • Newer Java runtime has more features. More collection APIs, NIO improvements, console access, XML support, compiler API, annotation processors, and scripting language interface.
  • 1.50 class file format comes with split verifier, resulting in faster classloading.
  • Putting our collective weight behind this will help us reach more users. Picking this fight individually is harder.
  • If this is successful, it’ll make it easier for us to move on to newer Java runtimes in the future versions.

Facts

  • Java5 was released in 2004, nearly a decade ago. Its public support has ended in 2009.
  • Even IBM is ending its support for Java 5 on the server side at Sep 30th, 2013.

Who is already onboard?

Being invited:

Considered contacting and discovered they have already moved on

Call for action

  • If you are a developer of an open-source project who wants to join, please let us know so that we can add you!
  • If you know some projects we should reach out, please let us know.

Contact

Kohsuke Kawaguchi: kk at kohsuke dot org / @kohsukekawa

See the original letter here:
https://docs.google.com/document/d/1pi8OsiG-hPDjqSge4xqmpZTshryUkMdF4QLBeCf0GXo