Writing — by Jan Lehnardt

Vegan Japan October 2025 Edition

2026-02-15T00:00:00+01:00

We spent three weeks in Japan in October 2025, eating 100% vegan. In this post, I’m sharing the restaurants and cafés we went to.

Vegan eating in Japan has a bad rep and based on our 2019 experiences trying to eat vegetarian, we knew first hand that it could be a bit tricky.

I’m very happy to report that it has gotten a lot better in recent years and I’ve had some of the best food of my life on this trip.

We did go into this with extensive planning and finding a plan A and B for each lunch and dinner. This might take more time than you’d like to spend. We had an exceptional time and no dud food-wise, but with our experience now, we are happy to relay that even with just a little planning, you should get to experience vegan Japan just fine.

Our preparatory research mostly consisted of Google Maps search with additional research and reservations through Instagram and other specific reservation platforms that the restaurants will link to (or can be found on Google Maps). While in Japan, we augmented this with HappyCow to work around changed travel plans or temporary closures.

It’s obviously easier in larger cities, but with Buddhism well established, plant-based food is available even in smaller places if you know how to ask (your translation app and being polite will work wonders). Since not everyone is aware of the vegan label, it can also help to ask about food without meat, fish, dairy, eggs. Most small towns have the obligatory Indian restaurant that usually has got you covered.

The fact that this information is locked into US-megacorps is not very fun, so I took a couple of hours to add or edit all places to [OpenStreetMap][osm], if they didn’t exist already. You can use the excellent open source Veganguide to look at them all.

Restaurants in Japan are generally very very good compared to what you’re probably used to. That means that vegan restaurants compete for customers on a very high level and some of the food you’ll find you’ll get nowhere else.

Tokyo

T’s Tantan, Tokyo Station

An honourable mention up first. We did not actually go to this restaurant, but @pat swears by it and we did pick up its supermarket Ramen at Tokyo Station on our first night to eat at the hotel after coming in too late and tired for a restaurant and it was delicious!. Random supermarkets across Japan will carry this, but we have not found a stable pattern.

Links:

—

Gluten Free T’s, Ueno-Hirokoji

A brightly lit and very friendly restaurant seating around 12 people. It focusses on gluten-free dining, but vegan options including starters, mains and deserts are available and very tasty. You can even buy some of their gf ingredients, like pasta to cook at home.

Notes:

You order via a website on your phone.
Last order 30 mins before closing time.
Make reservation for evenings and larger groups.

Links:

—

Organic Bar Nourish

Cozy organic restaurant with vegetarian and vegan food options. The service is very friendly and the food is excellent. They offered free miso soup with their lunch deal. Near Rikugien Garden which is well worth a visit.

Notes:

Restaurant is on the second floor.

Links:

—

Marugoto Vegan Dining Asakusa

An absolutely lovely riverside lunch and dinner spot that can open its full front to let nice weather in. The entire menu is vegan and all the food we sampled was sublime. A nice respite from the otherwise busy Asakusa area.

Notes:

You order via a website on your phone.

Links:

—

Shiba Park Hotel

The Shiba Park Hotel restaurant does Hanasanshou Dinner (similar to Kaiseki) including modern Chinese and Western variants, all vegan. The service is exceptional and the food is fantastic. Our head waiter was delighted when we ordered three Japanese dinners as westerners and he greatly enjoyed showing us the ropes. Highly recommended if you are looking for a special evening.

Links:

—

Kyushu Jangara Shiba Daimon Store

Random off-the-main-street Ramen place with excellent service and vegan Ramen options. You pay at the machine at the entrance, but staff can help you if need be. Near Shiba Park and Tokyo Tower.

Links:

—

Brooks Greenlit Cafe

Modern and cozy café next to a small park (that doubles easily as outdoor seating if you are okay with flaunting Japanese etiquette and take your order out). Excellent sweets and matcha. We did not get to try the delicious looking sandwiches, but would go again. Pairs well with a visit to Meiji Jingu Gaien Ginkgo Avenue.

Links:

—

Vegan Ramen UZU Tokyo (inside teamLab Planets)

Only available to visitors of the teamLab exhibition which is a must-see. The line and wait for the vegan Ramen can be off-putting but it is well worth it. Bridge the time with donuts from the cart at the back. Pro-tip: you can go back into the exhibition after eating, so if you need a break in-between, have a snack.

Links:

—

Vegan Eat Tokyo

Tranquil fully vegan Japanese + world fusion restaurant with very friendly staff and great drinks selection in the otherwise busy Aksakusa area.

Notes:

Google maps says permanently closed but HappyCow still shows reviews as of this week.
HappyCow
Gmaps
Instagram

—

Alchemy

A bit awkward to find in a mixed-used commercial building, but a nice and wide-open space with a wide selection of plant based food and fun coloured (and tasting) drinks. Probably best paired with exploring the rest of the stores there, e.g. the adjacent large bookstore. The amazing city view from their outdoor terrace is also a big plus

Notes:

You order via a website on your phone.

Links:

—

Daiichi Takimotokan, Noboribetsu

This is a luxury Onsen / Hotel with an outstanding Grand Bath that’s worth its own visit. If you’re a guest, Kaiseki dinner is available for pre-order. Compared to other vegan Kaiseki we had it was middle of the road, which by Japanese standards still means very good, but there’s better to be had. This is mainly so you can safely book this hotel and spa and have food covered.

NEXT RESTAURANT (Suidobashi)

This is a delivery-only place. The rice bowls are great, skip the pizza.

Kailash Asian Dining ＆ Bar

A totally serviceable and friendly Indian restaurant around the corner from the Tokyo Skytree.

Sapporo

Organic Plus

Cozy wine bar with organic kitchen that serves vegan options. The food is very good and service is top notch; as is the music selection. The menu clearly labels everything as either vegan, lacto-vegetarian or lacto-ovo-vegetarian. Do not miss. Feels like being in an early Murakami novel (without the smoking).

Links:

—

Veggie Way

We didn’t eat here in person, but got take-out instead, and the food was excellent.

Hakodate

Yasai Bar Miruya

Tiny open kitchen restaurant, woman-owned sole-proprietor and one of the sweetest places we have been. The food is excellent, the location is tucked away between residential and harbour districts, but just two tram stops from the central train station. This is a prime example of trusting recommendations and not just betting on flashy exterior. Approaching, especially in the dark you barely notice it is a restaurant at all. Staying open minded and just going for it rewards you in ways you could not have imagined.

Notes:

Reservations are not possible, best arrive early.

Kyoto

Vegan Restaurant F

One of our favourite experiences and some of the best food we’ve had on the trip. Small-ish mom & pop restaurant with a seven course fine dining experience that you will not forget. A tiny highlight is the home-made vegan cheese, the best vegan cheese we’ve ever had. They sell it to go and if feasible we’d have bought the whole stock. Service is lovely, prices are surprisingly low (~25€ per person, incl. drinks).

Notes:

We reserved in advance via Instagram.
Staff doesn’t speak english, but politeness and a translation app ensures a pleasant stay.

Links:

—

Vegginy

Another top favourite experience and the best burger I’ve had in my life. Truly a Scooby-Doo contraption that tastes like nothing else. Service is great and the atmosphere is chill. Do get some of the art exhibited, sales go towards a good cause.

Notes:

Entrance is in an easy-to-miss basement.

Links:

—

Veg Out

This was our only re-visit from 2019 as we loved it so much and it did not disappoint. With enormous windows for a brilliant river and mountain view, this tranquil café serves vegan buddhist-inspired cuisine that will make you visit again, too. Shares an entrance with a yoga studio, if you need even more tranquility. Easy to reach from or to Fushimi Inari-taisha.

Links:

—

Vegetable Dishes ”OKI” SHIJO

Entrance-level canteen of a hostel-like hotel with fantastic vegan breakfast options, both Japanese and Western-inspired. We didn’t go for dinner, but vegan available there, too.

Osaka

Asakara Good Store

Excellent breakfast, mostly western diner-style, vegetarian and vegan options aplenty in a cozy and relaxing atmosphere and great service. So good, we went twice. Great location for visiting Osaka Castle before or after.

Notes:

You order via a website on your phone.

Links:

—

Mercy Vegan Factory

A bright and friendly restaurant and bakery. All food is vegan, and a selection of ingredients can be purchased for home use. They do traditional lunch/dinner as well as sandwiches and cakes, which make great to-go items.

Links:

—

Shukhansana Pozzuoli

Pizza & Pasta, not usually the cuisine you go to Japan for, but this is an excellent one-man operation. The tiny restaurant seats maybe 10 people and you get a full view of the even tinier open kitchen. It is a pleasure to see the maestro at work while you wait. The pizza is excellent and the service is very friendly.

Notes:

Reservations are recommended
Take-out is not guaranteed if the current pizza queue is too long

Koyasan

Maruman

This was a spontaneous discovery for us as the restaurant we had planned to visit was closed on the day. This is a casual Japanese lunch place with limited western-style seating, so expect to take of your shoes and sit on tatami. At the time of visit there were two vegan dishes on the menu and the staff is happy to help you find them.

Himeji

Il Riccio

Spacious yet cozy lunch spot and organic food store in central Himeji perfectly situated half-way between train station and castle. Food, ambience and kitchen staff look like they came out of a Ghibli movie and the food is excellent.

Hiroshima

Jirokichi

Tiny Hiroshima Okonomiyaki place straight out of Cowboy Bebop. This is noodle-base Okonomiyaki that is distinct from the Osaka variant. The atmosphere is great and the food is delicious. Main dishes are prepared Teppanyaki-style and served on your own per-table hot plate. The menu has a distinct section for vegan options. Do not miss. Close to the Peace Park.

Notes:

The restaurant is on the second floor (2F).
Reservations are recommended and only available via phone.
- The host speaks a little english, if you keep your language simple you will manage as we did.

Links:

—

Kissa Saeki

Friendly organic daytime café serving various main dishes as well as coffee, tea and cake. Second generation family-owned vegetarian and vegan operation with many gluten-free options. Service is very friendly and the food is excellent. Close to the Peace Park and Fukuromachi shopping area.

Notes:

Cash only

Links:

—

JoGeSaYu

Modern and bright Japanese vegan restaurant with a focus on flashy dishes. The food quality is mid-range for Japan, so pretty good overall. The menu is on the larger size, which makes this a good spot for larger groups and the larger-than-usual dining hall size helps as well. The service was friendly.

Miyajima

Sonoma

Tiny curry-serving cafe with a chill atmosphere. Vegan options on Miyajima are a little limited and we are very happy to have found this. It’s on the way to/from the ropeway station.

Nagoya

Miho’s Kitchen Grains

My favourite of the trip. Miho runs this place solo with occasional serving help. Our first night there was so good, we just went again the next day. Nagoya being a little less touristy translates to vegan food being less abundant.

Miho spent two years developing and crowdfunding “Okacon”, a delicious pork-rind like vegan meat substitute that she now exclusively sells. It is very versatile and nutritious on top of being extremely tasty. I’m most impressed by the fact that part of the ingredients is an otherwise discarded byproduct from tofu production that goes to waste at 700,000 tonnes per year.

The dishes Miho creates from this are out of this world and you can’t get them anywhere else.

On top of all that, the fermented tomato base Ramen is the best soup I’ve eaten in my life (sorry gran).

Seating is traditional (no shoes, you sit on tatami floors) and extremely limited, you basically get to hang out with two more parties in Miho’s living room while she cooks.

If you’re visiting Ghibli Park or Sekigahara (or both), make this your staple dinner place. It’s conveniently close to the train station.

Notes:

Reservations via Instagram

Ghibli Park

Ghibli Park Café Tairiku Oudan Hiko

The cafe outside the great warehouse features a single vegan avocado sandwich that will get you through the day. Pro-tip: share three among two people and bring some snacks for variety.

Sekigahara

Ibuki-ann

The cafeteria in the annex of the Sekigahara battlefield museum and memorial features a single vegan udon soup. You order via the machine next to the kitchen. Do ask staff to point you to the right option, they are extremely helpful and friendly.

Even More

Here’s a list of places we had to skip for various reasons, but would have gone to if we didn’t randomly go to one of the other places in the spur of the moment. Gmaps links only, apologies.

Tokyo:

Kyoto:

Osaka:

Koyasan:

Sukhasana

Hiroshima:

Nagataya Note: we did an inquiry here during the day while shopping nearby and staff was surprisingly rude, so we didn’t pursue it further, maybe you have better luck.

Sekigahara:

Andante

AI Veganism

2026-02-02T00:00:00+01:00

I have finally worked out why the “AI-vegan” narrative is a logical fallacy.

AI-boosters, and yes, that includes all you with the “nuanced takes”, use it to absolve themselves.

The “choice to forego meat on ethical grounds” analogy would work if programming was always done with genAI and now folks are abstaining because the numerous externalities are no longer bearable.

But in fact we have not been programming with genAI this whole time and now we have discovered meat, a way to produce protein in one of the most atrocious ways imaginable.

However, we are not using that protein to feed the starving. Instead the people who already have more than enough food to last a lifetime, get their fill of protein a little bit faster. And producing that protein takes away nutrition from the people who don’t have enough of it in the first place.

That’s the actual analogy.

How to disable Google Gemini in your Google Workspace

2025-01-17T00:00:00+01:00

Google has started to aggressively out-roll their Gemini AI service and is opting everyone into not only the feature but also a 17% price hike come March.

For Google Workspace users, there is no obvious way to out-out of Gemini in Gmail or Google Docs.

Within a day of this arriving, I received multiple employee complaints about the invasiveness of the service in the respective UIs. That sufficiently motivated me to find a way to turn it all off.

After touring admin.google.com for a good while I concluded there is no off switch. But I can now tell you how to get one (or four, to be precise), check this out:

How do you get this? Simple-ish! Talk to support. The upper right corner of your Workspace admin dashboard has question mark icon that lets you contact support. I opted for a chat and after three escalations to higher levels and (nicely) persisting I wanted Gemini to be disabled (rather than replying to their somewhat useless banter) my fourth support contact was able to enable the disable UI for me.

You will find it under Generative AI -> Gemini for Workspace after it has been enabled for you.

This won’t opt you out of the announced price increase, but at least the invasive UI clutter and questionable results are disabled.

Good luck!

Chocolate Chip Cookie Recipe (vegan & gluten-free)

2024-02-03T00:00:00+01:00

I made cookies, folks were interest in the recipe, I scrounged this from multiple others on the web to make this exact kind.

Ingredients

280 grams gluten-free flour, cake mix
1 tea spoon backing powder
1 tea spoon Psyllium seed husks
1/2 tea spoon salt
2 table spoons sweetener, I use half and half maple sirup and agave syrup
3 dashes of cinnamon
1 pinch of fresh vanilla
170 grams vegan butter, let soften in 2x2cm cubes for 10–15 minutes
60 grams vegan cream cheese
1 linseed “egg” (1.5 table spoons linseed flour, 3 table spoons boiling water, mix and let sit for 3 minutes)
vegan chocolate chips to taste, a crushed chocolate bar will do, dark ones to taste
crushed peanuts, pistachios and walnut seeds to taste
- Optional, replace one nut variety with 3 generous tea spoons raw cocoa powder OR add cocoa to the whole batch, in which case, use 6 generous tea spoons

Preparation

pre heat oven to 180ºC, over/under heat
first bowl: mix all the dry ingredients thoroughly
second bowl:
- separately mix all the wet ingredients except for the linseed “egg” and mix thoroughly for 2 minutes
- add the linseed egg and mix thoroughly for a further 5 minutes, hand mixer or kitchen aid recommended
  - the result should be creamy & fluffy and of a unified colour
combine bowls and mix briefly, a minute tops
separate 1/4 of the dough into your other bowl
add 1/4 of the chocolate chips and one of the crushed nuts variety, mix briefly
use two table spoons to make ca. 1–1.3cm thick and 4–6cm wide circle splotches onto baking paper leave 2cm space at least
repeat with 1/4th of the dough until you are out of nuts and/or cocoa

Baking

put backing paper on a grill sheet, or pre-heat while the oven warms baking sheet in a pinch
bake until the sides and top of the cookies have started to get brown for a good five minutes, approximately 15 minutes
when unloading, the cookies are still very soft and fragile, use spatular gently to move to a wooden cutting board for cooling off
let cool for 20–30 minutes
serve with favourite hot and cold beverages depending on season

Yum.

Ebike Recommendations

2024-02-02T00:00:00+01:00

I’m in the market for an ebike¹ and I asked around to figure out what is important when making a purchase decision. I am not asking for specific bike recommendations, but rather what criteria are important for making a decision. The responses were useful and I’m summarising them here, roughly grouped by topic.

Bike Tech

If you (like me) know a lot about “acoustic”² bikes, all that still applies.
Avoid bikes with custom parts to ensure you have an easier time repairing this long-term.
- This includes all-inclusive brands like VanMoof, Sushi or Cowboy.
Having lots of gears is less important on ebikes. Some folks prefer even no gears, even on hilly terrain.

Weight

weight is a mobility concern if you ever have to manoeuvre the bike up or down stairs.
25kg is not a bad weight for a (men’s) model.

Maintenance

Have a local shop that you trust to stick around for repairs.

Electrics

Motors are usually custom and there is new tech every ~two years. Go with big established brands like Shimano, Bosch or Yamaha.
Aim for easy battery removal so you can store and charge it safely.
Avoid rear-wheel motors, pedal-hub it is.
- Update: modern rear-wheel motors are getting better and are used in overall more lightweight bikes, keep avoiding older ones.
Update: Throttles (ask the bike to go on its own) are not classified as bikes in Germany but might be a neat feature if they are available in your jurisdiction.

Driving Experience

Always test drive in situations you are going to use the bike.
- Use bike rental shops or bike sharing programmes to get access to a trial bike.
Motor responsiveness varies, try out what suits you better, immediate power or more delayed action.
“Ebikes changed my life, I even sold my car”.

Purchase

Avoid secondhand bikes because motors can be shot and they can’t really be replaced.
If you want to save some money, go with previous year’s models, but no older than two years.
Add 1500€ to your “acoustic” bike budget for an ebike.
Cheap bikes are crap.

—

1. I’m going with Don Knuth on dropping the hyphen here as soon as possible.

2. 😂😘

Save Co.Up

2019-12-17T00:00:00+01:00

Story Time: When I was new in Berlin in 2007, I had worked from home as a freelance consultant for many years and I was ready to think about getting an office. One of the reasons why I was moving to Berlin was to have more opportunities to meet likeminded people.

In the city I moved to Berlin from, that is otherwise lovely, everybody was very much doing their own thing. Open source and community was not a topic at the time, and I didn’t feel rooted enough to start something. From Berlin I knew there was a PHP user group that people I knew regularly attended. That sounded exciting to me, I wanted to be part of something like that. One day, I found myself in a U-Bahn towards RailsConf EU randomly meeting @langalex on our way to RailsConf EU and we started talking. His company with @freaklikeme had just moved moved into a new office space, but they had a few desks to spare. At the time coworking wasn’t really a thing, but we had heard of it, so the idea to move in with them made immediate sense. Some time in 2008 I became the first renter of what was later to become @co_up. Soon joined by…

Soon joined by now Berlin veteran luminaries like @kriesse, @klimpong and @roidrage we had a lot of fun working our respective jobs, share lunches in good company and exchange knowledge about the technologies we were interested at the time. @langalex positively spent weeks teaching me git on the side.

At the time, I had occasion to go to California where I met @dreid, who I knew from my open source work on Erlang and CouchDB. He introduced me to the concept of a Super Happy Dev House (SHDH). Basically a weekend of hacking on fun stuff at the office.

One of the most mindblowing (to me at the time) things about SHDH was that it came with instructions on how to run your own: http://termie.pbwiki.com/HowToDevHouse. I thought how hard can it be? We have a nice office space, we had many friends who might be up for it.

So we ran one. Introduction and recap links: http://jan.prima.de/plok/archives/161-Introducing-DevHouseBerlin.html http://jan.prima.de/plok/archives/163-DevHouseBerlin-1.html It was a great success.

I met many fun people there over the weekend, many of which are still active in Berlin actively doing community work. In the recap, you can read about how the @SoundCloud founders popped by and hacked up a web-iTunes using jQuery UI on top of their API.

Just to highlight a single connection here, every single developer event I have done in Berlin that required sponsorship has since been supported financially by SoundCloud. And all attendees have countless of similar stories each.

Long story long: we caught a first glimpse of what benefits to the community it had to run open and accessible events, and we all would double down hard after this.

Our little office community quickly outgrew the original office space and we started looking for a larger place and settled eventually on what became the original @co_up: a larger coworking space, and success didn’t stop there.

On top of the coworking, we also kept organising events, like @berlinjs and @upfront_ug, which have since long been surpassed in number and frequency by multiple events every week (h/t’s @rmehner @sheley @carolstran. And most recently the inaugural @queerjs (h/t @nikkitaFTW.

A few years in, we again could make good use of a larger office space and a new floor had opened up in the same building and put up a little fundraiser to be able to cover renovations. In particular, we ordered custom-built folding tables that allowed us to transform the floor from coworking by day into a meetup space by night in the matter of five minutes. The @co_up third floor you all know and love today was born and we started to run events down there, and kept the coworking separate on the fifth floor.

One special one-off event, heavily inspired by the @RailsGirls project, we ran a JavaScript for Absolute Beginners workshop (JSFAB. h/t to @theophani and @marijnjh for the inaugural teaching materials https://writing.jan.io/2012/07/22/jsfab.html

JSFAB brought willing learners and willing teachers together in a safe space to enjoy technological education. For free. Even while planning the event, it became clear that this model of well-educated people with well-paid jobs using their privilege giving back to the community wasn’t limited to JavaScript, and Open Tech School was born at the same time, as an umbrella organisation for community-teaching, but for any topic. http://www.opentechschool.org— Open Tech School is worth its own thread, but they have run many hundrends of meetups for any and all topic imaginable. They’ve enhanced the initial teaching weekends with continuous learning groups that kept people growing, a proper, completely volunteer run school, for anyone, for free.

I frequently get asked about how to transplant, for example, @berlinjs into another city, and while donated office space is often available, there is usually a commercial quid-pro-quo, when a company opens their doors, which often is to the detriment to the event itself.

My first reaction usually is: well, for starters, you need a @co_up. A not-for-profit community space, centrally located, lots of tasty street food nearby (so you can avoid terrible pizza sponsorships), that is free to use for free community events. That’s then usually where the conversation stops, and I have to reflect that what @langalex and @freaklikeme have set up with @co_up and what the rest of the community has done to run with that is properly unique.

I am no longer able to remember and recount all the magical things that happened when one community or another came together. 10s of 1000s of people have been through @co_up events. 1000s have used events at @co_up as a first step into the community, like I did with PHP all those years back. Again 1000s have found new friends, new employers, new co-founders, even new partners and the collective benefit of bringing all these people together in the past 12 years is immeasurable.

Unfortunately, as you already know, capitalism. All this success has downsides. One of which is property speculation in the city going rampant. We finally have a rent break in place, but that’s after rent hikes of over 2x in 10 years just a few blocks away from @co_up.

Over the years, we have seen the building @co_up is located in transform from predominantly producing industry to IT. A lot less of which likely would have happened, if @co_up didn’t prove the viability of the location. None of that, however, counts today.

The @co_up third floor rent is getting jacked up significantly in January and @co_up is running a fundraiser to get the community to support paying the new rent. For me, this is an extreme no-brainer. Even after moving out of @co_up, @neighbourh00die kept supporting it.

From what I can tell, the fundraiser is mainly supported by individuals who experienced the benefit of a not-for-profit event space first hand and this warms my heart. However, the funding goal is mere peanuts for Berlin’s well-funded tech companies and startups.

The equation that supporting @co_up quickly amortises your recruiting costs, some of which are many times the monthly rent required to keep @co_up open, seems not to sink in.

Aside from a few trusted partners, Berlin’s startups are, unsurprisingly, happy to exploit the free support system, but I think it is a disgrace. If your company has any budgets left for 2019, or if you are ready to commit, even just a little monthly donation (say 100€), you can help make one of the pillars of Berlin’s community sustainable for the long term. Give generously, and #SaveCoUp. Take a minute to scroll through the hashtag and see how many people, how many user groups and meetups you could be supporting.

Bonus Story

One more bonus story. In 2015 during the West African Ebola crisis, a non-profit running vaccination programs in the region started setting up a development team in Berlin to be able to move faster. because @co_up was a natural fit for such a team, they settled quickly.

At the time, the Ebola-affected countries were dealing with many compounding crisis, including a lack of infrastructure. The non-profit set out to build tools to help first responders that turned pen-and-paper-based processes into mobile web apps.

That allowed first-responders to help more people faster, and make their work more organised and collaborative. When trying to contain an epidemic, time and speed are a factor.

Because of the lack of infrastructure, the team had already settled on @CouchDB and @pouchdb for their technological foundation, because no other technology was readily available and open source that would allow them to quickly build mobile web apps that worked offline.

One day over lunch, they asked around if the others at @co_up knew anyone who knew @CouchDB. As @CouchDB project management chair and longest standing contributor, I’ve had talked to each and every person at @co_up about it, if they didn’t stop me quickly enough and so we quickly got put together.

In the course of about 12 months, my team at @Neighbourh00die and I fully joined @eHealth_africa to build out the Berlin development team. We grew from ~6 to 29 in the course of six weeks and helped build tools that eventually ensured that the Ebola endemic could be stopped.

We also worked on the apps that ran the first clinical trial that later lead to the first Ebola vaccine in history.

A lot of things came together to make this happened, but if it weren’t for @co_up, it would likely have gone a lot slower.

Community Legacy

2017-09-18T00:00:00+02:00

Berlin’s most influential & groundbreaking coworking space Co.Up is closing shop. Their famous event space remains open.

As Co.Up’s first ever renter, nine years ago, about a year before it even became Co.Up, I feel obliged to say a few words. This is, however, not a eulogy.

On the surface, a coworking space is office space with tables for rent, and there’s at least one in every major city today. When what eventually become Co.Up started in fall of 2008, coworking was decidedly not a thing, not usual, not common.

Of course, people have shared office space since there was office space, but a dedicated office sharing culture, a notion of a temporary home for digital nomads with globally shared values, that was new. And Co.Up was at the forefront of this now ubiquitous movement.

sad to hear about the closing of @co_up as a coworking space. your atmosphere was formative for me. thank you, @freaklikeme and @langalex. — @electricgecko

In the past ten years, and without hyperbole, Co.Up has been the foundation and nurturing space for sustainable communities that started with technology, but now spans culture, education and the arts.

How is Co.Up different from other coworking spaces in this regard? The openness and willingness to try things that are different, that are unconventional, but ultimately the right thing to do.

Co.up was born out of the desire of Upstream founders Alex & Thilo to have a nice office they can share with others. Alex’s & Thilo’s community involvement made it an attractive space for other technologists to hang out. Later, and with Aleks’s initiative and support, other communities found a home at Co.Up.

These communities and the coworkers participating in them enabled thousands of people per year to connect, start out their careers in Berlin, find jobs, find partners in crime^Wbusiness, found companies, start user groups. Even OpenTechSchool, a global initiative in volunteer education, has its roots at Co.Up. On top of all this, countless friendships have found a beginning at Co.Up that have since long outlived the confines of the offices at Adalbertstraße. And this is only a tiny sliver of groups that started out at Co.Up.

Thanks co.up for being my work home for many years, for all the people I got to meet, and everything you did for the community :’( https://twitter.com/co_up/status/908617161308082176 — @kriesse

Co.Up’s probably most radical initiative was the opening of a 100+person event space that was free for events that were open to the public. I keep meeting folks that say they want to start something and they need place to meet and every time it comes down to Co.Up’s generosity to support the Berlin communities pro-bono that enables so much. In other cities and contexts, the deal usually involves a commercial involvement, hindering many initiatives.

Luckily, Co.Up’s event space remains open.

Met lots of great people by way of @langalex and @freaklikeme, and the team at @co_up. All the best on their next journey. — @klimpong

Personally, I’ve given up my desk at Co.Up in 2015 after founding Neighbourhoodie and needing a space of our own, but we continue to support Co.Up’s event space financially, like many other Berlin companies. I’ve simply outgrown the model of a coworking space and now Upstream is going through the same transition. As they mention in their closing blog post, success is a matter of focus, and their focus is now their software business Cobot, a very successful coworking space management software, so they are still very much support the coworking community.

My thanks to Alex, Thilo & Aleks for all their hard work. Your dedication will live on in the DNA of so many Berlin communities, people, and hearts.

Understanding the Facebook vs Apache Software Foundation License Kerfuffle

2017-08-19T00:00:00+02:00

Translation: French by @gnieh_

Disclaimers: I am not a lawyer. I’m not speaking for Facebook, the ASF, or CouchDB. This is a personal view on the matter.

tl;dr: Projects at the Apache Software Foundation can no longer use dependencies that are distributed under Facebook’s “BSD+Patents” license, including React.

Intent of this post

I’m trying to explain the situation in simple language and without bias. There is a lot of misinformation around this issue that I hope I can clear up here. If there is anything that I got wrong here, please do let me know.

What happened?

April 20th: Apache Cassandra asked ASF legal if they could use RocksDB as a dependency, which was then licensed as BSD+Patents or GPL2.
June 17th: After a lengthy discussion, ASF’s Vice President of Legal Affairs Chris A. Mattmann concluded that Facebook’s BSD+Patents license is not compatible with ASF’s policies about dependencies.
July 15th: RocksDB changes its dual-license from BSD+Patents to Apache License 2.0 & GPL2 (that means you can choose to use either license when adding RocksDB as a dependency). As a result, RocksDB is now compatible with all ASF policies again.
July 17th: upon searching for other dependencies with the BSD+Patents license, React is singled out and the ASF is asking for clarification in the hopes that it can follow the RocksDB example.
August 18th: Facebook releases a statement and closes the respective GitHub issue stating they are staying with the BSD+Patent license.

Why did it happen?

To understand the conflict, we need to examine what the ASF and Facebook respectively are trying to achieve with their policies and licenses.

Aside: I want to make doubly clear that I’m not trying to take sides in any of this, I’m merely explaining the underlying intentions of very dense legal texts. In my opinion, both Facebook and the ASF can do whatever they want in terms of licensing. And if their goals differ, that might lead to conflict, like in this case. That’s unfortunate, but that’s the messy world we live in.

The ASF Side

It is the ASF’s Policy, that anyone using Apache projects as a dependency for an Open Source or commercial project can do so without (m)any restrictions.

The Apache License 2.0 lists a few restrictions, briefly:

you can’t use the Apache project’s name or trademark(s).
you must include a copy of the license and a notice that the project in question is being used by your project.
if you changed anything in the Apache project, you need to mention that too.

In return, the Apache License 2.0 then grants you a copyright license that lets you do whatever. This is what’s most relevant to other Open Source projects.

It also grants you a patent license, which is most relevant to commercial users of Apache projects.

As an example, this means I can take Apache CouchDB and release it as a new commercial and closed-source database JanDB. Given that I abide by the requirements mentioned in the Apache License 2.0 (as summarised above), with or without modifications, for free or for money or any other purpose I choose.

This “downstream freedom” is a major intention of why the ASF exists in the first place and is as such encoded in their policies and licenses.

Now, the Apache License 2.0 includes one more restriction and its part of the aforementioned patent license. If you are using an Apache project you can’t use any of your patents to claim that the ASF or anyone else who is using that same project is infringing on your patent without losing the patent license to the Apache Project.

In the JanDB example, if I hold a particular patent on database technology, I can’t sue any other CouchDB users over that patent, without also losing my patent license for CouchDB from the ASF. I can still sue them over other matters, including patents infringed on by other software the other companies are using.

In order to make it simpler for Apache projects to decide what kind of licenses its dependencies can have, the ASF has created a handy overview of allowed, and disallowed licenses, and everything in between. The disallowed licenses are classified as “Category X” licenses. This list includes a number of very popular Open Source licenses including the GPL family and many others.

The Facebook Side

Facebook’s focus with its BSD+Patents license is protection against so-called “frivolous” or “meritless” lawsuits. In short: if you are a big company with lots of money and exposure, enterprising assholes will try to come after you for whatever reason to legally extract some of that money or exposure. Patents are a prime vehicle for such asshattery.

The BSD+Patents license is designed to minimise these lawsuits for Facebook, and with the August 18th decision they have confirmed that this remains a high priority.

The Facebook patent clause has a similar restriction to what the Apache License 2.0 states, except, it is broader in definition. Whereas the Apache License 2.0 version specifically restricts its clause to “the Work” (say Apache CouchDB), the Facebook patent license is revoked when any “Patent Assertion” is brought up against Facebook.

So if you have a patent that you think some part of Facebook infringes upon, but is unrelated to your use of React, you lose your patent license to React when you decide to sue Facebook over that patent. In the Apache License 2.0 case, you only lose the patent license if you assert the same infringement for the project you are yourself licensing (say Apache CouchDB in the “JanDB” example).

In October 2014, Facebook switched React from the Apache License 2.0 to BSD+Patents explicitly, because it contains a broader protection and in October 2016 have confirmed their intentions in call between the ASF and Facebook.

What does that mean?

Projects at the Apache Software Foundation can not use any dependencies that are labelled as Category X by the ASF’s Legal team. This includes React + ecosystem projects that are also released by Facebook under the BSD+Patents license. Projects that already use such dependencies can not make any new releases past August 31st, 2017 including these dependencies, and have to migrate away from these dependencies now.

Affected projects are (at least): Cordova, Superset, TrafficControl, Ambari, Allura, Whimsy, Spot, Myriad, CouchDB, Lens, SensSoft, ~~Sling~~ (Updated August 22nd).

FAQ

What are the options for ASF projects now?

remove the dependency altogether, or find an alternative that has a compatible license, and deal with whatever extra work that needs to be done to make the migration.
move to a plugin architecture where the BSD+Patents licensed plugin is maintained and distributed outside of the ASF, but can be added by end-users.

Aside: it is true that there are projects that have (or claim) API compatibility with React, that come with compatible licenses. “Just use X” is a common recommendation that ignores a bunch of realities:

React is more than just it’s core, but there is a wide ecosystem for many related tasks around building web apps. Many of those related projects are also licensed under BSD+Patents, so they can’t be used either, and few or no replacements exist for those. So “moving to X” is not as trivial as it might sound, depending on the level of other projects that are used on top of React. As a point of data, for CouchDB’s Fauxton admin interface, the porting work is estimated at 3+ months of dedicated developer time for switching away from React. In our case, it’s a significant time investment that takes valuable developer time away from other pressing matters.
React includes a number of technical innovations, some folks have suggested to move to another framework that includes a subset of these innovations (say JSX), but not any of the other ones, including API compatibility. Moving to such a framework is significantly more work than the previous option. In CouchDB/Fauxton’s case, that is very likely prohibitive, but we’re still exploring options.

Why didn’t the ASF do this sooner?

The ASF Legal team doesn’t proactively review any and all software licenses. This issue was brought up on April 20th, 2017, and resolved within the ASF by June 17th.

What does that mean for the license compatibility with other Apache License 2.0 licensed projects using React?

Nothing.

The incompatibility is between the BSD+Patents license and ASF policy.

What does this mean for my (open source or closed source) project that uses both ASF and React software.

Nothing.

What does this means for me/my Open Source project/my company that is using React?

Nothing.

Unless you are part of the ASF or another organisation that has a similar policy regarding the BSD+Patents license. There seem to be a few.

Why was RocksDB relicensed and React et.al. weren’t?

I can only speculate, but React is a much much larger target, was differently licensed from the get go, and Facebook is interested in having RocksDB support in Cassandra and seems to be contributing that work. But I wouldn’t know for sure.

Aren’t Software Patents just the worst?

Yes.

But I’d rather have the ASF and Facebook be upfront about their intentions than leaving things in the dark like most other Open Source projects and companies.

Comprendre le bazar de licence entre Facebook et l’Apache Software Foundation

2017-08-19T00:00:00+02:00

Note du traducteur : Ceci est la traduction du billet daté du 19 août 2017. Pour toute correction ou commentaire, contactez moi

Avertissement : Je ne suis pas avocat. Je ne parle pas au nom de Facebook, l’ASF ou CouchDB. Ce billet reflète uniquement mon point de vue personnel sur le sujet.

tl;dr : Les projets de l’Apache Software Foundation ne peuvent plus utiliser de dépendances distribuées sous la licence Facebook « BSD+Patents », y compris React.

But de ce billet

J’essaierai d’expliquer la situation en des termes simples et sans biais. Beaucoup de fausses informations ont circulé sur le sujet et j’espère pouvoir clarifier la situation ici. S’il y a quoi que ce soit que je ne rapporte pas correctement ici, faites le moi savoir.

Que s’est-il passé ?

20 avril : le projet Apache Cassandra a demandé au département légal de l’ASF s’il pouvait utiliser RocksDB en dépendance, qui était alors sous double licence BSD+Patents ou GPL2.
17 juin : après une longue discussion, le vice président des affaires légales de l’ASF, Chris A. Mettmann, a conclu que le licence Facebook n’est pas compatible avec les règles de l’ASF sur les dépendances.
15 juillet : RocksDB change sa double licence de BSD+Patents à Apache License 2.0 & GPL2 (cela signifie que vous pouvez choisir d’utiliser l’une ou l’autre des licences lorsque vous dépendez de RocksDB). Le résultat est que RocksDB est désormais à nouveau compatible avec toutes les règles de l’ASF.
17 juillet : en cherchant d’autres dépendances sous licence BDS+Patents, React particulièrement est remarqué et l’ASF demande des clarifications en espérant que React suive l’exemple de RocksDB.
18 août : Facebook publie un communiqué et ferme le ticket GitHub associé, annonçant qu’ils restent avec la licence BDS+Patents.

Pourquoi cela est-il arrivé ?

Afin de comprendre le conflit, nous devons examiner ce que l’ASF et Facebook essaient respectivement d’atteindre avec leurs règles et licences.

Note: j’aimerais mettre doublement au clair le fait que je n’essaie pas de prendre position dans tout ça, j’explique simplement les intentions sous-jacentes aux textes légaux qui sont très denses. Selon moi, Facebook et l’ASF peuvent chacun faire ce qu’ils veulent en terme de licence. Et si leurs buts diffèrent, cela peut conduire à des conflits comme c’est le cas ici. C’est dommage, mais c’est le monde désordonné dans lequel nous vivons.

Du côté de l’ASF

La Politique ASF veut que chacun puisse dépendre des projets Apache pour un projet Open Source ou commercial, et ce sans (trop de) restriction.

La Licence Apache 2.0 liste quelques restrictions, en résumé :

vous ne pouvez pas utiliser les noms ou marques déposées d’un projet Apache ;
vous devez inclure une copie de la licence et une note indiquant que le projet en question est utilisé par votre projet ;
si vous changez quoi que ce soit dans le projet Apache, vous devez aussi le mentionner.

En retour, la Licence Apache 2.0 vous accorde une licence de copyright qui vous permet de faire ce que vous voulez. C’est ce qui est le plus important pour les autres projets Open Source.

Elle vous accorde aussi une licence de brevet, ce qui est plutôt important pour les utilisations commerciales de projets Apache.

Par exemple, cela signifie que je peux prendre le projet Apache CouchDB et le redistribuer en tant que nouvelle base de données commerciale et propriétaire JanDB. Tout cela sous réserve que je respecte les exigences de la Licence Apache 2.0 (tels que résumées ci-dessus), avec ou sans modification, gratuitement ou de manière payante, ou pour tout autre but de mon choix.

Cette « liberté en aval » est la raison première de l’existence de l’ASF et est inscrite ainsi dans ses règles et licences.

De plus, la licence Apache 2.0 inclut une autre restriction qui fait partie de la licence de brevet susmentionnée. Si vous utilisez un projet Apache, vous ne pouvez utiliser aucun de vos brevets pour affirmer que l’ASF ou quiconque utilise le même projet viole votre brevet, sans perdre la licence de brevet sur le projet Apache.

Dans l’exemple de JanDB, si je détiens un brevet sur les technologies de base de données, je ne peux attaquer aucun autre utilisateur de CouchDB sur ce brevet sans perdre dans le même temps ma licence de brevet pour CouchDB accordée par l’ASF. Je peux cependant toujours poursuivre ces utilisateurs pour d’autres raisons, incluant des violations de brevet par d’autres logiciels utilisés par ces utilisateurs.

Afin de rendre plus facile la tâche de décider quel type de licences les dépendances des projets Apache peuvent avoir, l’ASF a créé un aperçu très pratique des licences autorisées et non autorisées, et tout ce qui est entre les deux. Les licences non autorisées sont classifiées dans les licences de « Catégorie X ». Cette liste inclut un bon nombre de licences Open Source très populaires dont la famille GPL et bien d’autres.

Du côté de Facebook

L’intérêt de Facebook avec sa licence BDS+Patents est la protection contre les poursuites dites « frivoles » ou « vexatoires ». En résumé, si vous êtes une grosse société avec beaucoup d’argent et une grande exposition, des enfoirés entreprenants essaierons de vous poursuivre pour quelque raison que ce soit afin de vous extorquer légalement cet argent et cette exposition. Les brevets sont un outil de choix pour ce genre de connerie.

La licence BDS+Patents est conçue afin de minimiser ces poursuites judiciaires contre Facebook, et avec leur décision du 19 août, ils confirment que cela reste un grande priorité.

La clause sur les brevets de Facebook a une restriction similaire à ce que la licence Apache 2.0 exprime, sauf que sa définition est plus large. Là où la version de la licence Apache 2.0 restreint spécifiquement sa clause au « Travail » (disons Apache CouchDB), la licence de brevet Facebook est révoquée dès lors qu’une quelconque « revendication de brevet » est portée contre Facebook.

Ainsi, si vous détenez un brevet que vous pensez être violé pas une partie de ce que fait Facebook, mais qui est sans lien avec React, vous perdez votre licence de brevet pour React dès lors que vous poursuivez Facebook sur ce brevet. Dans le cas de la licence Apache 2.0, vous perdez uniquement la licence de brevet si vous revendiquez cette violation par le projet que vous licenciez vous même (soit Apache CouchDB dans l’exemple de JanDB).

En octobre 2014, Facebook a changé la licence de React de la licence Apache 2.0 vers BSD+Patents, explicitement car elle contient une protection plus large, et en octobre 2016 Facebook a confirmé ses intentions dans un appel avec l’ASF.

Qu’est ce que ça signifie ?

Les projets de l’Apache Software Foundation ne peuvent pas avoir de dépendances classées dans la Catégorie X par l’équipe légale de l’ASF. Cela inclut React ainsi que les projets de l’écosystème qui sont publiés par Facebook sous licence BSD+Patents. Les projets qui utilisent déjà ce genre de dépendances ne peuvent plus publier de nouvelles versions après le 31 août 2017 qui incluent ces dépendances et doivent se séparer de ces dépendances maintenant.

Les projet affectés son (a minima) : Cordova, Superset, TrafficControl, Ambari, Whimsy, Spot, Myriad, CouchDB, Lens, SensSoft, Sling.

FAQ

Quelles sont désormais les options des projets ASF ?

Supprimer purement et simplement les dépendances ou trouver une alternative publiée sous une licence compatible et assumer tous le travail additionnel qu’une telle migration impose.
Migrer vers une architecture de plugin où les composants sous licence BSD+Patents sont maintenus et distribués en dehors de l’ASF, mais peuvent être ajoutés par les utilisateurs finaux.

Note : il existe des projets qui ont (ou affirment avoir) une API compatible avec React et qui sont publiés sous une licence compatible. « Tu n’as qu’à utiliser X » est un conseil classique qui ignore tout un tas de réalités :

React est plus que son cœur et a un large écosystème pour de nombreuses tâches relatives à la construction d’applications web. Beaucoup de ces projets annexes sont aussi sous licence BSD+Patents et ne peuvent ainsi pas être utilisés non plus et peu ont un remplaçant compatible. Ainsi « migrer vers X » n’est pas aussi trivial qu’il n’y parait suivant le nombre d’autres projets qui sont utilisés par dessus React. À titre d’information, pour l’interface administrateur Fauxton de CouchDB, le travail de portage est estimé entre un et deux mois de travail à plein temps d’un développeur pour ne plus utiliser React. Dans notre cas, il s’agit d’un investissement en temps non négligeable qui prend un temps précieux au développeur sur d’autres sujets plus importants.
React contient un bon nombre d’innovations techniques, et certaines personnes on suggéré de migrer vers un autre framework qui contient une partie de ces innovation (par exemple JSX) mais pas toutes, incluant la compatibilité de l’API. Migrer vers un tel framework requiert sensiblement plus de travail que l’option précédente. Dans le cas de CouchDB/Fauxton, ce coût est très probablement prohibitif, mais nous explorons encore des options.

Pourquoi l’ASF n’a pas fait ce travail plus tôt ?

L’équipe légale de l’ASF ne relit pas de manière préventive toutes les licences logicielles. Ce problème a été soulevé le 20 avril 2017 et résolu par l’ASF le 17 juin.

Qu’est-ce que cela signifie pour la compatibilité de licence avec d’autres projets sous licence Apache 2.0 utilisant React ?

Rien.

L’incompatibilité se trouve entre la licence BDS+Patents et la politique de l’ASF.

Qu’est-ce que cela signifie pour moi/mon projet Open Source/ma société qui utilise React ?

Rien.

À moins que vous fassiez partie de l’ASF ou de toute autre organisation qui a une politique similaire envers le licence BDS+Patents. Il semble y en avoir quelques-unes.

Pourquoi RocksDB a été relicencié et pas React et les autres ?

Je peux seulement émettre des hypothèses, mais React est une beaucoup plus grosse cible, a été licencié différemment depuis le début, et Facebook semble intéressé par avoir RocksDB pris en charge par Cassandra et semble contribuer à ce travail. Mais je ne peux en être sûr.

Les brevets logiciels ne sont-ils pas juste terribles ?

Si.

Mais je préfère voir l’ASF et Facebook clairs sur leurs intentions que de laisser les choses dans le flou comme le font la plupart des autres projets Open Source et sociétés.

Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source

2017-03-06T00:00:00+01:00

If you want your open source maintaining to be sustainable, you need to stop caring.

Wait what?

Nolan wrote a very in-depth description of what maintaining open source projects can feel like.

Mikeal suggests leaving projects is the solution, which I think is only the most extreme option.

I’m offering middle ground: stop caring.

I can relate to everything that Nolan is saying and I must know that Mikeal’s solution is always an option in order to be able to not care effectively.

Inbox Zero Redux

Before I stop caring though, I’d like to address a flaw in how I see people apply “Inbox Zero”. Nolan uses the powerful metaphor of people in front of your door with their problems.

Just because there are people with problems in front of your door, that doesn’t mean they are your problems. You can choose to make them yours, but you want to be very careful about what to care about. Ideally you don’t care about any of these problems and none of these people (more on the people later).

Inbox Zero doesn’t mean you have to have looked at everything, or even handled everything (like replied to every email or commented on every issue), but to have sorted everything into piles that you can work on in batches (it’s more efficient from a context-switch perspective) when you have the time.

When you have the time. This implies that you have to make time to actually resolve issues coming into your inbox. This also means: if you can’t make time, these issues are not going to get handled. And the only way to be okay with this is to stop caring about the issues.

And being very good about being able to bubble to the top what you do want to take time for.

GitHub Notifications, like Email, is often treated as a world-writable todo list. This works for small number of people writing issues, but with a semi successful open source project or multiple small ones, you easily surpass this being a useful model.

As a result I treat all my open source notifications and email as: I might not get to this.

Caring

This is from my perspective of maintaining two large-ish Open Source projects: Apache CouchDB and Hoodie and many many small projects I started, or contributed to. CouchDB even went through the birth of the NoSQL database category, so on top of all the Open Source stuff, I had a nascent venture capital infused industry to deal with.

All the advice I have here is for later-stage Open Source projects. For early stage projects, care is the only thing you can give them. But once you’ve shipped version 1.0.0 or even 2.0.0, once you wrote all the documentation, once people start using the project in production with success, once you’ve talked the 100th person through getting started on IRC or Slack, your priorities have to change.

Here’s the list of things I do care about in later-stage Open Source projects:

Code of Conduct violations: these are basic ground rules that govern everything we do in a project. If somebody doesn’t play along, that needs to be dealt with asap.
Security issues: once you are used in production, handling security issues swiftly and professionally is a imperative. Since they can pop up at any time, you want to be having some spare time that you can allocate to this at all times. That doesn’t have to be you individually, but as a project, you always need to be able to handle these.
Trademark violations: Apache CouchDB is a registered trademark, and within the Apache Software Foundation it is the job of the Project Management Committee to go after trademark violations. US trademark law requires action against transgressors for a trademark to be upheld. So this is something I have to do. These things aren’t as urgent as security issues, and are usually solved with a form letter.
No new contributors coming in and signs of fellow maintainer burnout: I’ve written at length about this before in Sustainable Open Source.
Do I sleep/eat/have fun/sport/partner/friends/nature enough? If I don’t function, I can’t give anything to projects or people in Open Source. Michael Bromley sums it up nicely in Why I Haven’t Fixed Your Issue Yet.

Not Caring

Here is a list of things that come up repeatedly, with any variety of urgency, anger, and frustration:

“Hey, I found [other database] works better for me.”: Great! I don’t care.

“Hey I’m building this app / solving this university assignment, can you help me with…”: No, don’t care.

“Hey, I see you haven’t released a new version in X days/weeks/months/years”: I don’t care.

“Hey, I found problem X in your tool”: I don’t care.

“Hey, I can’t get started with your thing”: I don’t care (I’ve already written the docs).

“Hey, I reported this issue, but nobody is picking it up”: I don’t care, send a PR and it might get better.

“Hey, I opened a PR and it doesn’t get merged”: I don’t care.

“Hey, I opened a PR and it doesn’t get merged, and now I’m frustrated and I blame you for stringing me along to spend so much time on this.”: I especially don’t care about guilt-tripping.

“Hey, I read on Hacker News…”: I don’t care.

“Hey, your project is shit.”: Don’t care, insta-block.

None of this is to say that I don’t try and address these people’s issues and concerns, as much as I can, too. But on my terms and in my time, and the only thing that lets me sleep at night is not caring about any of these things. I’ll get to them eventually, some may fall between the cracks.

It’s not nice from a project or people perspective, but short of leaving the project and leaving it all behind, I found this to be the only way to make my personal Open Source maintainership sustainable.

Ten Years with CouchDB

2016-10-23T00:00:00+02:00

I read a lot of biographies. There is a pattern where people move on after ten years on a project, be it a band, a movie franchise, a company, or an open source project. Not everyone leaves whatever they are doing after ten years, but there is a definite trend.

A few years ago, when my ten years with CouchDB started showing up on the horizon, I started wondering whether I’d be one of the people that feel after ten years, they have given their project everything they had to give, and that they had to move on.

I started preparing for the fact that I might feel like I’m done with CouchDB. I started thinking about what that would mean in terms of transitioning my duties at the project.

I never got very far. A scenario where I wouldn’t be part of the CouchDB project just didn’t present itself. So while still being open minded about the ten year mark, I stopped worrying about it.

Getting Started

CouchDB 2.0 just came out. It is a major milestone in the project. In a way it is finally fulfilling CouchDB’s original vision. It occurred around my ten year anniversary, and from a timing point of view, it would be the perfect moment to move on.

But I never felt it. I never felt being done. Instead, I feel we are just getting started. We’ve got the basics down now and there are a large number of topic areas that we can pursue to make CouchDB a lot better for a great number of people.

From the Archive

My first contribution to CouchDB was a Unix-compatible build system (Linux, FreeBSD & Mac at the time). Custom Makefile and everything. It became part of CouchDB 0.5.0 and I threw in a Mac application as well.

I have since worked on every part of the project, and I have a long list of things I’d like to achieve before I feel I’ve given CouchDB everything I’ve got to give.

I feel like I’m just getting started.

Sustainable Open Source

2015-11-20T00:00:00+01:00

Recently, two major open source projects in the JavaScript world have started pleas to contributions, because they were running out of people to move the projects forward.

Reading the issues and tweets around this, I accidentally a Twitter rant (*). Now I want to write this up with a little more detail.

All of this is based on the premise that the lifeblood of an open source project are the people who work on the project. If you disagree with that premise, you don’t have to keep reading (I’m not saying you are wrong, but you won’t get anything out of this).

Another premise here is that open source projects are largely contributed to by people in their spare time. Of course that’s not all open source projects, and those who have paid full- or part-time staff still benefit from this discussion, but I want to focus on the scenario where people contribute to projects, and create a benefit for the larger community, in their own time.

In the twitter rant, I postulated a list of priorities for open source projects, if they want to be run sustainably. Before I go into the priorities, let me explain what I mean by a sustainable open source project.

Sustainable Open Source Project

A sustainable open source project is one that, during its lifetime, does not run out of contributors. There are two factors here that make projects run out of people:

1. Existing people leave the project.
2. No new people join the project.

To keep people who are already contributing, there are few basics things you need to get right.

1. Care about them as people, rather than producers of contributions (whether it is code, or docs, or designs for the website).

For example: if somebody promised to do something at a certain time, but then life gets in the way: don’t chastise them, and don’t have a culture of where they are even afraid of telling you that they are missing the deadline. Support them in their hardship, be open and understanding of people’s limited time. You don’t have to become their counsellor, but caring about your collaborators as people instead of just the code they commit makes all the difference.

2. Make sure your contributors don’t burn out,

In open source projects there is always a lot to do, more than could ever be done in a reasonable amount of time, even if paid for full-time. That creates pressure for the people who care about moving the project forward, respond to all issues, review all pull requests, write all the docs, etc.

As the people who run an open source project, it is your responsibility that this pressure doesn’t eat up contributors. For example, observe whether people take a break from contributing. As in everything, you must take breaks to be successful long-term. Maybe have a policy where people have to take a week or two off from participating in the project every three months. I’m sure you can think of other ways that would work for you.

3, Make sure there are enough people who, together, can take on the workload of the project, even with people taking regular breaks. If you can’t get enough people together, reduce the scope of the project until it matches what your contributors can handle.

This specifically includes not only writing code, but writing docs, supporting end-users in issues, on Slack/IRC, StackOverflow etc, project marketing (updating the blog/twitter/tumblr), keeping drive-by contributors happy by reviewing pull requests and issues in a timely and friendly manner, and so on. There are ton of time-hogs that are not obvious in open source projects.

For larger projects this even includes press inquiries, legal topics (licensing and naming are just two of the very hairy topics that eat a lot of time, in my experience), coordination with other projects in the space, work on foundations (hello Node.js) etc.

tl;dr: Open Source projects are a lot more than just committing code to a repository somewhere. Make sure you have enough people to handle what you want to achieve.

4. Have a Code of Conduct and be prepared to enforce it. As with all human things, people are bound to disagree. A CoC will bind everyone to keep disagreements civil and productive. And yet, some people won’t play by the rules, or understand the rules in a different way. And with a potentially global audience, cultural difference will make this doubly complicated.

But: you have to have a Code of Conduct that explains what happens if somebody repeatedly violates it. And when that happens, you have to act on what you wrote down. In most extreme cases, this means expelling an individual from the community. This is one of the hardest things I’ve ever done while running an open source project, but it has to be done.

Getting new people to join the project

All of the above will help you retain people, once they are engaged with your project. Here are a few tips on how to make sure you have enough new people coming in to shoulder all the work, account for people taking breaks, and account for others losing interest, or having other commitments.

1. Always be recruiting.

As an open source project, your scarcest resource is people’s time and attention. In order to get anything done, you will need more people. And as everywhere else, recruiting is hard, so it has to be your top priority.

For example: there’s a tough bug in your code, you could sit down for an hour and fix it. Or you could sit down for an hour and write an issue that explains enough of the context of the project so someone else would be able to fix it. Do the latter and you have a chance of recruiting someone, while at the same time more than one person can learn about the project’s internals from the issue, maybe take that part of the issue and put it into your README under “developer documentation.”

There are many, many more opportunities on how to involve new people rather than “quickly doing it yourself”, try to find out which ones apply to your project.

2. Again: Care about the people first and their contributions second.

Naturally, newcomer’s contributions aren’t as complete or far-reaching than those of experienced contributors, so it is doubly important for you care about the people and their enthusiasm about your project more than that typo-fix they put on the website. We’ve turned someone who fixed a single typo on the website to a steady contributor and well respected community member that now helps out all over the project at Hoodie, for example.

At the Apache Software Foundation, where the CouchDB project is run, we have a mantra: Community over Code. — It is a hard learned lesson from running high-profile open source projects like the Apache Web Server, Hadoop or Lucene, for over 20 years now. The reasoning is simple: if the right people rally around an idea, the right code will follow. But without a community who cares, no ever so brilliant piece of code, is worth anything.

This takes very little of your time and makes all the difference.

3. Document your processes.

Have you ever been to a (tech-) event where you didn’t know anyone, but everyone else seemed to stand in groups and chat like old friends? — I’ve been to tons of them, and as an introvert, this is not a lot of fun, and even as an extrovert, this is a challenge.

Now imagine you want to contribute to an open source project where you see some people doing some work, but you don’t see why or how this is happening and where people talk about things.

Here are a few things that happen in your open source project that are handled implicitly. You personally have no problem with this, because you either invented the practices, or were around when they were established, but for a newcomer, these are impenetrable barriers to participating.

Releases. Someone somewhere puts a tag into git, a tarball on a website, or a package into your package manager. Who decides when that happens? What objective criteria need to be fulfilled before a new release is made? Who or what decides whether a particular contribution, feature, or bugfix makes it into the next (or any) release? Who decides on the tag? Who publishes the tarball or package?

If you don’t document all of this in detail, you won’t get anyone ever helping with this. Usually, much of this is very implicit, and by making it explicit by documenting it, you often find that you have some flaw in your procedure, that you can simplify or automate a certain aspect, but most of all, somebody else can join and help.

“Hey, we are stuck on step 3 of the release process, does somebody have time to do 4 and 5?”

Accepting and declining Issues, feature requests and pull requests. Who decides whether an issue is an issue? Who decides whether a particular feature is merged from a pull request, or against the direction the project wants to go in? What are your commit message, code-listing and test-coverage requirements (use GitHub’s CONTRIBUTING.md)?

Put as much of your project’s vision and direction in writing. Of course a lot of this will be in flux as you go along, but if you copiously document this, anyone can jump in at any time and make the right call.

At CouchDB, we even went so far as to document our decision making process as part of our bylaws, which explain how the project operates. If this seems overly tedious bureaucracy to you, you do have a point: this takes time, especially agreeing on everything in large community, but it is very worth it. Since establishing the bylaws, we’ve had numerous new contributors come in and work as part of the project as if they’ve been around forever, following the right procedures to get their initiatives to a successful conclusion and thus making CouchDB a lot better.

Make your communication channels explicit*. At the ASF we have a rule that every project decision must happen on the dev@ mailing list in order for everyone having a chance to read about it in their own time and join the conversation at a central and transparent point.

At the same time, we have a busy IRC channel where we discuss a lot of ideas in a higher-bandwidth environment. However, once we get out of the half-baked stage for anything, we write it up on dev@ and have everyone else who couldn’t e.g. be on IRC at that moment (because they are on the other side of the globe, or at work) catch up with everything and partake in the conversation. Yes, this slows things down a little, but it makes sure everyone has a chance to see everything and be heard.

Whatever your communication channels are, make sure they are documented in your README, on your website and documentation. Make it easy (and free) for people to join and explain the etiquette of the medium.

Special shout out to the FreeBSD project, which is outstanding at documenting their inner workings <3

Specifically reach out to people for “positions” you want to see filled. At Hoodie, we’ve recently decided that we’d like to have a dedicated editorial team that handles our website, twitter, tumblr, etc. because the rest of us didn’t really have the capacities to maintain them all, and previous attempts made us lose two community members getting overwhelmed with the responsibility, so now we are recruiting a team (c.f. taking on only so much that you have enough people to handle it, see above).

As a result, we published a dedicated “job ad” for the position. We are just getting started, but the response has been so overwhelmingly positive that I strongly believe we’ll be very successful going forward with this for other positions. Try it.

Culture

In an earlier life I was deeply involved in the PHP community. One of the prime places to get support for problems with PHP was the IRC channel #php on EFnet. IRC and EFnet in particular are notoriously hostile places (I know there are worse IRC networks, I don’t need to be reminded of them), and that culture translated to the #php channel.

I was young and just thought that’s how things are. So I helped people out, and made fun of people who didn’t seem to know there way around (“press F4 to make this chat go faster”). I’m not very proud of being part of a hostile culture in hindsight, but at the time, I thought that’s just how things are.

Over time, I learned how beneficial it is to not antagonise people who are trying to use your open source project. Maybe in the context of PHP it didn’t matter because it was so popular, but later on, this got me thinking.

BIG FAT DISCLAIMER INTERMISSION: This is not a generalisation about the PHP community. As any community, the PHP community goes through its ups and downs and has its good and bad actors, but overall, the people who work on and with PHP are a great bunch that I have learned from half a career’s worth of knowledge and experience. Senior developers have mentored me (a high school student at the time) and helped me understand a lot about the web, not just PHP. I’m eternally grateful for this. INTERMISSION END.

When I started out at CouchDB and we finally joined the ASF and it was standard procedure to have a user@ mailing list for end-user support, I remembered my days in the #php channel and decided that that’s not the culture I want to have there. So for the first three or so years, I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.

My responsibilities since have shifted quite a bit and I’m no longer checking on the user@ mailing list day-to-day, but every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud.

Culture isn’t just what happens to you, culture is what you make of it.

Whatever you want your culture to be for your open source project’s community, as the people who are most visible, it is up to you to lead by example.

Money

If you follow my premise of people being the biggest asset in open source and recruiting and retaining them is your first priority, then it follows that it would be really easy to grow your contributors.

The ratio of women in IT is about 17-25% (depending on the study), but the ratio of women in open source are 0.1-5%. For me that means: we have spare talent that isn’t participating in our projects that could help with all of the above.

Sadly, we don’t have good numbers (as far as I know, if you have them, please send them along!) for other groups of people who are underrepresented in technology and open source specifically, including, but not limited to, people of colour, LGBTQI+ people, people with disabilities, people who do private care work (for children or elderly family members), or people of lower economic status. All of this section equally applies to all of these groups and I’m just taking women as an example because we have the numbers there. Rest assured, the numbers are worse than they are for women in open source, so we have some work ahead of us.

The summary here for why this disparity exists is that most people in open source are young white guys from a upper-middle-class (in the EU sense) and above, like myself. We all have the privileges that allow us to spend our spare time, or even paid time, on open source projects, but as is evident by the numbers, that privilege doesn’t extend to your average single mother of two, or person of colour who couldn’t land a job in IT, despite the qualification.

One way out of this would be a way for people to get paid to work on open source projects, and especially those people who are underrepresented in tech, because their time needs to be paid for. But this also includes the dedicated individuals who were privileged enough to have enough time to work on an open source project that is now so popular that it demands so much of their time that they can’t do it in their spare time sustainably.

Unfortunately, I have no guidelines for this. Financing open source is an open topic and people have far-reaching opinions from wanting to keep money out of open source at all cost (rimshot) or not, and people who are already raising money for tech projects by marginalised people.

However, this is not a mainstream discussion yet, although smaller initiatives exist, even after the Heartbleed disaster. Even though OpenSSL is comfortably funded now, this was a purely reactionary initiative (that worked well, no qualms about that), but we have no strategy about how to address this and it’s about time that we started having this discussion.

So much of our work and infrastructure depends on Open Source, and it’s time we took the people doing this work as seriously as as the highly financed startups and corporations that depend on of all this freely available work.

Let’s make open source sustainable!

Why Technology Hype is a Good Thing

2015-07-16T00:00:00+02:00

Hype for technologies is usually seen as a bad thing™.

While I don’t want to deny that there are downsides to this, I also see an upside.

tl;dr: Don’t consider a hype an annoying fashion, but rather a massively distributed mechanism for more quickly figuring out value.

Hype gets a technology and the ideas behind it exposure with a lot of people. Not all ideas are going to be good, and the more people take a good look at one, the earlier we will find out what is good and what isn’t.

History is full of this: XML started out as a document structuring format. But soon after it became popular, people started using it for everything, including computer to computer communication (SOAP, WS-*).

And that was very very very popular. Until we collectively realised that we’ve taken things a little too far. XML is a fine format for the things it was designed to do, but it is not a good generic data protocol format.

Some of the good ideas of XML survive though: Validation is still useful, but it is more optional in the JSON world we live today. There are enough cases where validation is not needed, or would be a prohibitive barrier to entry. We know that now. So we made it opt-in.

Another thing I see hyped these days (for a while now, actually) is Docker. I don’t have too much experience with it, but it appears that people are starting to do everything with Docker. And I’m excited about this. Not because I believe Docker is the end to all means, but because we will collectively find out more quickly what the good and not so good ideas behind Docker are.

The more popular something gets, the more critics it attracts. And in the view of the discourse of community learning and understanding, that’s a good thing. Criticism that has merit will spread, and we will all learn what the good ideas are.

In the JavaScript world, React is all the rage. At JSConf EU, we got a lot of proposals for React-ish talks, which is just another way of saying, people are doing everything with React.

We don’t know yet, what the good ideas behind React are going to be, so we have to have a little patience before things will shake out. But they will.

To hype!

Engaging With Hateful People in Your Community Lends Legitimacy to Their Presence

2014-11-21T00:00:00+01:00

A woman friend who stays anonymous privately tweeted this discussion earlier. I believe anyone involved with Open Source communities should read and understand this. This is published with her consent.

People, and men in particular, let’s talk about how we deal with people from hate movements showing up in our repos.

OK so for everyone’s context, screencaps of a Gamergater commenting on a Node repo. We need to talk about this.

And to be clear, I’m not shaming @mikeal or @izs (you’re awesome). IMO there’s something broken in our response when male supremacists …

… show up, and men who clearly care about inclusiveness are getting this wrong. So I simply hope my tweets will add useful perspective.

For you men the screencapped exchange might read as
(1) horrible male supremacist argues
(2) rebuttal by @mikeal & @izs
Nothing wrong with (2)

So you might be surprised that to me it reads very different:

(1) male supremacist person shows up - clearly a safety issue
(2) people in the community are actually engaging with this person :(

Note the difference: As a man you might have read the arguments. I literally stopped at the usernames.

(Aside: If the “gr.amergr.ater” username somehow doesn’t spell “misogynistic hate mob” to you, please go read up on this.

This isn’t random internet drama; other people’s safety depends on you understanding this stuff.)

So why do you men get to care about the bigoted arguments and even engage & rebut? Because you’re unlikely to be targeted.

They read as “abhorrent” to you, but not as “threat to your safety”. Good for you!

But for me, the presence of this person is a problem.

When I see a male supremacist show up in an online space, the likelihood that I will participate drops to zero.

Because as much as I care about participating in you all’s projects, no open source project is worth compromising my safety over.

You can have a male supremacist in your online space. You can have me. But you can’t have both.

It’s probably not unreasonable to extrapolate that other women are similarly put off by the presence of male supremacists.

So when you decide to engage & rebut hateful arguments, this comes at the expense of excluding women and minorities from the online space.

Okay, part 2: What’s the right way to deal with male supremacists and similar hate groups showing up?

I don’t have a clear answer. What I care most about is that community members are protected.

Here’s my suggestion #1: Don’t engage. It’s better to instantly block that person from the repo and delete their comments.

GitHub’s combination of “everyone can read”, “everyone can comment”, and “weak moderation features” can make it hard to ban effectively.

Hence suggestion #2: Take discussions (sensitive ones especially) off GitHub completely, to more private, better-moderated spaces.

GitHub’s weaknesses make it not very safe for women and minorities, so if you want those voices heard, avoid the GitHub issue tracker.

By the way: Similar things apply when male supremacists send you reasonable-looking pull requests.

I noticed that this gr.amergr.ate person had sent a small PR to a [my-project] plugin, and the plugin maintainer merged it.

This made me super uncomfortable, and I hope I don’t have to interact with that maintainer, because I really don’t trust their judgment.

When you get a PR from an author whose very name spells hate, then even if the diff looks reasonable, don’t merge it.

Reject it, or ignore it until becomes obsolete. Or even reimplement the fix yourself. Just don’t merge. Let’s not have hate in git log.

The Innovator in Hindsight

2014-04-20T00:00:00+02:00

In where Clayton Christiensen predicts that Linux on the Desktop will never come and that it will fuel the mobile revolution. In 2004.

Including an introduction to the Innovator’s Dilemma and Solution, and how this quares against Open Source.

http://web.archive.org/web/20130729212828id_/http://itc.conversationsnetwork.org/shows/detail135.html

The State of CouchDB 2013

2013-12-20T00:00:00+01:00

This is a rough transcript of the CouchDB Conf, Vancouver Keynote.

Welcome

Good morning everyone. I thank you all for coming on this fine day in Vancouver. I’m very happy to be here. My name is Jan Lehnardt and I am the Vice President of Apache CouchDB at the Apache Software Foundation, but that’s just a fancy title that means I have to do a bunch of extra work behind the scenes. I’m also a core contributor to Apache CouchDB and I am the longest active committer to the project at this point.

I started helping out with CouchDB in 2006 and that feels like a lifetime ago. We’ve come a long way, we’ve shaped the database industry in a big way, we went though a phoenix from the ashes time and came out still inspiring future generations of developers to do great things.

So it is with great honour that I get to be here on stage before you to take a look at the state of CouchDB.

Numbers

I’d like to start with some numbers:

In 2013 we added 15 committers to the project, up to a total of 30. Thats 2x the number of people regularly contributing to CouchDB!
The year isn’t yet over, but these committers already created 3x the commits of 2012. And they have committed more than in any other year in CouchDB’s history.

We have shipped eight releases: 1.0.4 1.1.2, 1.2.1, 1.2.2, 1.3.0, 1.3.1, 1,4.0 and 1.5.0 just this year, that is up from one(!) last year.
- thanks to our new release schedule we are getting more features to more people faster by focusing on small iterative changes forward.
20% more JIRA tickets and 50% more GitHub issues

We have made a lot of changes in 2012 to make 2013 a great year for CouchDB and it sure looks like we succeeded and that 2014 is only going to trump that.

I’d like to thank everyone on the team for their hard work.

Currently

We’ve just shipped CouchDB 1.5.0 last week and it comes with a few exciting new things as previews, for you to try out and play with and report any issues with back to us. And that is on top of all the regular bug fixing and other improvements.

A completely new developed admin UI, nicknamed Fauxton, that is poised to replace the much-loved, but increasingly dated Futon. I’d like to personally thank the Fauxton team: Sue “Deathbear” Lockwood, Russell “Chewbranca” Branca, Garren Smith and many more volunteers for their work as well as the company Cloudant for sponsoring a good chunk of that work. Great job everyone! Fauxton is going to be replacing Futon in one of the next few releases and will give us the foundation for the next stage of CouchDB’s life.
Plugins. While it was always possible to write plugins for CouchDB, you kind of had to be an expert in CouchDB to get started. We believe that writing plugins is a great gateway drug to getting more people to hack on CouchDB proper, so we made it simpler to build plugins and to install plugins into a running instance of CouchDB. It is still very early days, we don’t even have a plugin registry yet, but we are surely excited about the prospects of installing GeoCouch with a single click of a button in Futon or Fauxton. We also included a template plugin that you can easily extend and make your own, along with a guide to get you started.

The plugins effort also supports a larger trend we are starting to follow with the CouchDB core codebase: decide on a well-defined core set of functionality and delegate more esoteric things to a rich plugin system That means we no longer have to decline the inclusion of useful code like we’ve done in the past, because it wasn’t applicable to the majority of CouchDB users. Now we can support fringe features and plugins that are only useful to a few of our users, but who really need them.

A Node.JS query server. CouchDB relies on JavaScript for a number of core features and we want to continue to do so. In order to keep up with the rapid improvements made to the JavaScript ecosystem we have tentative plans to switch from a Spidermonkey-driven query server to a V8-driven one. In addition, the Node.js project has a really good installation story, something that we had trouble with in the past, and includes a few utilities that make it very easy for us to switch the query server over.

All this however is not to blindly follow the latest trends, but to encourage the community to take on the query server and introduce much needed improvements. The current view server is a tricky mix of JS, Erlang and C and we are not seeing many people daring to jump into that. In a second step we expect these improvements to trickle down to the other query server implementations like Python or PHP and make things better for everyone. For now this is also a developer preview and we are inviting all Node.js developers to join us and build a a better query server.

Docs landed in 1.4.0, but 1.5.0 is seeing a major update to the now built-in documentation system. With major thanks to Alexander Shorin, Dirkjan Ochtmann and Dave Cottlehuber who were instrumental in that effort, CouchDB now has “really good docs” instead of a “really crappy wiki”, that are shipped with every release and are integrated with Futon and Fauxton.

Beyond

The immediate next area of focus for the CouchDB project is the merging of two forks: BigCouch and rcouch.

BigCouch is a Dynamo implementation on top of CouchDB that manages a cluster of machines and makes them look as a single one, adding performance improvements and fault tolerance to a CouchDB installation. This is a major step in CouchDB’s evolution as it was designed for such a system from the start, but the core project never included a way to use and manage a cluster. Cloudant have donated their BigCouch codebase to the Apache project already and we are working on an integration.

rcouch is a what I would call a “future port” of CouchDB by longtime committer and contributor Benoit Chesneau. rcouch looks like CouchDB would, if we started fresh today with a modern architecture. Together with BigCouch’s improvements, this will thoroughly modernise CouchDB’s codebase to the latest state of the art of Erlang projects. rcouch also includes a good number of nifty features that make a great addition to CouchDB’s core feature set and some great plugins.

Finally, we’ve just started an effort to set up infrastructure and called for volunteers to translate the CouchDB documentation and admin interface into all major languages. Driven by Andy Wenk from Hamburg, we already have a handful of people signed up to help with translations for a number of different languages.

This is going to keep us busy for a bit and we are looking forward to ship some great releases with these features.

tl;dr

2013 was a phenomenal year for Apache CouchDB. 2014 is poised to be even greater, there are more people than ever pushing CouchDB forward and there is plenty of stuff to do and hopefully, we get to shape some more of the future of computing.

Thank you!

Understanding CouchDB Conflicts

2013-12-19T00:00:00+01:00

Heya Stranger! You probably came here to better understand CouchDB conflicts, and this post will help you to do so.

Should you need any more help with CouchDB, my company, Neighbourhoodie Software is offering world-class CouchDB support. Get in touch, now. :)

As part of a summary what Nodejitsu is planning to do with the scalenpm.org campaign money, they said:

All of these problems stem from the same symptom: conflicts in CouchDB. If you’re new to CouchDB you can read up on conflicts here. Conflicts are caused in the npm registry because (depending on several factors) a given publish can involve multiple writes to the same document. When these writes do not hit the same CouchDB server conflicts are generated. There are other medium-term solutions to scaling writes (such as sticky HTTP sessions), but conflicts will inevitably arise so we must address the symptom as well as the cause.

Of course CouchDB has a concept of conflicts, they are core to what makes CouchDB great: master-less peer to peer replication of your data. But I feel they are misrepresented here, so I’ll try and clarify things a little.

We will find out that the symptom isn’t CouchDB’s conflicts feature, but how the npm client treats CouchDB document updates in a way that is not recommended (note that I’m not trying to point any fingers here, I just hope people can learn from this :).

How to store data in CouchDB

The standard way to store data in CouchDB is to HTTP PUT a JSON object into a CouchDB database:

PUT /database/document
{"a":1}

When retrieving that document, it it will look like this:

GET /database/document
{"_id":"document","_rev":"1-23202479633c2b380f79507a776743d5","a":1}

CouchDB will automatically add two properties to our JSON object, an _id and a _rev. The _id represents whatever we named the document in the initial request (we can also let CouchDB assign a random _id) and the _rev, or “revision” represents an opaque hash value over the contents of a document.

To change the value of a document, we need to prove to CouchDB that we know what its latest revision is:

PUT /database/document
{"_id":"document","_rev":"1-23202479633c2b380f79507a776743d5","a":1, "b":2}

The next time we get the document it looks like this:

GET /database/document
{"_id":"document","_rev":"2-c5242a69558bf0c24dda59b585d1a52b","a":1, "b":2}

You see the revision updated. Now lets try to update the document again, but provide the old _rev:

PUT /database/document
{"_id":"document","_rev":"1-23202479633c2b380f79507a776743d5","a":1, "b":2, "c":3}

We get:

{"error":"conflict","reason":"Document update conflict."}

Understanding revisions

This way, CouchDB ensures that a client never accidentally overwrites any data it didn’t know about. Think about this like a wiki editing system: one person edits a wiki page and adds a few paragraphs of new information while another person just fixes a typo halfway through the first person writing their contribution. Without any cleverness, the first person will overwrite the second’s person typo fix when they save their version (or revision) of the wiki page. To ensure they don’t, each revision could be tagged with a _rev that the client then need to provide when writing back to the server. If they don’t match, the client needs to re-read the document and merge any other changes that might have happened in the meantime (the typo fix) and then try to save the wiki page again. In more technical terms, this is called “optimistic locking”. This is to avoid the scenario of “pessimistic locking” where the second person has to wait for the first person to make their changes before they can edit the wiki page.

CouchDB works the same way and for good reasons, but it can be counter-intuitive to how people are used to working with databases. Some users think their way out of this without really understanding why CouchDB works this way. When they encounter a document update conflict, they will make a GET or HEAD request to CouchDB to learn about the latest _rev of a document and then use that for a second write request without first regarding the new data that has appeared on the server. In some cases, this is a viable strategy, especially, if only a single database server is involved and changes to documents are restricted to one or very few users (like in npm).

Distributed systems and all that

Now the fun part is when we add more database servers. One way to set up CouchDB is to run multiple instances behind an HTTP load balancer (because that’s really easy to do) and set up bi-directional replication between the two databases. This helps with reliability and load distribution, as two servers can share the read-load and if specced correctly, a single server can survive the outage of the peer, while the load balancer ensures that users never see a difference.

A load balancer usually distributes reads and writes randomly between the two CouchDBs. This is where the fun begins. Let us update our document once more:

PUT /database/document
{"_id":"document","_rev":"2-c5242a69558bf0c24dda59b585d1a52b","a":1, "b":2, "d":4}

Now this gets written to CouchDB A because the load balancer decides so. CouchDB A now has:

GET /database/document
{"_id":"document","_rev":"3-2235fd4815b81b2da1b84159aba4006e", "a":1, "b":2, "d":4}

But CouchDB B still has:

GET /database/document
{"_id":"document","_rev":"2-c5242a69558bf0c24dda59b585d1a52b","a":1, "b":2}

Usually replication updates this quickly, but it might take a while due to write load, and if the client sends multiple requests in quick succession, there is a fair chance that updating the document yet another time will hit CouchDB B which will reject the write, because the _rev doesn’t match any more:

PUT /database/document
{"_id":"document","_rev":"3-2235fd4815b81b2da1b84159aba4006e", "a":1, "b":2, "e":5}

Returns:

{"error":"conflict","reason":"Document update conflict."}

If we use the strategy of quickly getting the _rev from the doc and trying again, we might GET from CouchDB B again, to get "_rev": "2-c5242a69558bf0c24dda59b585d1a52b" and attempt the write again:

PUT /database/document
{"_id":"document","_rev":"3-c5242a69558bf0c24dda59b585d1a52b", "a":1, "b":2, "e":5}

If this PUT also goes to CouchDB B (you see this scenario is getting less and less likely, but it is still possible and certainly expected in a system like npm’s), this write will succeed and now we two conflicting revisions on CouchDB A and CouchDB B:

CouchDB A: 3-c5242a69558bf0c24dda59b585d1a52b
CouchDB B: 4-8b6ea819bf3384b2c215fd05fc5a1e5a

When CouchDB replication now runs, it will introduce a conflict on both CouchDB’s, as it is expected to. But since this is an undesirable situation, CouchDB generally recommends against using this strategy to deal with document update conflicts.

Solving the riddle

There are multiple ways to fix this:

When making a change, don’t require multiple GETs and POSTs. It is my understanding that the npm developers are working on that (Run npm install -g npm to make use of this without waiting for the next node release, thanks @izs).
Don’t update the _rev locally in the client without also merging any new data from the server. I hope the npm developers are also taking this into account.
Sticky sessions: most HTTP load balancers can be configured to send subsequent requests from the same client to the same backend server. This is generally not desirable because it limits scalability and fault tolerance, but it is a worthwhile stop-gap, if not default setup, if applicable to the app. I can’t comment on whether this is applicable to npm or not.

I hope I could shed a bit of light on a thing that we, the CouchDB developers, have thought about a lot in the design of CouchDB, but have obviously failed to communicate sufficiently in the earlier days of CouchDB.

Let me close with saying the Team CouchDB is proud to support npm and the node community! <3

The Parable of Mustache.js

2013-11-01T00:00:00+01:00

In October 2009 Defunkt released mustache.rb. It looked useful to me at the time, but I needed it in JavaScript. The code was just under 200 lines and simple enough that I thought I could port it over on a lazy Sunday, or Saturday, I forget.

So I did, and to this day, I believe my biggest contribution to mustache.js was not all the fancy stuff that happened since, but the initial transliteration of Ruby to JavaScript. Yes, transliteration, Ruby and JavaScript are close enough that I did a more or less line by line port of the original code. I can’t claim I did any programming myself there.

If you look at the early versions of both projects, they look remarkably similar

mustache.rb was a huge hit in Ruby land right away and soon after I did my port a number of very smart people came around and rewrote the existing RegEx based “parser” (eugh) into a proper parser and compiler combination to make sure all proper computer science theory is applied and things run most efficient.

I looked back at the code then and couldn’t find my way around, things were split over dozens of files and I am sure it all made sense to a very organised brain, but I couldn’t even begin to start to understand what the whole thing did. And I remember distinctly that I was happy that I found mustache.rb in the before state so that I had a chance to port it. I would never have begun to try if I had found the “more optimal” solution.

The realisation there though made me also a bit sad. I am all for doing the right thing and executing things faster and everything, but it bugged me that the clarity of the code was all gone now.

Then other smart people came and wanted to do the same for mustache.js and I was hesitant. But instead of trying to argue with clarity, because fuck that if we can make it 10x faster, my argument was that these parsers & compilers are way too long for a JavaScript implementation that was targeted at the browser. My tagline was “by the time your compiler is finally done downloading, my RegEx parser has already produced a result”. It was of course a bit of a cop-out, but I got quite far with it.

Until Nate showed up and wrote a parser/compiler in ~350 lines of code (that was roughly the acceptable limit for me then) and I finally lost that argument too. But it took a while until mustache.js finally got its well needed superpowers, with huge help from Michael.

Meanwhile, I met Yehuda Katz at a conference and someone introduced me as “Jan, he does CouchDB and mustache.js” and Yehuda just said “Oh boy, I’m going to upset you soon.” and then avoided me for the rest of the conference (or it was just coincidence, I don’t know :). A week later he released handlebars.js, a mustache.js-inspired templating engine with some extra features that were really useful. But it wasn’t according to spec, just close enough, that a lot of people started using it. I thought “good for them”, but I secretly (or not so secretly) wanted to steal the best ideas and get people to use mustache.js instead. That didn’t really go anywhere because people stopped working on the spec in a sensible manner and we couldn’t agree on more features. And eventually, I spent more time with CouchDB again.

In the meantime many more mustache implementations in other languages appeared and one implicit design goal between was it to allow sharing of templates between them and produce compatible output. There is even a spec.

Around the same time Twitter started using mustache.js in the frontend and it was a great honour. But they too preferred a proper parser/compiler implementation so @fat & team went ahead and wrote Hogan, a mustache.js-compatible implementation with a faster load and runtime. @fat talked about this at his 2012 JSConf US talk, he got asked why he didn’t submit a pull request to mustache.js instead of making a new project. He said that a Pull Request that consists of “Hey, I threw away all your code and replaced it with mine” isn’t such a good idea. I agree, it wouldn’t have left the best impression.

He praised though, that they were able to build a compatible implementation that could compete on its own merits while still being compatible with a spec and he said that all library development should be done that way. Too often we conflate a great idea with its implementation and we would be better of allowing different ones and let users pick and choose their poison.

While watching @fat speak, it dawned on me that if I look at things this way, then the RegEx implementation of mustache.js is just another implementation of the same spec and its merits are tight and accessible code. And I could have hugged him for it. In fact I ran up on stage during the talk and nearly ran him over (22m:15s). My beloved implementation still had a reason to exist and that made me very happy. Until today, the 0.4 branch of mustache.js is still around.

Lessons Learned:

Accessible code has merit over optimised code, even if the optimised code should be used most of the time.

Build libraries with a spec, encourage competing implementations. (We plan to do this for Hoodie)

Hugs win.

The state of mustache today is alright, the implementations are all reasonably mature projects and people just use them. But there are a few that want to move it forward but are hindered by the complacency of the early adopters who have moved on to other things (including me). I hope we can get that resolved eventually.

On that note, mustache.js has a number of interesting Pull Requests and issues open and if anyone is interested in taking over maintainership, please make yourself heard in on the GitHub project.

Let’s Start a Revolution

2013-08-16T00:00:00+02:00

I will not die for you
I will not kill for you
I will not fight for you
I will hold your burning flag in my hand

— Coup d’etat by Refused

History is filled with two types of people: the ones that want to maintain a comfortable status quo and the ones that want to move humanity forward.

The maintainers of the status quo tend to be the ones on top of the food chain. The ones that want to bring humanity forward are usually the ones who are questioning the laws, the mechanics, the inner workings of whatever is going on at that time.

Over the centuries the ruling classes set up schemes to structurally keep everybody else out. Over the same centuries though, they had to cede step for step that more and more people could benefit from the privilege of an upper class.

There is this phrase “on the wrong side of history”. We use it when we look at societal issues that are discussed at a certain point, today, or in the past. Democracy, slavery, racism. A contentious issue will always have people arguing either side, and over time we see who got it right. The others are on the wrong side of history.

Giving the same opportunities (at least on paper) to women is a novel concept as of as little as 100 years ago and is still not evenly spread around this planet, especially in the western world.

The USA have built a whole country around that idea that you can work your way up from the lower classes to power, fame and wealth. Under the hood, however, you see the same structural oppression of the lower classes that you can trace through the middle-ages, Rome, Athens and ancient Egypt.

For the most part, I think it is obvious what history tends to align with: making things better for a large group of people at the expense of a few privileged ones.

Let’s Talk About Money

Money is what enables business, enables society, and thus enables progress.

People who manage money should never be the ones making final decisions or define culture, work or otherwise. However, today, they dominate education, culture and business. And we all suffer for it.

The focus on money today is obscene. Just look at some of the language around it: “money works”, bullshit, money does nothing but representing a value, people work.

People get compared by what they are “worth” as if merely having money has any meaning. Only if you do something good with your money, you are an asset to society, are worth something.

We allow current generations to be exploited for short-term capital gains, while feeding the next generation the same ideals and thus manifest this whole travesty into our culture for generations to come.

Over the past few decades though, we have forgotten that, because it enables things, money is a utility, and yet we treat it as means in itself.

We need to get back to understanding that money is a tool and that people who manage money are enablers for the ones who push for progress.

This is our Time

A few weeks back Dennis Plauk was on German TV. You have likely never heard of him and likely never will again, but his appearance made a distinct impact on me.

He was on a national TV news show, giving his expert opinion as the editor in chief of a music magazine.

More importantly though, THAT DUDE WENT TO MY HIGH SCHOOL. He was a year ahead of me, and from the fifteen hundred people that went to that high school, he was one of the very few that made an impression that lasts until today.

Seeing him on TV solidified a feeling that I had for a while. My generation, I was born in 1982, is gearing up to be the generation that runs this world. We are gradually being passed the baton of history to carry it all forward to make a mark. If we so choose.

If you’d ask me to characterise my generation in one word I’d choose apathy. I see early 20s today that have a much keener sense of making their mark in world than my generation ever had.

This is our time. Let’s make our mark.

My industry is high-tech, software to be precise.

My job is to take ideas that are of certain value to certain people and tell computers how to provide that value.

With “job” in the getting-paid-for-it sense, I get to do what alchemists have failed at for millennia: making Gold. Making Gold out of thin air (and coffee).

On top of performing alchemy on a daily basis, the people in my profession get treated like unicorns. We get to choose what we work on, when to work on it, for how long to work on it, where to work on it. And if we bloody please so, we take a week off and hang out in Dublin and speak at a conference along with and in front of like-minded unicorns.

In order to do our job, or taking a step back, in order to live, we rely on a modern society built on people who “do their job”, whichever that one is. On any given day, we rely on people who maintain the civic infrastructure, water, power, waste, provide us with ways to purchase food in various forms, people who clean our homes, offices and gardens, people who cut our hair, who drive us around town and many many more that we don’t even see or interact with.

I don’t suggest that these people can’t or won’t find pride, honour and fulfilment in their work, but they sure have to live with a lot fewer every-day liberties than the lucky bunch that is us technologists.

We are privileged. Privilege is when you don’t see a major problem with the world around you. When you don’t understand why someone or even a large group of people would be angry, after all, they all grew up here, they could just have done the same things that you did and they’d be fine.

Privilege is not something I was particular aware of growing up. That’s usual for people who grow up privileged. Sure, there were things I wasn’t particularly satisfied with, but looking back, my parents had steady jobs, I went to an o-kay school, we went to France for our summer vacation, in one of the two cars we had.

Understanding privilege was, for me, a very grown-up thing to do (yes, I still use “grown-up” in the sense that I don’t think I really am one).

My first reaction when it dawned on me that I did have a sort of privilege was shame, I was better off than others through no fault of theirs or feat of my own. That was a bitter realisation to make. In fact, it made me not think about privilege too much, which is yet another privileged thing to do (but I wouldn’t learn this until later).

I finally came to terms with my position when I understood that privilege is not inherently a bad thing (and if you tell me it is, fuck you for shattering my self-view). While it is very easy to exploit privilege, by simply doing nothing, or actively building upon your advantage to further it to the disadvantage of others. But, and here is where things turned around for me, you can use privilege for good.

Now, as a unicorn alchemist and accepting my privileged position in society, I understood that I do not only have the ability to use my privilege for good, but that I have a social responsibility to do so.

And given all the liberties we are given through our privilege, we don’t only have a responsibility of turning our powers into good, we have an exceptional opportunity to make this world a better place.

How to Revolt

If we are looking at the ingredients for a revolution, we are half way there. We have the motivation, the opportunity and the timing. Let’s find out how to revolt.

An entrepreneur’s job is to find out how to create and extract value from current historic, societal and economic circumstances.

At its core business is a-moral. Money changing hands for goods and services does not care who made what under which conditions.

Yet, business gets to define so much of our culture. Our life revolves around working five days a week, working 40+ hours, working to maximise shareholder value.

There is plenty of scientific evidence that this status quo actively harms people, physically and psychologically, and as a consequence, holds back society. People get sick from too much work and stress, costing the healthcare systems more money than they can handle and people are no longer capable or able to do any good.

Business at large, “capitalism”, is a fantastic tool to achieve great progress at scale, but business for business sake, or profit for profit’s sake can never be a cultural goal, only a side-effect.

Yet, as it has always been in history, the people in charge, the privileged ones, keep this up for their own benefit.

We live in a culture that teaches everyone that you need a job to be happy, to be a useful part in society, to work hard to be someone.

The way this work “un-ethic” is engrained into our culture is deeply vicious. Through media and entertainment the people who are interested in keeping this status quo pay artists, filmmakers, TV producers, actors, musicians etc. vast amounts of money to keep retelling this story, a story a young person born into this world has little chance of escaping.

We need to prop up a counter-notion: the idea that the working-hard story is just that, a story told by people who benefit from you working hard.

We need to let life define work, not the other way around.

Revolting Daily: An Experiment

I don’t have a tried and trusted system, but I’ve started to experiment. Feel free to follow my ideas, or build upon them or experiment with your own ideas, and tell us all about it. Here is what I am doing:

Optimise for happiness. Nothing that is supposed to bring society forward is worth doing if it makes people miserable.
De-emphasise “work” as the defining constant in life. “Life” is the defining constant in life. We should be able to turn enough profit to support life and growth on working two days a week. Encourage that the rest of the time is spent volunteering, teaching kids to code, work at a charity, or just enjoy life with friends and family.
Get the money-people out of the decision line. Make them advisors, make your CEO the Chief Happiness Officer, or even better, turn the leadership of the company over to a non-profit that is bound by ethical statutes that will always override short-sighted monetary decisions.

This is a good start, let’s get that going and then address the next steps:

Figure out how to make all this available to less unicorn-heavy sectors. Run society that way, not just high tech.
Figure out the balance between being able to create a sustainable, moral, business and being on the right side of history.
Spread the word, inspire others to follow your lead. Learn from other’s successes and mistakes. Find giants to stand on.

Let’s go!

There are about five billion years in this solar system in front and behind our lives. This is our one shot. And we can make a difference.

We have an exceptional opportunity to make this world a better place.

We are in a perfect position to lead change.

Now is the perfect time to start leading that change.

The culture of business today is on the wrong side of history.

Let us change that.

Let us start a revolution.

This essay was created from the notes for my opening talk for the 2013 edition of brio. My thanks to Lena Reinhard for her invaluable editing help.

How To Give the Killer Tech Talk — A Pamphlet

2013-05-10T00:00:00+02:00

Here’s my battle tested recipe for giving amazing technical presentations.

Prelude

Have a Topic / Know Your Topic / Know Your Audience

This recipe assumes that you have something interesting to talk about. It assumes you know your topic, the better the better, but you don’t have to be an expert. Especially, don’t sweat that there might be someone in the audience that knows more. Don’t be afraid to say “I don’t know” to questions, deferring it to looking up the answer.

You are on stage, this is your show.

Performance > Content

Again, you should know your stuff, but more important than stating what you know is how you state what you know. A presentation in front of an audience is 90% performance and 10% content, or 80/20, doesn’t matter really.

You don’t have to be a great entertainer, but people look up to confidence, be bold. If you are not usually bold, assume a stage persona that isn’t actually the frightened you. Put on a masquerade, a show for the masses. It is totally okay for you to be frightened, but the audience need to never know.

And never forget, even the most professional speakers, musicians, anyone on a stage, is frightened and nervous before the gig.

With that out of the way, here’s my recipe for giving kick-ass technical presentations, based on my experience giving and seeing many good and many more bad technical presentations. My thanks to all the speakers that I could learn from and to anyone who has ever given me constructive feedback.

The Recipe

0. Hello

Say hi, introduce yourself, give a bit of a background, say thanks for being let on stage. Build empathy. I am one of you, we share the same problems/goals/values etc. We understand each other.

2 minutes.

1. Scope

WHOA.

Grab your audience’s interest. Make them listen, ask intriguing questions, or make some outlandish statements that you come back to later for clarification. Build enough suspension to keep your audience’s attention.

Manage expectations Here’s what’s going to happen, and this is why it’s relevant to you.

3 minutes.

2. Show & Tell

BOOM.

Blow the audience away. Answer the questions you asked before, back up the outlandish claims you had. Sing, dance, do whatever it takes to get your audience to drop their jaws, two, three times.

If you show off some software, parade it around, try a live demo, or point out important snippets and results. If a demo is hard, pre-record and talk over a video.

Start with your strongest point first.

Make weaker points more relevant by binding them to the previous point or using them as a segue to the next one.

Have a narrative that carries you through your talking points.

End on something concise your audience can tweet.

10 minutes.

3. Details

Yadda, Yadda.

Here is where you get to explain the magic. You get to dive into technical details, you get to explain the design philosophy behind your topic. This is where you win your audience’s hearts.

10 minutes.

4. Thanks

Say thank you. Take a breath, you are done.

5. Q&A

Huh?

The Q&A serves multiple purposes:

it gives you feedback on how well the talk went / how relevant the topic was to your audience. The more and the harder the questions, the better.
it gives you feedback on what to do better next time. Maybe there is a point you forgot to make, a connection that you didn’t walk the audience through, maybe there is a technical aspect that many are interested in.
it gives you an opportunity to do a deep-dive into a topic that you only mentioned briefly, or not at all, before.

5 minutes.

Bonus Material

Know the rules, then break them.

Words Considered Harmful

2013-03-28T00:00:00+01:00

I’ve heard before: What’s the harm? Why not at least try to include ‘Hey there!’ if every little bit helps? Somewhat of a fair point. Using a word does no harm in the same way a daisy does no harm to your front lawn, or a shade of grey does no harm to your shadow.

Here’s where I’ll join the rest in unquantifiable hoodoo: I believe words are aesthetically damaging. I believe a white space free of words is more pleasing to the eye, more easily consumed, and thus more likely to be retweeted (which is a proven way of growing your audience).

Hear, hear.

Node Dublin — Open Source Communities

2013-02-12T00:00:00+01:00

These are my notes from my Node Dublin talk about “Open Source Communities”. I don’t think I did the title justice in the end, but I’ll keep it for consistency’s sake. The video shows that I was fairly nervous giving the talk and I wasn’t quite happy with the sound engeneer and my snouting into the mic while breathing. For those of you who can’t stand to watch, here are the notes.

Welcome

I am Jan Lehnardt: @janl, Apache CouchDB, mustache.js, JSConf EU.

Open Source Communities

I was gonna look at Node through the lens of other Open Source communities I had been involved in and conclude that by avoiding most of the mistakes it became the most exciting community of all time.

Lukily Isaacs and Mikeal made a way better case for why Node is successful, and why the key success is not yet manifsting itself in dominating anything, but setting us on a trajectory to disrupt all of IT (and if you believe Clay Shirkey— and you should — disrupt society & politics).

To reiterate, Node’s core accomplishments are:

No language war. JavaScript is good enough.

Small Core.
Clear Module Abstraction.
Non-Leadership.
NPM (I add).

And finally, Node’s whole premise is to be good at building networked servers.

Not be an immersive development environment, like .NET, Java, Cocoa, or frameworks like Rails, Django & the like.

It turns out that the concept of a neworked server is a really good abstraction for building all sorts of software.

So by trying hard to avoid being everybody’s darling, Node focussed on one thing and perfected that thing that makes it everybody’s darling.

(My dayjob is working on Apache CouchDB. It is written in Erlang.

The whole programming paradigm of Erlang revolves around building miniature networked servers that do one simple job for robustness and fault tolerance, easy of reasoning and finally parallel execution, and to put them together in a way that creates bigger software, not just servers.

Many other components of desktop and mobile software can be expressed as being a networked server.

Heck, even the original definition of OOP is independent entities that hold data and have behaviours attached that would send messages to each other to invoke that behaviour.)

World Domination

With the keynotes yesterday morning and after looking at all the fantastic technical talks we saw over the past two days I hope you get a sense not only for how succesful Node is, but also why, and why that is even more important than the current success.

Taking a step back.

We can now build entire systems in pure JavaScript, frontend and backend and this is significant.

We can also control flying quad-copters and robots and power moblie experiences.

We are bridging all fields of computer science from the hardware up to fancy 3D rendering. All in JavaScript.

And all of it is becoming good enough, in the same sense that JavaScript is good enough to be the language of Node, to go out and build everything.

This is where this talk becomes emotional.

We, the people in this room, the ones at the other Node conferences, the JavaScript conferences and the frontend conferences and the people out in the field, we are going to be building the next genration of software, infrastructure, products, everything.

We will be powering the ongoing digitalisation and networkification of the world, of commerce, of governments.

Not the enterprise Java folks, not the PHP people, not Rails. Us.

That isn’t to say the others won’t have their place, but we’ll have lion’s share of things to do.

To invoke Clay Shirky one more time: they are from a time before GitHub.

Taking another step back, a couple in fact.

We, the programmers, the designers of the world, we have an incedible gift.

A gift that nobody else has, and many have tried to gain for millennia: We can create gold out of thin air (or, maybe out of thick coffee).

A show of hands, who here in this room considers to be in her or his dream job? We get to dictate the conditions of our employment.

We dictate salary, we dictate working hours and we dictate what we want to work on. Nobody else has that freedom.

Yet, we are relying on a society that “does their job”.

Many of the speakers here have come from far away to share their thoughts with us and to hang out, to have fun.

We came by plane, rode in cabs, staying in hotels, or friend’s houses.

We enjoy coffee and lunch here and in the city, use public transport.

We build upon education, rely on medical service.

All of it built & run by people who do their job, that do not get to dictate salary, working ours or what to they fancy to work on.

We live such abstracted lives that we can concentrate on creating immense value from literally and figratively nothing.

On top of that we get paid ridiculous amounts of money (absolutely and in comparison) to do so.

It is absolutely fabulous, and I love every minute of it. It is an immense privilege that I get to live this life. A life I choose.

But reflecting leaves me with a sense of responsibility towards my fellow people.

Those who don’t get to burn through billions of venture capital money to play table tennis all day.

Not the ones that actually manage to return an investment and make the obscenely rich people even richer.

At the expense of innovation, at the expense of personal freedom, prosperity, security.

Jeff Hammerbacher said: “The best minds of my generation are thinking about how to make people click ads, that sucks.”

I agree and I feel responsible to build a future, technologically and socially that values humanity over profit.

I hope you feel that responsibility as well.

(We Are) The Future

Given the premise that we, the people in this room, are on the verge of setting the stage for the world, what can we do to make sure our reign will be rememberd as a good one?

And given that we accept that through the way things are set up today, that we are in an incredibily privileged position that comes with a social responsibility, what should we do with it?

I’m not here to try to plaster my own agenda over you. Instead, I’m sharing a few points of view to encourage you to actively think about your own.

Take Mozilla.

Where a non-profit organisation owns a for-profit company.

The non-profit keeps to set the goals for the company, while the company uses capitalism, markets & money as a tool to build stuff that benefits everybody.

Firefox, Persona (née BrowserID), Do Not Track. All build expressly against finanical benefits of one single institution.

Why don’t we have more organisations like this?

Nerds imagined and built Mozilla.

We can do, too.

Imageine a mobile carrier, that is set up like Mozilla.

Globally run, with the user in mind, engaging the community for support.

Imagine sane data-plans, free roaming between GSM technologies and community provided wifi.

Net access for everyone, cheaply, not bullshit telcos that just screw over everyone, when their job is administrating a public resource.

Let’s build a mobile carrier like this. You and me, let’s do this.

Better yet, let’s encourage others to do this as well, let’s build ten, or a hundred.

Let’s take this idea and apply it to many many more areas of life.

Or, in Mikeal’s footsteps, defy organisations, just build stuff in losely coupled communities that circumvents and dominates all the current institutions who are set up to exploit, rather than support us.

Let’s hack and fork business models and community patters as freely as we do code.

Let’s work on problems that matter.

Let’s work at a scale that makes an impact.

We are all JavaScript People.

The future is ours.

Thank you.

The State of CouchDB

2013-02-01T00:00:00+01:00

Get Professional CouchDB Support Now

Slides to go with the headings.

Hi, welcome to CouchDB Conf.

CouchDB means a lot to me and it makes me very happy that you are all here today.

Who am I

My name is Jan Lehnardt and I am the elected project management committee chair of the Apache CouchDB project. If you don’t know what this means, don’t worry, it means I sign up to deal with politics and paperwork voluntarily.

I have been with CouchDB since 2006. My first contribution was the initial UNIX build system to CouchDB. I stuck around ever since.

My main job back then was PHP/MySQL consulting and Open Source work as my own 20% project. In 2007, I started giving talks about CouchDB at user groups and conferences and quickly became addicted. People called me the CouchDB Chief Evangelist, although I don’t really like the title. From 2008 I started getting contracting jobs specifically for CouchDB and things blew up quickly that it became clear soon, that an organisation of some sort was needed to handle this. I eventually joined forces with CouchDB’s original inventor and J Chris Anderson to form the company Couch.io. We initially weren’t keen on taking venture capital, but when the whole NoSQL thing blew up, it was very hard to say no and on January 1st 2010 we were in business.

Couch.io turned into CouchOne and was eventually merged with Membase into Couchbase. Unfortunately, at this point, there isn’t much Couch-y about Couchbase aside from some underlying technology, so the name can be confusing.

I parted ways with Couchbase a week ago in order to concentrate and focus more on Apache CouchDB and related technologies.

CouchDB isn’t Dead

In late 2011 two major supporters of CouchDB withdrew their support: Canonical’s UbuntuOne service, on paper a poster-child use-case for CouchDB and Saucelab’s Selenium platform publicly made clear that they were moving to other technology. It wasn’t a big deal if you looked closely, the one project didn’t have enough resources to integrate with CouchDB the right way and the other diverged so far from the original system design, that CouchDB was no longer a good fit. We were and we remain good friends with the respective developers, so we didn’t feel like pointing that out specifically. The result though was that people who didn’t look closely saw that CouchDB had popular failures where it hadn’t. This wasn’t all bad, but set the stage for another incident a few weeks later.

CouchDB’s original inventor publicly announced that he’d move on from Apache CouchDB to Couchbase fully. That new technology would only go into Couchbase. If you are in the know, this wasn’t a big deal again, he hadn’t contributed to CouchDB in two years, Couchbase was a different thing and he wanted to rally support for that. The casual reader though took away one lesson: “CouchDB is dead”.

With the added confusion of Couchbase’s name, and continuing their CouchConf conferences, things looks dire.

CouchDB 2012

With this in the wild, the active CouchDB committers got together and put out an excellent 1.2.0 release that was accompanied by a new, modern website design. We thought instead of writing counter-statements and start unnecessary he-said-she-said discussions, we’d rather concentrate on shipping good software. 1.2.0 was well received and the whole thing lead the team to come together as a whole in Boston and two weeks later in a smaller group in Dublin in April 2012.

We came up with a long list of of features that we wanted to get into CouchDB. Some work happened over the summer, but I personally took a bit of a break to avoid burn-out from CouchDB. In fall, things started moving faster again when more community members started pushing things along. New contributors came and we finally came up with a way to go forward.

We decided to not be insane. The definition of insanity is trying the same thing over and over again and expecting different results. While it wasn’t all bad in CouchDB land we could do better and to do better we had to change a few things.

CouchDB Reboot

We determined that CouchDB needs a fresh mission statement. I signed up to come up with a few drafts, but nothing happened yet, so this one is still out there cough.

We decided to release more often. With the upcoming 1.3.0 release we will switch to a quarterly release cycle. A new minor version will come out approximately every 90 days, even if it is just a few bug fixes that a small number of people direly need.

CouchDB 1.3.0 will ship with top-notch API documentation right inside of Futon, the built in admin interface.

We will start to set up teams where anyone can sign up to work on a specific thing: docs, our JavaScript components, the Erlang core, the admin interface (built in HTML+JS). We want to make sure anyone who has the right skills can contribute in their area of expertise and not be scared away by the Erlang.

We put some emphasis on QA, automated testing, building binaries and packages for releases as well as in-development versions, so people can try new features before they come out more easily and as a result report issues early.

A few of the core team will put some focus on encouraging contributions rather than coding themselves. We hope to get more people on board with CouchDB development.

We also started doing roughly quarterly in-person meetings (at least as smaller groups) and weekly status meetings on IRC to give everything a little more focus and transparency.

The next few slides show a long list a few features that we’ll be working on. If you think anything is missing, let us know!

The more prominent things are: Merging rcouch, BigCouch, the new Futon, the plugin system and v8/node integration.

rcouch is a cutting edge distribution of CouchDB with many experimental features. A lot of that work is useful for Apache CouchDB and we plan to fold those back into the project.

BigCouch is a industry-strength clustering solution for CouchDB to allow seamless scaling and storing of lots of data. BigCouch is going to be merged into mainline CouchDB as well.

The admin interface Futon is getting a complete refresh with modern web development technologies.

There are many features hidden in some developer’s git repository because, while useful, it wasn’t generally applicable to CouchDB. With the plugin system, we hope that we can fuel a repository of plugins to CouchDB that are easily installed (think browser extensions, right from Futon). For example, you could install GeoCouch with the click of a button.

Finally, we are currently discussing the move from SpiderMonkey and to V8 or even Node. The jury is still out on which one it is going to be, but we hope that this is going to open up a lot more opportunities for CouchDB in terms of features and new contributors.

Community

CouchDB would be nothing without you, the community. People who know little about CouchDB might like it or not, but people who really get to know CouchDB are extremely passionate about it.

CouchDB’s core idea, the promise that data can be anywhere it is needed, to make applications easier, more approachable and effective for people in modern computing environments, that idea is a big one. It’s the one that brings this community together.

Thanks again for coming, you are all awesome. CouchDB means a lot to me and I get a little teary seeing you all here.

If you like any of the above todos, or have some of your own, please help out, get in touch about how.

Friends of CouchDB

The CouchDB ecosystem is full of exciting projects that support CouchDB in one way or another.

PouchDB

PouchDB is the newest project on the scene. PouchDB is a pure JavaScript implementation of CouchDB targeted at the browser.

Let me say that again: CouchDB in JavaScript, for the browser.

PouchDB is the oldest idea, but it took the longest to realise because browsers weren’t ready for it. Now is the time though that we can build and ship a CouchDB compatible data store and replication engine that lives entirely in your browser. If you want to build web apps that can seamlessly synchronise data between a laptop, a phone and a server and not treat one as a “master” and the other as “slaves”, PouchDB is your solution.

TouchDB

TouchDB-iOS and -Android are Objective-C and Java implementations of the same idea, but for mobile phone platforms. They natively integrate into your iOS and Android applications and allow synchronisation between themselves, multiple devices, CouchDB’s on the server and even PouchDB in a browser. Again, a milestone in fulfilling the CouchDB vision: data where it is needed, not on some server, far away over a slow and unreliable or even unavailable connection.

Node.js

This might not be too obvious to people who don’t do Node, but CouchDB is big, if not essential here, too. As any programming language & platform, Node.js comes with a package manager called NPM. As far as package managers go (and I’ve used them all except I think ant) NPM is the one that sucks least, or rather, it is pretty good.

If you are invested in Node.js programming NPM isn’t just a tool you can use, it is essential to the development and deployment workflow of your applications. It is that good.

And here is the kicker: NPM’s (de)-central registry is build on CouchDB. NPM is effectively a CouchApp. The Node elders love CouchDB.

I suggest, and plan to turn this into an opportunity for CouchDB. Say, for example, we need benchmarking tools for CouchDB. The Node folks are great at that. If we were to go and say, “hey, do you want to help make NPM faster? Help us build benchmarking tools, so we can speed up CouchDB for you.” — And that’s just one idea, the potential collaboration is immense. Add to that that we maybe get native Node support inside CouchDB, we can do all sorts of crazy shit like writing core add-ons to CouchDB in JavaScript.

Finally, I’d like to mention Hoodie, a project that Gregor, Alex, I and a few friends have been working on on and of over the past year. It is frontend web app framework that uses Node and CouchDB. We are happy to show that to you on the weekend.

The Node Firm

I am going to mention Node.js one more time. Some of you might know The Node Firm, but for those who don’t, think of it as a company made up of the core contributors to Node.js that come together as a collective of professionals to offer services around Node.js that are complementary to the open source project. Things like consulting, technical vetting, training, things that an open source project rarely can do itself.

The key part for me to like The Node Firm (I joined recently) is that, and I repeat, it is complementary to the open source project. It doesn’t try to extract any value from the project, but merely satisfies demand for services that the project can provide. Finally, proceeds are going right back into the community, in the form of conference support, swag, stickers, t-shirts, and so on.

I think this is a brilliant set up for an open source company and I hope many will fork this model.

With that as a preamble, I am happy to announce that together with Dave Cottlehuber and the preliminary support of a few community members, we are launching The Couch Firm, modelled after The Node Firm.

It is early days for us, but expect the same setup, a business complementary to the open source project.

Conclusion

Above all, Open Source is about transparency and community, and I hope you feel you have an accurate picture of where we’re at right now. We had a hard year, lost our traction, and we still came out on top.

With this, I’ll leave the stage for a day of exciting speakers with all sorts of crazy cool topics.

Thank you all for being here!

CouchDB Conf Recap

2013-02-01T00:00:00+01:00

On January 25-27th 2013 we ran CouchDB Conf Berlin. A one-day conference and two-day CouchHack event dedicated to the Apache CouchDB community and technology.

Why

CouchDB Conf was born out of the desire to run an Apache CouchDB Technology conference. Couchbase’s CouchConf used to be that, but has moved away, while sadly keeping the name.

The CouchDB community is a busy bunch and any excuse to get together is taken up with enthusiasm. CouchDB Conf was sold out with ~70 participants in a wintery Berlin.

Conferences in general are great for various reasons:

the core developers get some face time to have a good time, but also to get neck deep into discussions and hacking that require in-person communication. Lots of future plans can be hashed out quickly as well. We made good use of that.
the user community gets to hang out with the core developers, learn about how they work and most importantly, get to ask all the fun, hard, silly and important questions they never dared ask before. We also made good use of that.
Everybody gets to show of what they are working on and get everybody else excited about it. We made extensive use of that. Exictement was rampant.

Eventify captured a few good impressions.

Talks

The slides for the talks are all linked up on the conference site.

One common thread through all presentations that CouchDB’s replication feature is most the popular thing CouchDB has to offer. HTTP and JSON are nice and simple, but replication is the one thing all would go out of their way to point out that it is the thing that makes CouchDB most attractive.

CouchDB’s vision early on was to be able to run on small clients, big servers, with lots of data and very little data, mobile phones and really any device that one can carry around, and crazily enough also in the browser. For the longest time though this was a bit of a pipe dream, as the Erlang CouchDB implementation wasn’t really suited to run on low-power devices and definitely not in a browser.

This now changed. BigCouch makes the start, as it handles CouchDB’s BigData and clustering aspirations. It has been around for a while, but is now finally being integrated into Apache CouchDB proper.

Hot on the heels is TouchDB, which comes in two flavours: iOS and Android, or Objective-C and Java respectively. Both are native reimplementations of CouchDB for mobile devices. TouchDB-iOS is production ready (a few apps are already live), the Android version is a little behind and both are open for contributions.

The newest player on the scene is PouchDB, a pure JavaScript implementation of CouchDB targeted at modern desktop and mobile browsers. Albeit being the newest member of the CouchDB family, it has the highest activity and was recently selected to act as a sample project in the Stanford Computer Science course. It is on the verge of being production ready.

All of this finally brings CouchDB’s vision together. Lots of data can live on BigCouch clusters, regular data can live on regular servers, user-data can live on mobile handsets, tablets and even in the browser and data can float freely between all of them. Application developers no longer have to worry about how to get a user’s data in front of them, handle concurrent updates, sync with offline devices and online servers. Even peer-to-peer sync is possible.

Towards the end of the day, when the whole vision inadvertently came together, the energy levels were very high. And nothing fuels developers better than seeing users getting excited.

Shit is getting real, as the kids say.

CouchHack

The following weekend was dedicated to hands on hacking, some more cool show & tell type talks and a Skype-powered video talk from Bangkok.

Among the highlights are:

CouchDB/rcouch running on the RaspberryPi with Zeroconf auto-networking and everything.
A preliminary port to BlackBerry 10.
Wallaby, a native QT-based app framework that uses CouchDB for data storage & sync.
Hoodie, a pet project of ours.
CouchDB Operations.
Hands on hacking with PouchDB.
Hands on hacking with TouchDB.
Hands on hacking with PouchDB and TouchDB.
Clearing out 30+ issues in preparation for the 1.3.0 release.
Adding GeoCouch functionality to PouchDB.

Use the Time Slider feature to see the topics for all days.

Thanks

As the organiser, I couldn’t be more happy about how CouchDB Conf has turned out. Of course, I couldn’t have it all done by myself, so I’d like to thank the following people and companies:

The Speakers

Katrin Apel, Dale Harvey, David Zuelke, Martin Hilbig, Nuno Job, Volker Mische, Oliver Kurowski, Jason Smith, Robert Newson, Joan Touzet, Stephan Strohmeier, Till Klampaeckel and Randall Leeds.

The Helpers

Gregor Martynus, Dave Cottlehuber and Jan Friedensreich.

The Companies

Co.Up for hosting us, Tito.io for the flawless ticketing, GitHub & Cloudant for the drinks, Nodejitsu, FreshX, Mozilla, EasyBib and IrisCouch for sending people or donating company time.

There are preliminary plans to set up a CouchDB Conf in Seattle later this year. We’ll keep you posted.

Members of the CouchDB Community will be attending the following conferences:

FOSDEM in Brussels, February 2 & 3.
ApacheCon North America, Portland Oregon, February 24th–March 2nd.
Erlang Factory, San Francisco, March 18th–20th

You are welcome to join us and nerd out about CouchDB :)

Thanks!
Jan

Changes and New Beginnings

2013-02-01T00:00:00+01:00

About two weeks ago I parted ways with Couchbase’s day to day business. Not that I was involved much in the end, but it was time to move on. I remain a co-founder and shareholder, but my regular involvement is over.

This wasn’t an easy decision, and as those go, it took me a good while to make it.

About a year ago I started noticing a change. Things I’ve always cared about intensified manyfold and my work situation didn’t leave me with much time and energy to pursue them.

Couchbase made every attempt to accommodate me, let me work on Apache CouchDB for most of the past year, and help with an arrangement where I could spend some of my time at my discretion (with no pay, but enough work to keep me afloat) and I am very grateful for that opportunity.

I spare you the details (ask me over a drink), but in the end I had to answer the question of whether I am a CouchDB person or a Couchbase person. I had to answer that for my working relationship with Couchbase and ultimately I had to answer that for myself.

My heart knew, of course, but leaving a company that you helped founding isn’t the easiest of things to consider. I carried that conflict through most of 2012 and I tried to make things work in a compromise, but ultimately failed, realising that I am, at heart, a CouchDB person.

2012 wasn’t the best of years for CouchDB. That helped me realise how much I believe in the idea and the community behind it.

I learned a lot about myself, turned 30 in December. Around that time, the introspective period of the year turned into action. I was done contemplating what to do with newfound revelations and had a vague plan of the direction things should go towards.

There are a number of distinct moments that helped me figure out what is important to me.

Rails Girls

The Rails Girls movement teaches non-programmers web programming for free. Volunteers from the Rails community would spend their weekends teaching, regular week-nights coaching development groups. All stuff I thought was honourable, but I didn’t see how I could fit that into my schedule, along my regular work and have enough energy to do it all. Yet I saw others doing just that. This created an urgency for changes, so I could, while not teaching Rails Girls, do things I deem important. More on that later.

In the spirit of Rails Girls we started a JavaScript workshop JSFAB (JavaScript for Absolute Beginners) which, along with other similar initiatives eventually culminated in OpenTechSchool, a roof organisation for volunteer learning and teaching. The idea spreads like fire, still, into other tech communities, and other cities and countries. This is truly a tech education innovation. I am very proud to be a part of this.

Gleicherlohn.de

Around the US Equal Pay Day Gina Trapani put up Narrow the Gapp. Anne suggested there should be something like that for Germany, so I spent a total of four or so hours to rip off the project’s UI (open source) and made it so Anne could put in the hard data into a JSON file on GitHub.

Gleicherlohn.de was a mini project with a large effect. The lesson for me though was that web technology, while incredibly accessible already, is still not easy enough to handle for regular people, even technically inclined non-programmers struggle. Why, I thought, would Anne not be able to put this up all by herself.

Then I realised what my original motivation for working on CouchDB and eventually founding Couch.io was: empowering people to use technology to their advantage. I wanted to get back to that.

Giving Back

While talking to friends last winter I made the realisation that we technology people are a rather privileged bunch. Not that there is anything wrong with that, but for me that means finding ways to give back to the communities that enable me to live such a privileged life. Teaching and making technology more accessible fit right in there, so it wasn’t hard to figure out what to do. Instead of working five or seven days a week, I tried to find a way to work as much as I need to live comfortably, while having enough time and energy to pursue pro-bono work. Again, Couchbase was very accommodating here.

Diversity

One last topic that found its way to me is diversity in tech communities. The numbers don’t look particularly good, so I tried to find ways to get this improved. This lead to helping Tiffany to get We Are All Awesome set up, start our diversity-friendly Call for Papers for JSConf EU and the result that we were able to organically get 25% women speakers, an absolute novelty for hardcore tech conferences.

More importantly though is that we inspired many more events to follow in our footsteps, improve on what we did and share the results. I lost count of how many conferences took after us, but is easily 20+. The resulting cultural change is immense. I couldn’t be more proud of that.

I want to make sure I can continue to do this work and I hope I can inspire more people to do the same in the way that works best for them. In terms of work, I want to be able to work on things that matter and get paid fairly, but also not over-do it. Leave enough time to work outside of work.

To that end, I am doing three things:

I am getting involved with The Node Firm.
Found The Couch Firm.
Launch Hoodie.

The Node Firm is a complementary company to the Node.js open source project. A collaboration of professionals to support the open source projects in areas it can’t provide itself.

The Couch Firm is exactly that, but for CouchDB. It is early days, I’ll keep you posted.

Hoodie is a thing to be revealed at a later time, but it is not exactly a secret, if you know where to look.

2013 looks mighty exciting from where I am sitting.

I can’t wait to get started!

The Wartime CEO

2013-01-20T00:00:00+01:00

With apologies to Mario Puzo.

Steve Jobs rarely made future looking statements. “These are the products we have today, we think customers will like them”, is as far as he usually got.

Tim Cook, even when under Steve, is known to boast how the current state of Apple, or future products, are going to play out well in the future. Not that Steve didn’t believe that, but he rarely made a point about it publicly.

Steve kept the world in the dark about Apple’s capabilities. He made us think Apple were still the underdog — the odd-job that focussed on design, when nobody else did, the one with the non-standard retail strategy, really, the one going against most conventional business wisdom — when they clearly and obviously were not an underdog anymore.

As obviously as Steve and Tim knew that to be a strategic advantage, as obvious it is that, if they are correct that Apple is in fact the greatest company of the world, these days are going to be over eventually.

Tim is leading an Apple that everybody knows to be the elephant in the room.

Steve Jobs was a peacetime CEO.

Tim Cook is a wartime CEO.

My Quantified Ass

2012-12-16T00:00:00+01:00

Haruki Murakami in his debut book “Hear the Wind Sing”, chapter 23:

The third girl I slept with used to call my penis my raison d’être.

*

I once tried to write a novella on people’s raisons d’être. It never got off the ground, but for a while there I kept thinking about people’s reasons for doing anything at all, which put me in a strange frame of mind. I was habitually reducing everything to numbers. For eight months, I was a driven man. I’d board a train and first thing count the passengers in the car. I’d add up all the steps in in staircases. If I had a spare second, I’d take my pulse. According to my records at the time, between August 15, 1969, and April 3 of the following year, I attended three hundred fifty-eight classes, had sex fifty-four times, smoked six thousand, nine hundred and twenty-one cigarettes.

All the time, it seems I seriously believed that putting a numerical value on everything would enable me to transmit something to others. And as long as I had something to transmit, my existence would be assured. But, of course, no one showed the slightest interest in the number of cigarettes I smoked or the number of steps I climbed, or the size of my penis. Hence I lost sight of my own raison d’être, leaving me the odd man out.

In Defence of Taking Photos with iPad

2012-09-10T00:00:00+02:00

A phone or a camera will show you a minified version of your motive before you can take a picture. An iPad shows your motive on a much larger display, in a larger size.

It is a digital window into reality. A window that you can ask to capture whatever you see through it at any given time.

But it is not a minified version of reality, not a preview. The power lies in showing the real thing. An iPad allows you to cut out a piece of reality.

Dear Merlin

2012-08-20T00:00:00+02:00

I’m a huge fan (you faved a tweet of mine once, it made my week). I have listened to all of Back to Work and it made a difference in my life (yes, I’ve bought the shirt). And YLNT.

Thank you, honest and heartfelt.

You made public that you opted out of a popular topic last night. Big whoop, somebody said a stupid thing, a politician no less.

You get to decide what shows up in your timeline, what gets to consume your attention and what gets to make you angry. Everybody does. You also get to pick what you publish.

With that pre-amble, I think I am asking you to reconsider publicly stating your opt-out of a discussion that affects half the population, that must affect your wife and before long will affect your daughter. (For the record, I do enjoy the parenting sidebars).

I’m not asking you to fight a fight you don’t want to fight, I’m just asking not to make it harder for the ones who do. And I apologise for getting so personal.

I might be missing the subtle joke, I often do, but that post of yours just doesn’t sit right with me and I can’t help myself and write these lines. I don’t assume malice, and I am certain you are aware of the bigger picture, so I won’t bore you with repeats. I’ll just ask:

Please unpublish, or amend.

The damage may be done, the frog boiled and the joke killed, yet, I need to ask you to take action. What you do, again, is entirely up to you. I just can’t help but ask.

Thank you for your attention and keep up the good work.

Love,
— Jan

Brave

2012-08-20T00:00:00+02:00

Hi Jan ;) what do you think of @brenda_chapman being removed of #Brave ? Is #Pixar sexist? http://t.co/JkNOoSQe

— @RicardaSaleh

The Movie

I love the movie. The story is great, relatable, emotional and amazingly progressive for a Disney production. This film should be required watching for all school children.

The artwork, I have so far only seen the movie in 2D, is amazing. The hair, oh my god, the hair. So good.

It is so good I can’t find proper words for it, just go and watch it.

The Directress

I would have loved if Brenda Chapman’s relationship with Pixar were a posterchild of a woman high up in the hierarchy. But it is not. The article linked in the tweet cites the official “creative differences”, and how it affected her (I do feel sorry) and I am happy she sees her vision brought to the screen after all.

Neither party discusses the details of the break up, so I can only speculate. But I won’t.

Is Pixar Sexist?

Brenda is quoted:

‘Sometimes women express an idea and are shot down, only to have a man express essentially the same idea and have it broadly embraced,’ she writes. ‘Until there is a sufficient number of women executives in high places, this will continue to happen.’

It’s a fact, I’ve seen it in action. If that’s how she characterises Pixar’s side of the story, that is not shining a good light on them. I do hope that Pixar will have a chance in the future to make up for this.

More importantly, I do hope Brenda Chapman and many women like her will get the chance to tell their stories, make their movies and get them released on the major labels.

Freifunk Statt Angst

2012-07-26T00:00:00+02:00

This story begins in 2007. I had to get a temp flat, for a week or two until the one I wanted to move into proper was available and I got the first thing I could. Sadly, no Wifi.

I tried to see what the neighbours were up to, but none were willing to share, so I looked around the ether for options. I found a Freifunk node. No password, free internet, at last. Just very slow.

The reason I couldn’t find a free wifi is simple: German law makes the owner of an access point liable for any legal fuss that’s caused over that connection. Allowing strangers to borrow your internet can turn into nasty legal shenanigans. Most Germans, myself included, secure their wifi with a password. Even cafés often limit access to paying guests.

I read up on Freifunk and thought I should give back to the community. I signed up to the mailing list and tried to figure things out. I couldn’t, people, technology, all hard to get into along with all the life-changes going on, so I shelved it. But I never forgot that I wanted to give back at some point.

The democratisation of networks is a rant I save for a later day, but I like the idea of people-owned networks, shared with everybody, no central authorities to fuck things up. Yay.

Now Freifunk statt Angst (a play on “Freiheit statt Angst”, a campaign against evaporation of citizen’s privacy) against the “Störerhaftung” (literally: “disturber liability”) law that makes most wifis in Germany password secured.

I simplify, the whole situation is more subtle, but suffice to say I think the law is stupid and many people agree. “Freifunk statt Angst”, run by the Freifunk community in Berlin, came up with a nice hack (I’m a sucker for nice hacks, if you don’t already know).

A Nice Hack

Through a random donation, the Berlin Freifunk community got a couple of hundred access points, for free, with the condition to hack the hell out of them. And they did, new firmware, sensible defaults to make the setup a matter of connecting power and an DHCP enabled Ethernet cable (things most everybody has at home, basically).

The kicker now is that a Swedish internet provider provides access to 100 anonymised VPN endpoints.

Everything put together is called a “Freifunk Freedom Fighter Box” and it looks like this:

If you have an existing router at home, the setup takes a full 30 seconds and can be done by anyone.

Free Freifunk Freedom Fighter Box

Best of all, “Freifunk statt Angst” is giving away 100 of these boxes for free.

I picked mine up today after emailing with “Jürgen” after Thilo told me how easy it would be.

The setup was indeed a breeze and within a few minutes I had random people’s iPhones connecting. Yay!

I went out to see how far the wifi would reach and it isn’t bad but it could be better. Luckily modding the box with an external antenna is easy and I hope I can get this set up next week.

JavaScript for Absolute Beginners

2012-07-22T00:00:00+02:00

We are just wrapping up our first JavaScript for Absolute Beginners (JSFAB) workshop.

It was a notable event for a bunch of reasons:

It was the first JS-related coaching event in the spirit of RailsGirls Berlin since their inaugural meetup in in April.
JSFAB is organised by the OpenTechSchool movement that founded itself after the success of RailsGirls. They help making many more events a success.
The whole workshop is pulled together and carried out by a number of great volunteers. They plan the whole thing, they write all the training materials and they spend their weekend coaching students. For free.
You are all awesome!
We used GitHub to collaborate on the materials and it is no surprise that the GitHub model works really well for this kind of work. Pull Requests help getting the material and translations together and issues track things that come up during the coaching that can be imporved later on.
All materials are open source and we would like to encourage you to setup a JSFAB event in your city or join us in Berlin. Feel free to clone, fork, remix and reuse any of our materials or websites. The OpenTechSchool GitHub Organisation is all yours!

A special shout out to Tiffany Conroy and Marjin Haverbeke for writing the bulk of the training materials. Check out Marijn’s book Eloquent JavaScript.

JSFAB 01 was a huge success and I am extremely proud we could pull this off. We taught somwhere between 35 and 45 students over the course of two days and the feedback is great.

With the materials and expertise of this first round in place, I hope we can turn this into a regular event.

Thanks everybody for helping out!

Apple & Standards

2012-07-09T00:00:00+02:00

Guy English is asking for commentary on Apple removing all their products from the EPEAT registry.

I have no special insight into the matter. I just observe Apple and notice patterns. How Apple deals with standards bodies is a well established pattern.

Precedents

Gruber laid it out in one of The Talk Show episodes covering the iBooks Author release. Apple is happy to use, follow and contribute to a standard as long as it aligns with its business interests.

eBook standards didn’t provide enough features for Apple to ship the iBooks Author product. Apple added proprietary extensions and shipped. They then retroactively help pushing the standard along so they don’t have to fork it forever.

The key point is: Apple don’t wait for standards.

Another case: web standards and WebKit-only CSS extensions that then later get amended to the standard. Same story as above, manifold and all publicly documented.

Recycling

I take it as a given that Apple considers eco-friendliness of their products to be a competitive edge. I also take it as a given that they will continue to see it that way.

Now Apple is moving their products in a direction that isn’t reconcilable with EPEAT standards. I do not know what any of this entails. However, I fully expect that Apple is working on a better-than-the-standard (in their eyes) way to recycle their machines.

I don’t suggest they have that today (they may or may not know how to get these screens and batteries out of the machines), but I have no doubt that Apple believes they can do it. And that they can use their PR machinery to communicate this as a “fuck the standards, we are better than the standards” message.

UPDATE, 24.07.2012: Apple is back with EPEAT.

User-centric vs. Enterprise Products or a Small Utopia

2012-03-31T00:00:00+02:00

This is a re-post from an earlier blog. It was published on October 20th

I think it is worth posting it again.

This post has been sitting nearly as-is in drafts mode since May 2008. Today is a good day to publish it. It is about how I think software is changing to the better across the board.

The other day I got into an argument with Damien about how the perception of products changes.

My basic thesis is that with a user-centred product, say, the iPhone, the Enterprise will eventually have to adapt it, because the people that make up the Enterprise will all use the product, despite its lack of enterprise-friendliness (which is no longer as true for the iPhone as it’s been last year).

A user-centred product is something that is designed starting from the user, not the business goals of the company that makes the product or the underlying database technology.

The Enterprise in this case is some organisation that creates a framework for people to work on specific goals. These goals could be very different, take something like IBM as an example. The corporate frameworks need to be reasonably flexible to support all sorts of different goals.

At the same time, the Enterprise tries to maximise cost-effectiveness. Tying everyone to the same hard- and software, because it is cheaper to buy en masse, easier to maintain en masse and easier to teach en masse.

The fundamental problem of the Enterprise is, the users of a specific product have no, or only very little say in what they are going to be using on a daily basis. Committees, with no idea about how a certain bad designed product can affect the individual’s productivity and thus the productivity of the Enterprise, decide what to buy for everybody. And this decision is based on entirely incomplete experiences.

Do you know how to use all the time saving features of your Cisco VoIP deskphone?

Now Damien thinks I am a bit naïve here. The Enterprise will always decide on factors they can measure such as support and maintenance cost and I am sure they will try hard to keep it that way, but I strongly believe that this changes. And it will continue to change to a situation where the deciders realise they operate on insufficient data and let those who are directly affected have an opinion and a voice.

Why do I believe that? Because, only in the recent years, the focus of product development has changed towards creating stress-free tools, easy-to-understand machines, electronic gadgets for everyone. People start to expect things that actually just work and not get in their way. The iPhone is only one example. The Flip video camera is another. The entire business of 37signals is based on caring for the user and not catering the Enterprise.

I think that eventually, this kind of thinking arrives at the deciding committees and they will realise that the Enterprise is best helped with employees that don’t have to deal with utter crap when they are trying to do their job.

I say eventually, it will take some time, maybe decades. And there will always be the ~~bad~~big corporations that do not care for the individual and there will always be bad decisions about what to buy and there will always be crap that salespeople shovel to enterprise customers.

But the acceptance for all this will decline and the expectancy for proper, easy to use products will grow.

Gif me now

2012-02-13T00:00:00+01:00

Spurred by the meme of looking at an animated gif while playing an unrelated YouTube video in the background, I’ve created Gif me now.

It makes participating and enjoying the meme a matter of pasting two urls. The rest is pure entertainment.

I enjoyed a small exercise in modern web development. I refrained from using any sort of CSS or JavaScript libraries and I didn’t build any sort of back end to go with the site. It runs on GitHub pages. Lean and mean.

Plan B (Back to the Woods)

2012-02-12T00:00:00+01:00

Marco [recently reiterated](http://5by5.tv/specials/4 “5by5

5by5 Specials #4: Kindacritical”) a position that I thought I held for myself, but upon hearing it again, I have to consider.

I’m using a Mac and other Apple products because I believe they solve my problems best.

When I started using Macs for work, Apple was much the underdog and I felt cheeky for having chosen the better tool. But I always knew that at some point in the future, when Apple would stop making the most useful tools, I’d look for alternatives.

Aside, Marco and others say they do like to see Android succeed because the competition keeps Apple on their toes. I believe that to be true as well.

I think I could get by on an Android device and I do think I could do my professional work on a Linux Desktop machine (although, I’d probably look into FreeBSD again).

What struck me is that I rarely do anything to support the competing platforms. If I want to make sure I do have a Plan B for my choice of a mobile device and desktop machine, maybe I should start investing now. Buy an Android device, help write amazing software for Android or Desktop Linux.

If push came to shove and I’d have to switch away from Apple, I don’t think I’d be happy with the state of things today and as far as we can expect in the near future. So if I truly believe that I should have a way out, I should start improving that way out.

Now, I just started thinking about this. I don’t see myself dropping Apple any time soon, and I don’t think I’ll get an Android device anytime soon, or start writing software for the Linux Desktop, but I’ll be a bit more diligent about what I can do to make Plan B a viable option.

Trying Duck Duck Go

2012-02-11T00:00:00+01:00

A recent Talk Show mentions Duck Duck Go as a privacy-conscious alternative to Google as a search engine. I thought I’d give it a shot.

I’m using Safari as my main browser and its list of configurable search engines is hardcoded. I can’t even get to it using some default write trickery. John Gruber details a neat hack to get Duck Duck Go as your default serach engine in Safari regardless.

Add the Duck Duck Go IP address 46.51.197.88 (or .89) to your /etc/hosts file with the hostname search.yahoo.com.
Change your default engine in Safari to Yahoo.
There is no step three.

So far…

…the experience is nice. Duck Duck Go is notacibly slower than Google’s serach, but it isn’t bad and the results are good. One neat feature is that if Duck Duck Go detects that it can offer you quick links to, say Wikipedia, those will show up almost instantly and it turns out that is most of what I want.

UPDATE October 15th, 2012: The speed difference has gone down a lot.

I’m occasionally interested in looking at the image serach results for a web search and with Google that’s just one click away and I do miss that now, but I figure a dotjs script or Safari extension will get me that feature back quickly.

UPDATE October 15th, 2012: There are a number of !-commands that help here.

Aside, I’m trying to live with as little as possible customisations, but in recent months, Is tarted adding little tweaks here and there. We’ll see when I go closer to “bare” again.

The Backpack

2011-12-07T00:00:00+01:00

Rands wrote about bags. I’m a bag nerd. Here’s my take.

I’ve been a bag nerd, in particular a backpack nerd ever since my black Jack Wolfskin Mr. Bike when I was 14. It was one of the best backpacks ever made. Unfortunately, Jack Wolfskin decided it would be a good idea to change it to a more modern layout and style and of course they blew it.

I’d still use it, if I hadn’t lost mine in the mist of time. I still miss that backpack.

Luckily, there’s Exped, and in particular the Exped Mountain Pro 20.

Imagine Swiss Alpine backpack specialists that have been at it for nearly thirty years, constantly improving their products and craft alike and who have the highest standards for functionality, design, durability and materials. All in one backpack:

Nerd Factor

The prime reason for me to try this one after a string of disappointing affairs with many sub-par backpacks was its looks.

It does have functional straps covering the front, which I’ll get back to in a bit, but aside from them, the design of the Mountain Pro 20 is minimalist, clear, straight lines and no unnecessary extras. Its form is a nearly exact box shape and avoids the usual pear shape that I don’t like (on backpacks).

To my eyes, this backpack reads “professional backpack” and I dig that.

Scaling

The main compartment is a 20 liter rectangular box locked by a two-way rain-proof zipper. The cover lid holds a small zipped pouch that conveniently doubles as a fast-access or a variety collection space that opens flapping to the front. The front has another slide-in pocket that goes all the way down. A velcro cover keeps the front pocket’s contents dry and easy to reach.

When I bought the Mountain Pro 20, I carried a 13” Mac Book Pro which fits neatly into the slide-in pocket inside the main compartment. The new 11” Air virtually disappears, so does the occasional iPad.

The bulk of the storage space is good for anything between a go-to-work situation, a camping weekend or a hiking daypack. I once managed to attend 5 days of WWDC in San Francisco on only this backpack as my entire luggage. My US Customs Officer joked it was “not enough” (he also joked “WWDC, what’s that? Some kind of wrestling show?”).

The fixed front and side straps at first seem to violate Rands’ requirement on no dangling extras. It even comes with a handful removable and adjustable straps to tack all sorts of stuff on the front and below the backpack. Unused, they don’t get in the way, and if you want to carry something extra (and you will, at some point), you’ll appreciate the setup.

The back of the Mountain Pro 20 is sturdy, which keeps the whole backpack in form and ripped for better wearing comfort, even when your luggage is rather heavy. If you are going really heavy, you can slide in a comfortable and nicely adjustable hip belt.

The outer fabric a special mesh material constructed from what resembles the hexagonal pallets of a beehive. It is very sturdy, poke, rip and waterproof.

Ninja Moves

The Mountain Pro 20 allows me to mimic Rands’ routine at the airport security check. Sliding the backpack over one shoulder, I am one zipper away from the 11” Mac Book Air and optionally iPad. Zip up and I’m through.

Rain: I carried three passports through monsoony surprise rain in Nanjing, China in the lid pocket without any fear of damage. The zippers and seams are all water tight and glued and covered.

The compact form factor allows me to store the backpack close to where I am in any situation, even in tight spots on planes, trains or cars.

The Extra Smarts

Exped’s craftsperson-like attention to detail shows in a number of ways:

All zipper handles glow in the dark.

All length-adjustable straps have a T-shaped end with velcro opposites on each side. This allows you to adjust the straps and then roll up and fix the rest of the band to avoid any dangling.

Let’s look at the fixed front and side straps one more time. I also own an Exped Backcountry 35 for longer trips. It comes with a lot more straps that allow me to hook up the Mountain Pro 20 on the back of the Backcountry 35. I’m not sure this was intended, but it works quite well for situations where your getting through quickly depends on “one personal item only”. I call it the “piggybackpack”.

This allows me to move through air-travel without having to check-in anything while avoiding wrath of my fellow travelers by carrying enormous carry-on luggage. Mounting and dismounting takes anything between 10 and 30 seconds, depending how tight you set things up.

Next Revision

The Mountain Pro isn’t perfect, although it comes close. Here’s what would improve my use.

The biggest gripe is that when I open the top lid pocket as well as the lid itself, it opens to the front turning the lid upside down, causing the contents of its pocket to drip out on occasion. I can avoid this by closing the top zipper first. I don’t know how to solve this nicely.

The other models of the Mountain Pro as well as the Backcountry models come with a nice extension to all zippers: both sides of the zipper have a small rubber handle attached to them that allow you to pull firmly to straighten the zipper so it can be easily opened and closed when the pockets are packed. The Mountain Pro 20 lacks this and it would be a nice addition.

Again, on most other models, Exped avoids plastic clips to join two parts of one strap, but they do use them for upper-torso and hip belts. While they are still intact on my models, I know on other backpacks, they are often the first things to break. Knock on wood that these here are better, but in other places Exped uses an aluminium hook and tightly sewed-on straps for this. It looks a lot more durable to me. Again, a feature I’d like to see adopted wholly.

There are a few extras that are for serious hikers only. A future “City Edition” could remove those for me.

Unique Snowflake

You will have different requirements, but I recommend going through Exped’s product line and I’m quite certain you’ll find something you like, provided you agree with their visual style.

Elop to English

2011-06-16T00:00:00+02:00

We are very pleased to have Apple join the growing number of Nokia licensees,’ said Stephen Elop, president and chief executive officer of Nokia. This settlement demonstrates Nokia’s industry leading patent portfolio and enables us to focus on further licensing opportunities in the mobile communications market.

We plan to no longer innovate in the industry and degrade to a shameless patent-troll corporation.

Couchbase Open Source Internship Berlin Summer 2011

2011-05-09T00:00:00+02:00

Couchbase is offering a summer internship in Berlin, Germany.

We are flexible about timing to make the internship work with your exams and other curricular commitments.

Work with a distributed team of open source developers on one of the most exciting database products of today including (but not exclusive to) Apache CouchDB, memcached, Membase and Couchbase.

We are looking for students of computer science or related fields who want to make first hand experiences with the professional and open source software development world. Interest in dynamic languages is a plus, but not required.

We offer a relaxed work environment, an international team, a workplace in Berlin, proper compensation, and participation in various Open Source projects.

We are committed to diversity and inclusiveness.

If you are self-driven, a good communicator and not afraid to use English, please send your letter of application to: jan@couchbase.com.

Update May 10^th: We are accepting international applications, but you have to be available for an in-person interview in Berlin.

Translations of Selected Parts of “The Multiscreen Revolution” to English

2011-02-22T00:00:00+01:00

The following is a rough translation of selected parts of Adobe CTO Kevin Lynch’s recent blog post on “The Multiscreen Revolution”.

Please note that I don’t hold any ~~substantial~~ grudge against Adobe and wish them all the best finding a way to make the web a better place.

With apologies to John Gruber.

We are in the midst of a revolution across a variety of screens, with new input methods, new formats, and new distribution models. This revolution is being fueled by several fundamental drivers: processing power growth, powerful portable batteries, increasing bandwidth for wireless Internet connectivity, and a wide array of screen sizes and device form factors.

Technology advances.

Average processing power has been on a continuous growth curve for PCs over the past 25 years, with Moore’s Law holding firm as processing doubles every 18 months. This growth is being further accelerated by the adoption of multicore processors.

I remember folklore and don’t shy away from restating the obvious.

In addition to PCs, we now see an increase in processing power on smartphones, Internet-connected televisions, and tablets. This is driving the mobile computing boom and enabling much richer experiences on these screens, with typical processor speeds over 1GHz. Even so, the processing power across these screens is comparable to what the personal computer experience was about seven years ago. While mobile computing power increases, we will continue to have an ongoing processing power gap between PCs on the one hand, and smartphones, TVs, and tablets on the other.

TVs have Internet now.

This creates a challenge for anyone building digital experiences, as they will need to deliver effective experiences across many non-PC devices, not only high performance personal computers.

I’m about to sell you a write-once-run-anywhere solution. But not just yet.

Our approach at Adobe is to take a mobile-first view on the new work that we are doing to design for the more constrained environments, then look to ways to enhance that experience for higher performance environments.

Others are eating our lunch and dinner on mobile. We’ve finally realised this and are running fast to catch up.

Advances in battery technology over the past 10-15 years have enabled the increase in processing power on mobile devices. If we look at this in terms of the amount of energy than can be stored per weight of the battery, the transition from the hefty lead acid batteries in 1945 to lightweight lithium polymer technology today has resulted in dramatic improvement. This is what is enabling us to carry around smartphones or tablets with processing power that delivers such a strong experience today.

I know more folklore, I’m mentioning 1945 so readers think I’m good at being CTO by knowing my history.

This shift follows the classic “s-curve” of innovation, where a technology slowly improves in the early period of its inception, experiences rapid improvement, and then goes into a mature period of slow to no improvement. We are now in the mature phase of current battery technology. It has basically hit a plateau over the past five years.

My editor suggested I pep up this post with graphics, thank god I have analysts as friends, they have all sorts of cool things to put in graphs, like s-curves. They are shaped like an “s”, get it?

By their very nature, mobile devices are much more reliant on battery power, and many web experiences are power intensive.

(Emphasis mine) I watched a Shakespeare play recently.

Since it’s likely that we’re going to be operating with the battery technology that we have right now for at least the next several years, content creators need to consider ways to optimize battery usage.

Technology advances, but not linear. Also, s-curves!

Since Flash is such an integral part of the web, we at Adobe have focused a lot of our energy on optimizing its mobile performance with battery limitations in mind.

By integral I mean skip-intros and the few places where open standards are not yet closing the gap.

In addition to working with our hardware partners to optimize Flash Player for their devices,…

It is not our fault that Flash is so slow on mobile devices!

…we’ve also focused on making Flash smarter in how it manages the CPU resources that it uses. For example, Flash will automatically pause the content that is running when the browser is hidden from view or the current browser tab is placed in the background.

…but we’re willing to look into it on our end, too. Here’s a straw man for our efforts that doesn’t really attack any of the issues that Flash does have on mobile devices.

The display itself is usually the primary power drain on devices, followed by using the radio for communication.

It is not our fault that Flash is so battery-draining on mobile devices!

Some of the simplest things such as turning the brightness down on the screen go a long way toward preserving battery life.

Make sure your tires are properly inflated.

Also, there is a difference in power usage based purely on the number of lit pixels vs black pixels – the more bright pixels on a page, the more power is used.

I don’t know how LED displays work.

Typically, with innovation like advances in battery technology, there will be another s-curve that will slowly ramp up and then give us a major leap ahead of the current state of the art.

S-curves!

There’s a lot of research and investment happening in the realm of battery technology. I expect we will see a major breakthrough over time in this area, which will enable even more radical performance for mobile computing, perhaps even bridging the gap with desktop computing.

We’re going to wait for others to fix any issues that make Flash slow and battery-draining on mobile devices.

The typical connected US household uses either cable or DSL right now, likely running between 10-20 megabits per second. In some countries, of course, it’s faster than this. Wireless data connectivity is starting to increase around the world, and there is a coming breakout where we will see a crossover: wireless bandwidth is going to exceed wireline bandwidth. People actually will have a stronger connection to data on the Internet with a wireless connection, which is being driven by 4G technologies, such as LTE.

I don’t care for anyone in nowheresville.

Wireless operators already are starting to roll this out, starting at speeds of 10-20 Mbps, and the technology has the ability to ramp up to 50-100 Mbps on a per user basis over the next several years. Of course, this speed will vary depending on which type of building the user is in and other factors, but generally we can expect to see wireless bandwidth over time that’s about five times faster than what we’re experiencing today.

I only paid half attention on Computer Networks 101 and didn’t hear the part where it says that latency, not throughput, is the problem with computer networks. I also don’t know how mobile networks work because I ignore the fact that latency is even more important there.

Overall it is going to be a plentiful bandwidth environment, and that’s going to be great for anyone building experiences such as streaming HD video, multiuser games, or rich, live collaboration on the web.

We are going to make the web even slower.

For many years, web designers and application developers looked at the average computer screen size and aimed at that in their work. Over time, this size gradually increased and now we are at a point where this has splintered into many screen sizes. One can no longer design to a single average size.

Remember I was going to sell you a write-once-run-anywhere solution. Get ready for it!

Some content providers have chosen to tackle this diversity through multiple implementations of their websites. But as more and more form factors are added, this approach becomes impractical. Ideally, to take into account all these screen sizes, content can be created once and made adaptable so that it will adjust to a diversity of screens. One emerging approach that is to use CSS to skin your site across displays. Another is to design multiple presentations of content while reusing common elements such as story flow, images, and video that may be dynamically adapted.

Open web technologies are not up to the task.

This transformation from desktop to mobile is happening now. Below is a chart from a recent Morgan Stanley report, showing that desktop connections to the Internet are continuing to increase. In the next three or four years mobile computing is going to exceed desktop computing on the Internet.

Mmmmh sweet charts. Pie charts. Mmmmmh pie.

All of these changes together represent a bigger shift in computing than the personal computer revolution.

I’m thinking CTO-thoughts.

At Adobe, this is an exciting time of change in how we look at building our tooling, runtimes, and cloud based services to help people best express themselves in the multiscreen world. To learn more about these trends and get some insight into how we see this is transforming web sites, digital publishing, video, enterprise applications, and gaming, you can watch my presentation at Adobe’s annual designer & developer conference, MAX (the keynote begins 15 minutes into the video stream).

Finally, the pitch! — Isn’t it great, the future is all scary, but Adobe’s got your back! Because we have s-curves.

Again, Good Luck!