Technical Ramblings

While at the park flying the other day, one of the swarm of kids who came up to me was super interested in looking at the drone and asking how it worked. This isn’t new: kids love the drones, though this kid was one of the hyper-enthusiastic bent rather than the more shy/reserved ones who watch from a distance. My wife asked him if he was going to be interested in being a nerd in the future.

Now, this kid was in 3rd grade. The correct answer to that answer is “No” — in third grade, nerd is a pejorative. So I was unsurprised to hear him say “No, I’m not going to be a nerd when I grow up.” His reaction was entirely in line with what I’d expect from anyone his age asked that question.

My lovely wife followed up with the typical question: “Ah, what do you want to be when you grow up?” This is a totally typical question that I will ask to the kids who are interested in my drones; typical answers vary, but I’ll often get “video game developer” or “computer programmer”; since sometimes they know I work for YouTube, “I want to work at Google/YouTube” isn’t all that uncommon. These days, these pursuits are all pretty mainstream (at least among the typical “white upper-middle class 3rd graders living in Cambridge, MA” who I typically run into with these answers). But I was a bit amused to hear his answer:

“A geologist.”

At this, Jess and I both started chuckling: Oh, I’m not going to be a nerd when I grow up, I’m going to be a geologist!

The kid looked at both of us laughing and was confused. “What’s so funny?”

I responded: “Well, to me, being nerd is largely about being passionate and excited about som…”

He interrupts: “Oh! Yes, then I’ll definitely be a nerd when I grow up.”

(The rest of the sentence was going to be “about something, especially technical pursuits or scientific pursuits”; though you can be a nerd about just about anything, to me it’s strongly associated with unique scientific explorations.)

The eagerness with which he was willing to commit to being passionate about his interests — interrupting me in order to do so — was charming. Given his overall attitude, it was no surprise to me, of course: this is someone in whom I could recognize a more bold version of myself. (Despite my attitude later in life, in third grade, I was somewhat reserved, having felt myself be crushed under the heels of terrible behavior of kids at that age.) He was excited and enthusiastic and passionate was a great word to describe his interest.

A nerd is passionate. Whether it’s about drones, or computers, or geology or sewing; whether it’s about family history or library science or chemistry: passion is what makes the difference. Whether you’re in third grade or 30 years old: Find your passion. Find your way to be a nerd.

Google announced this week that they will be closing down Orkut at the end of September.

Most people reacted with “That thing still exists?” (Unless, of course, they are Brazilian.)

I was an Orkut hipster; I joined before it was cool. (Specifically, I joined back when the network actually wasn’t ~fully connected; my roommate in college and I had different ‘friend graph’ sizes, IIRC.)

Apparently, I used my crschmidt@livejournal.com email to join Orkut. I was able to login and see my profile, and see some of the testimonials that were left for me a decade ago, mostly from friends on LiveJournal.

The one that gets me, is this one (left by an anonymous user):

I would not push Chris Schmidt in to oncoming traffic. Normally when I say that about somebody, it has to do with my ethical code. In this case, though, it has a lot more to do with who Chris is as a human being.

At the time, I’m pretty sure I figured out who left this testimonial, but the cultural context in which it was left has been lost to me now. So I’m left with a vaguely positive testimonial from an anonymous source from a social network I abandoned a decade ago.

… Actually, that sounds about as positive as an end-of-life social networking experience can be. I’ll take it!

I’m flying out of Logan to SFO this morning, and I’m flying JetBlue through terminal C. Usually, Terminal C is a *mess*, but this morning, it wasn’t at all:

• Usually, they have 1 or 2 stations checking IDs; this morning, they had 8
• Usually, I’m used to the USian approach of “Take out all the things and off all the things”. Here, I didn’t even have to pull my laptop out of my bag.
• Instead of the weird millimeter wave machine — they only had x-ray devices.

I did briefly have my bag pulled aside — since I’m flying with 3 heavy LiPo batteries, I wasn’t surprised — but as soon as they realized they were just batteries, and the one that they looked at was in a plastic bag, they let me go without a problem.

Brilliantly simple security. I wish I could have that more often. Of course, since I wasn’t expecting it, I’m now sitting at the gate 1.5 hours before I can even board…

Sometimes, I wish that I could talk more about work openly.

I do a fair amount of what I consider somewhat cool stuff at work — as is evidenced by my somewhat lower work in open source these days. (Since I find my work more interesting, I spend fewer of my off hours invested in ‘more interesting’ projects than I used to.) Of course, in reality, I expect that most people would still find what I do completely boring, but to me, it’s exciting.

In the past, when I worked for MetaCarta, there were only 20-30 people who would be in a position to be upset by what I would talk about — if I wanted to chat in public about something, I could usually chat with everyone who might care about it in an afternoon, and get a go/no-go from them.

But now, I work for a much larger company, and speaking out of turn could have much larger consequences. (Not the least is the fact that the company is publicly traded — so anything I say has the potential to actually shift a public stock price.) The group that I work in is significantly larger than MetaCarta’s core of engineers, and the number of levels between me and the top is comparatively larger.

So now, when I’m working on things that I consider cool, or want to share — I typically have to just keep my mouth shut.

Recently, one of my coworkers was trying to encourage someone from our team to present at the Berlin Buzzwords conference — talking about how good it would be to present some of what we do at the conference to get feedback from others working on the same problem. I couldn’t help but think, at the time: What exactly do you think that we could share at this conference?

Maybe it’s a cultural thing, but I feel a bit stymied by this regularly — even inside the organization, sharing data we’ve gathered becomes a political, rather than a technical, decision. Oversharing without consideration for how other teams will see the data is something that can have significant negative impacts on our interactions with other teams, because it’s very easy to step on toes.

I realize that this is all part of working in a large organization. Overall, there are a lot of positive benefits — in fact, much of the reason that I have more data that I’d like to share now is because we have a larger set of resources than we had available at MetaCarta, where many of the projects I worked on were just me hacking along on them alone. It doesn’t make it less frustrating, but it does swing both ways.

But sometimes I still just wish I could blab about what hack I spent my weekend on. Or open source another small project. And it’s a shame that I can’t.

Anselm just posted what appears to be a random thought on twitter:

Are you more generative than consumptive in your particular field? … Create more than you consume?

In open source, I often rephrase this question as “Are you a source, or a sink?”

There are many people in the community who contribute more than they consume. Organizations, individuals, etc. There are also many sinks in the community — since entropy is every increasing, this seems a forgone conclusion — and one of the key things that causes an open source project to succeed or fail is the number of sources or sinks.

I personally try very hard to be a source in all that I do, rather than a sink. One way that I do this is that I try very hard to always followup any question I ask — for example, on a mailing list, on an IRC channel, or what have you — with at least two answers of my own. This means that, for example, when I hopped into #django to ask about best practices for packaging apps, I stuck around, and helped out two more people — one who was asking a question about PIL installation, and one about setting up foreign keys to different models.

Now, in the end, my answers were simple — no one with even a basic knowledge of Django would have had problems answering them. But by sticking around and answering them, I was able to make up to some extent for the time/energy that I consumed from someone more familiar with the project, by saving them from needing to answer as well.

It is often the case that users trying to get help will claim that once they get help, they will ‘contribute back’ to the community by, for example, writing documentation. This never happens. Though there are exceptions to every rule, it is almost always the case that users who ask a question, prefacing it with “I will document this for other users”, never follow through on the latter half. The exceptions to this — or rather, the alternate cases — are cases where a user has already investedлегла significant research, and likely already started writing documentation. Unless the process is started before the problem is solved, it is almost universally true — in my experience — that the user will act as a sink, taking the information from the source and disappearing with it.

I work very hard on supporting a number of open source projects that I work on. Though my involvement lately has been more hands off — by doing things like writing documentation instead of answering questions, acting as a release manager instead of fixing bugs, and so on — I work very hard to keep the karmic balance of my work on the positive side. I believe that this pays off in the long run — I have somewhat of a reputation of being helpful, which is beneficial to me since it means I’m more likely to receive help when I need it. I also work to keep karmic balance high on the part of the organization I work for, since many of the other people in the organization are less able to keep karmic balance high.

These rules don’t apply solely to open source — I have the same karmic balance issues going on in my work inside of MetaCarta — but I maintain the same attitude there. Coming in with the idea that it is okay to be a sink can lead to a nasty precedent. In the end, I think that everyone loses. Sinks — both in open source and other karmic ventures — will eventually use up the karma they start with, and be left out to dry. It is the case for more than one person that they have extended their information seeking without contributing back beyond the point where I am willing to continue to support their information entropy.

I joke sometimes about giving out “crschmidt karma points”. Though I don’t have an actual system in this regard, I do quite clearly delineate between constant sinks, and regular sources, and grey areas in-between. I try to stay on the source side, and I encourage anyone else to do the same — even if it’s only by answering easy questions on the mailing list, or doing a bit more research on your own. Expecting other people to fix your problems, in open source or otherwise, is simply a false economy of help, since in the end, it simply doesn’t work.

Earlier today, I read a post on the OpenGeo GeoSpiel blog calling for OpenLayers to get on the “Usable Documentation Bandwagon”.

Now, I’ll be honest: I followed the links that he offered, and found something that is not, to me, much more convincing than the OpenLayers documentation as it stands today. If I look at ESRI’s JSAPI, I see a couple things wrong right off the bat — like the fact that I can’t actually link to where I want to. In any case, if you click Geometry -> Point, you see a document which, to me, is a lot less interesting than the similar page provided by OpenLayers.

Perhaps there is some subset of documentation put together by ESRI in their JSAPI that makes sense, but for an API reference, it seems to me that OpenLayers does reasonably well on the portions of our API that someone has invested time to work on.

This doesn’t mean we’re “done” by any stretch of the imagination: One of the things that I’ve wanted to do for ages is actually sit down and do a thorough review of the OpenLayers API documentation and improve a lot of it, targeting cross-linking with other documentation and examples especially. These types of tasks, however, are the types of tasks that require a lot of time, and don’t have a lot of immediate benefit. Since all work on OpenLayers for the past several months has been my personal free time after work, there’s only so much I’m personally able to do. However, no one has *ever* made a request to the OpenLayers team to be able to do this work — including OpenGeo — that I’ve seen. It seems to me that whit is experienced and knowledgable about OpenLayers, since I’ve seen him using it for development, but I’ve never seen him ask to participate in improving the OpenLayers API documentation on the mailing lists, nor have I seen a request of this nature from any other organization.

To me, this means that it’s likely that our API documentation does, to some extent, meet the needs of the organizations using OpenLayers. It’s not perfect — nothing is — but no one thinks it’s a major stumbling block that’s worth fixing, at least not enough to spend money on it.

This is exactly the type of reason that OpenLayers is now accepting Sponsorship from organizations looking to support the project. This type of improvement is exactly the kind that project sponsorship can help support.

OpenLayers is aware of how important documentation is to the success of the project. We have invested dozens of hours between a dozen different contributors to create and maintain a set of relatively complete API documentation. According to Ohloh, of the 55,000 lines in OpenLayers Javascript, over 30% are comments: over 25,000 lines of what is mostly API documentation. No one is ignoring the problem — and if the current state is insufficient (as everything in the project is, *especially* to new users and beginners), then we’re very open to help from any and all interested parties.

API documentation isn’t the only thing a project needs, of course. Documentation comes in all forms — and OpenLayers is seriously lacking in a lot of documentation targeted towards beginners of all kinds. We’ve been working to change that, with a new documentation site available, and other efforts targeted documentation of OpenLayers in English and other languages. I would say these efforts are much less complete than the API documentation, and starting on them is far more important, in my opinion, than improving our API documentation is at this time.

OpenLayers is a large library. It’s used by many organizations. We’re open to contributions of all types — never have I seen OpenLayers turn away someone who wanted to help with documentation intentionally. We have regularly worked with contributors in helping them to improve the documentation, and to claim that we are ignoring the need for documentation seems to me to be representative of a lack of knowledge of the tools that the project uses for documentation, not specifically a lack in the goals of the project, which puts documentation of functionality — via API docs and minimal examples demonstrating functionality — as a requirement of almost all new code in the library.

Chad writes:

I know their “motto” is “Don’t Be Evil” .. but I think it should be “Don’t Be Smart” instead.. this is some dumb thinking from Google. Trust me.. I know better than Google on how I want to download and install my software.

This is just the latest in a whole lot of similar statements I’ve seen from many people across the web in a variety of situations talking about how “I know how to manage my machine”, with the underlying meaning being something like “You should act as if people who are working with your software know how to work their computers.”

When I put it that way, does it really sound right? Is there anyone who thinks that the *majority* of users of Google Earth actually know how to run their machines? Is there anyone who thinks that it makes sense for Google to build and QA two different install mechanisms — one for technical users who know what they’re doing, and one for those who don’t?

Very few companies the size of Google do anything on a whim. I expect that some thought went into the development of the Google Earth downloader. The fact that the thinking is not centered around technically competent users is just evidence that Google doesn’t need to target the early adopters; it’s not a sign that what they are doing is ‘Bad’ or ‘Stupid’.

Technical users are few and far between in the mass market. Google Earth is targeted towards the mass market. Just like all software that is targeted towards a mass market, there is nothing ‘stupid’ about removing tools that the majority of users don’t need or care about: By doing so, you limit the number of people who are going to end up confused by your tool, and that’s not a bad thing when you care about the majority of people instead of a technical elite.

Jo Cook writes about ESRI’s crackdown on licensing:

In what can only be described as a noble act of self-sacrifice, ESRI have told us that as an educational charity we are no longer allowed to have an educational discount for using their software and, not only that, our license codes will cease to work at the end of this month.

This is why Open Source software is so important. So you think you have a stable relationship with your vendor? Maybe you think that you’ve come to a great licensing agreement that you’re happy with? Remember that so long as you’re working in an environment where someone else controls the tools you use, you’re not able to make your own rules.

Why does Open Source software matter? If you’re not using it, you’re handing over control of your use of your tools — possibly important ones — to people who aren’t under your control. In the end, that lack of control may end up hurting you far more than you’d expect.

Three quotes from my presentation earlier today, on Getting Help With Open Source:

• On talking to Open Source developers and asking for help: “Be Polite, Be Concise, Be Gracious.”
• On diving into the code: “Code is pickled, executable documentation.”
• On choosing your requests carefully: “A developer’s time is a limited resource. Don’t waste it!”

Talk went well. Transcript recorded by Arnulf on IRC (original). Many thanks to Arnulf, and all the attendees!

As of 5PM today, I will be unavailable on the web until July 9th. I’m going on a honeymoon, and I’m leaving my computer offline for the entire trip. (Yes, I am a workaholic. Heck, I committed to OpenLayers less than 2 hours before my wedding.) So, although I will be at home slightly more than that, you should not expect to hear from me until July 9th. If you have something that requires my urgent attention, please get it to me today 🙂

My actual honeymoon will include a stay at the Mount Washington Hotel, in the White Mountains of New Hampshire. Not to pat myself on the back too much, but I think I’ve earned it 🙂

Don’t break anything while I’m gone!