Tweeters should buy Twitter

There has been a lot of buzz in the Blogosphere about Twitter buyout offers (from Facebook, Yahoo!, Google, etc.) as well as a lot of talk about how Twitter (or rather Tweeting) is too important to be controlled by any single vendor and how it's too important to be so susceptible to outages.

The fist vein of discussion is about monetization. If Twitter can't find a way to make money (without messing with their winning and incredibly simple formula) the thought is that they will be open to a massive buyout offer (and then they'd just let the buyer worry about monetization).

They second vein of discussion in about reliability. The main recurring theme here is decentralization (open it up they say, it should be distributed like any of many of the technologies that make the Internet what it is).

While I find the first idea to be plausible, the second, in my opinion, is not something that Twitter is ever going to accept (ie. i think they would fight, to the death, against it). Oh sure, there are many competitors out there, and some that are better in many respects, but a twitter by any other name is simply not as sweet. The power that Twitter now holds is in their brand. They've crossed a tipping point and are on their way to becoming a household name (if they aren't already). They are now a brand juggernaut of sorts, continuing to attract new users, not through superior qualities, but through massive massive recognition. So, I don't see them being simply replaced and or dethroned anytime soon.

However, I see a convergence between these two ideas. The problems of "How can Twitter be monetized?" and "How can Twitter be stabilized?" have at least one answer in common.

Tweeters should control Twitter.

Now I don't see Twitter allowing this to come about with any less of a fight than allowing themselves to be replaced in any other way, distributed or otherwise. So going back to the idea of a massive buyout offer, which I think they'd be likely to consider if the price were right: If the Twitter community could organize and raise enough money to make a serious offer (through micro-donations, pledge drives, corporate sponsorship or what have you) I think Twitter would be just as likely to take Tweeters' money as Google's or Yahoo!'s. Once Tweeters were in the driver seat I think there would be very little resistance to attempts to open up, decentralize, and stabilize Twitter.

I think the idea is crazy enough to work. What do you think?

M.

Calgary Hacker Space

Recently a friend of mine, wrote:

"Calgary needs a hackerspace. Not because “Vancouver, Toronto & Montreal have one”, but because the Calgary hacker community is stagnant and scattered. We need a physical place where hackers can come together with the purpose of sharing, learning, teaching, and nurturing personal growth. I envision this meatspace location as a place where like-minded people can come to work on very cool projects and allow for the teaching of anyone around to learn.

I should clarify something pretty quick here: I don’t mean “hacker” as in evil computer vandals/criminals. I also don’t think “hacker” is constrained to computer activities. Anyone is a hacker if they possess the mindset of curiosity, abstract thought, and imagination. A hackerspace is for anyone that knows a bit of stuff, with a thirst to learn more, and wants to apply their knowledge/learning to cool projects. I envision those projects including (but not limited to):

• Arduino programming & other electronics
• lockpicking
• computer security
• physical security
• personal privacy & anti-surveillance
• rapid prototyping
• crafting of physical objects (metalwork, woodwork, knitting, etc.)
• alternative energy
• cellphone exploration
• voip usage & research
• radio communication

The above list should also include overlaps between two or more themes, such as:

• electronics+clothes-making = wearable computing
• physical security+computer security = using RFID as a lock

..."
-- Calgary Hackerspace - a call to action

I've never really referred to myself as a "hacker", but that's a term that might apply to me. Whether it does or not, I want to do what i can to help this idea happen.

I must confess, that I'm not even terribly interested in the actual space. I like to deal with the abstract. Even code is a little more concrete then i prefer to get.

I'm really interested in the process. I'm interested in the concept of a group of really smart people, who don't have much in common aside from a passion for something that makes them interested in something else such that someone else might call them a "hacker", all coming together and trying to accomplish something big as a group.

I'm interested in how the space and the group will be managed. How will the group make decisions? Where will the space be? Will it be one space or many? Who holds the keys? Who holds the money? Where does the money come from? IS there even any money? Who owns the space? Who cleans the space? Will people sleep there? Will people eat there? Will people live there?

I've got lots of ideas and, being an idea guy, the idea of being surrounded by people who can take a good idea and run with it excites me!

If any of this excites you, or even mildly interests you, please join the google group or the facebook group and figure out a way to help.

M.

[ UPDATE: 2009-7-9 ]

With a lot of hard work from some dedicated individuals the Calgary Hacker space is coming along nicely!

http://protospace.ca/

Congratulation on the new digs Protospace!

Agile Software Development vs agile software development

I just read Stevey's Blog Rants: Good Agile, Bad Agile and at first i thought he was being overly dramatic and critical, but the more i read about his understanding of Google-style project management the more i realized that he and i are in agreement about what's good and what's bad about "Extreme Programming".

I've started my own company* and, although we are small, we are a team. I've always called what we do "Agile Software Development". Maybe he's right. Maybe we aren't "Agile", but we ARE "agile" and i want to keep it that way because it's great!

Back in the day, i latched on to "Extreme Programming" because the methodology promised salvation from some very undesirable situations. One part of Steve's rant sounds very familiar:

- hire a bunch of [programmers], then hire more.
- dream up a project.
- set a date for when they want it launched.
- put some [programmers] on it.
- whip them until they're either dead or it's launched. or both.
- throw a cheap-ass pathetic little party, maybe. This step is optional.
- then start over.

I've experienced this. It sucks!

As i read Steve's description of Google i recognized the similarities in the ways we prefer get things done (most likely because we've been inspired and heavily influenced by Google's example).

- there are managers but most of them code at least half-time.
- developers can switch teams and/or projects any time they want.
- they never tell developers what to work on (they let them choose their main project).
- developers are strongly encouraged to spend some of their time working on side projects.
- there aren't very many meetings.
- it's quiet.
- there aren't a lot of gantt charts and date-centric dead-lines.
- crunch periods are the exception, not the norm.
- people get fed (especially during crunches).
- people are encouraged not to overwork.

This isn't exactly what we do, but our way isn't so different:

- our developers are our managers.

I believe that you can't effectively manage a role you couldn't preform yourself.

- our developers are not assigned to one project.

Any of us may help out on any given project. We go where we are needed. It's up to the "manager's" to keep track of what resources they have and what resources they need and ask for help when necessary.

- we choose to work on the projects we work on.

We don't take on projects that don't have the potential to inspire us to work on the deeper problems that really interest us. We take on every task with one eye towards research and one eye towards results. It's this cross-eyed balancing act that keeps us interested in the work we are doing.

- we try to keep our deadlines as soft as possible

We still have deadlines because most clients don't want to hear "It'll be done when it's done!" but the truth is that even tho most clients have preconceived deadlines, they usually recognize when they need to let those deadlines slide.

Old habits die hard and i don't expect every one of my clients to see deadlines the same way i do: as a misnomer. There is nothing "dead" about our deadlines. It's just a target or a milestone (which isn't even necessarily a date). Most projects live for a long long time after the first "launch" or "release" and that's not a bad thing.

- we recognize that crunches and meetings should be kept to a minimum

We still meet (and crunch) more then we'd like to, but we splurge on good food when we do. I like to call it our Sushi budget ;)

So I'd say Google-style project management works well for us. Whether you call it "Agile", or "Extreme" doesn't really matter that much to me. The the important thing is that Google has proved that a methodology like this can scale. "Scaling" means it works on the small scale as well as the large scale.

I can't help wondering if it "Slides" as well as it "Scales". Can these same practices work for other industries? Legal? Accounting? Finance? Journalism? Creative writing? Music? any industry in which "thought workers" produces "artifacts"?

I intend to find out, and i'd welcome all the help i can get!

* It's not just MY company. There are several of us and really it's OUR company.

This line speaks to me

E.W. Dijkstra Archive: Answers to questions from students of Software Engineering (EWD1305): "The programmer should not ask how applicable the techniques of sound programming are, he should create a world in which they are applicable;"

Guido van Rossum, you're my hero!

Python 3000 Status Update (Long!): "Python 3.0 will break backwards compatibility. Totally. We're not even aiming for a specific common subset. (Of course there will be a common subset, probably quite large, but we're not aiming to make it convenient or even possible to write significant programs in this subset. It is merely the set of features that happen to be unchanged from 2.6 to 3.0.)

Python 2.6, on the other hand, will maintain full backwards compatibility with Python 2.5
...

The recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously is as follows:

0. Start with excellent unit tests, ideally close to full coverage.
1. Port the project to Python 2.6.
2. Turn on the Py3k warnings mode.
3. Test and edit until no warnings remain.
4. Use the 2to3 tool to convert this source code to 3.0 syntax. Do not manually edit the output!
5. Test the converted source code under 3.0.
6. If problems are found, make corrections to the 2.6 version of the source code and go back to step 3.
7. When it's time to release, release separate 2.6 and 3.0 tarballs (or whatever archive form you use for releases).

The conversion tool produces high-quality source code, that in many cases is indistinguishable from manually converted code. Still, it is strongly recommended not to start editing the 3.0 source code until you are ready to reduce 2.6 support to pure maintenance (i.e. the moment when you would normally move the 2.6 code to a maintenance branch anyway)."

Be Breif

Pimp My Code, Part 14: Be Inflexible!: "You've probably seen some variant of this, but I'll show you my version. In coding, you have many dimensions in which you can rate code:

- Brevity of code
- Featurefulness
- Speed of execution
- Time spent coding
- Robustness
- Flexibility

Now, remember, these dimensions are all in opposition to one another. You can spend a three days writing a routine which is really beautiful AND fast, so you've gotten two of your dimensions up, but you've spent THREE DAYS, so the 'time spent coding' dimension is WAY down.

So, when is this worth it? How do we make these decisions?

The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to:

'START WITH BREVITY. Increase the other dimensions AS REQUIRED BY TESTING.'"

Seat Up or Seat Down?

I'm a proud seat-putter-downer and occasional pee-sitting-downer and now there is scientific proof supporting my stance... err... seat:

The Science Creative Quarterly » THE SOCIAL NORM OF LEAVING THE TOILET SEAT DOWN: A GAME THEORETIC ANALYSIS:

"Discussion and conclusions

For “mankind”, the analysis in this paper has the following appeal: Once again, it has been found that the social norm of leaving the toilet seat down is inefficient; hence, “mankind” may feel vindicated.

For “womankind”, the analysis in this paper is appealing for the following reason: It has been shown that the social norm of leaving the seat down is a trembling-hand perfect equilibrium. Hence, this norm is not likely to go away, at least in the near future."

"Seat Up" may be more efficient, but "Seat Down" results in a more natural social balance.