Archive for the 'Social' Category

Orkut was still alive?

Posted in Social on July 4th, 2014 at 21:14:46

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!

Reasonable Airport Travel. Weird.

Posted in Social on March 23rd, 2014 at 05:02:58

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…

Working for the Man

Posted in Social on February 12th, 2012 at 18:25:39

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.

Are you generative than consumptive in your field?

Posted in Locality and Space, OpenLayers, Social, Software on May 26th, 2009 at 10:57:47

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.

Open Source Project Documentation: OpenLayers

Posted in Locality and Space, OpenLayers, Social on December 11th, 2008 at 16:38:34

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.

Technocentric Thinking

Posted in Social, Technology on June 28th, 2008 at 17:34:52

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.

Why Open Source Matters: Control

Posted in ESRI, Locality and Space, Social on March 12th, 2008 at 10:58:29

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.

Getting Help With Open Source: Just a few bits

Posted in FOSS4G 2007, Social on September 27th, 2007 at 15:49:16

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!

Honeymoon Time

Posted in OpenLayers, Social, meta on June 29th, 2007 at 06:18:57

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!

The story of a procession…

Posted in FeatureServer, Locality and Space, Social on June 8th, 2007 at 05:52:03

Maps tell stories. They tell all sorts of stories, but one of the stories that they tell the best are processions: series of photos taken over a wide area over a period of time, but with the same principle actors.

The most important procession to me right now is the one that I’ve been working up to for four years, as of tomorrow. At the church shown (using the Boston Freemap TileCache, FeatureServer for feature translation from the Flickr API, and OpenLayers, of course, as the map interface) on the map I put together, I’ll be getting married tomorrow to the lovely Jessica Allan.

From Chicago to Champaign-Urbana to Manchester, NH to Cambridge, MA, with more late nights and late flights than I care to remember, more love and devotion than I can describe, and more acceptance of my tendencies to show utter obsession with anything I’m doing than I could possibly have expected, my relationship with Jess has flourished, and I couldn’t be happier to be tying the knot tomorrow.

Okay, so the relation this has to mapping or technical ramblings is tentative at best, but I still think it’s cool. :)