OpenCore Software

­

I started the outline of this post by writing a “Reactive Section” and a “Proactive Section.” As it turns out, I don’t have enough time to focus on the Proactive Section, so I’m just going to do the Reactive Section. Hopefully I’ll get to a Proactive Section next time around

So, without further adieu…

The Reactive Section

Response to Whit/Seb/Rob

In response to Whit’s response to Seb’s blog post, I must agree that these posts provide a really helpful perspective; please keep them coming. Specifically responding to Seb’s post, I very much agree with Rob’s interpretation of how the meeting turned out the way it did. My goal for that part of the meeting was to reinforce the importance & relevance of the UWSSR project, and to get people fired up about it. There had been a bunch of talk on the list about Lloyd, plus I had spoken privately with David about it, so I wanted to mention it in the context of everything else, just to keep the conversation above board . But I certainly didn’t expect to have the type of discussion we had (maybe I should have). No secret agenda here.

However, both Seb’s blog post and Doug’s suggestion that mgmt write our own iteration goals really struck me — I didn’t realize the extent to which the process seemed opaque. It’s amazing how clear things can be when they’re in your head. So thanks guys for really bringing that up, and this blog post is step 1 of me doing something about it.

Personally, I really hope the heated Lloynz discussion didn’t take away from any excitement we are building about Sputnik/UWSSR. While it may feel like we are getting off track, I agree with Whit that it’s a huge opportunity to ride the wave of interest and (hopefully) start putting our product to the test.

Toward less reactivity: how I want to kick ass

I think that Ian pretty much nailed it, and I’m glad he said it. Underlying much of the discussion we’ve been having lately, but never laid out as eloquently as Ian laid it out, is the idea that we need to attain a certain level of success before we can be ready to chart our own course. We need to prove (to ourselves and to others) that we know what we’re building and why, and that we can execute it really, really well.

Not to pick on Task Tracker, but we got a support email today to the effect of “does the tasks section work, at all?” Yikes. But the truth is, as long as there are parts of our product that are that shaky, we aren’t kicking ass yet.

UPDATE:  It turns out this user was actually getting deliverance error, so nothing was showing up at all.  Sorry, task tracker. 

I also liked Ian’s point that kicking ass means something different to each of us, and it’s up to us to figure out what that is. Ok, I’ll go: For me, kicking ass means doing my best to understand how everyone on the team is doing on a daily basis — in terms of getting work done, sure, but also in terms of feeling good about the work they’re doing. Jeff’s blog post today showed that he’s reached a breaking point dealing with the build all by himself, and ideally it shouldn’t come to that. Kicking ass also means making it clear where we’re headed in the near future and what’s on the horizon. Obviously we have some work to do on that. I’ll also judge myself an Ass-kicker if the people on this team get to know and respect the “content” people we work with (here at TOPP, in our partner organizations, etc.), and vice-versa. I really think that that’s crucial for us to be successful.

Grandiose much ados about nothing

One thing I’ve noticed lately (and especially today) is that people _really_ like to debate the different approaches to solving a problem. At the risk of sounding like a technophobe who wants to stifle discussion, I must say I’m really amazed that anyone can get any work done, with the amount of debate on the list. Now, of course, debating strategy and architecture is an important part of designing a product, that I know, but sometimes it feels to me like we’re more interested in the academic discussion that in the final product. I simply love Jeff’s post: “My plan is pretty straightforward….Get this working the hackiest way in zope for wiki + listen lists….At this point, there is something to show…” It’s not that I want us to make hacky software; I want us to get something going, in the simplest way that works, and get some use on it. Which brings me to my next point…

One band, one sound ­­

You probably don’t know this about me, but one of my favorite movies of all time is Drumline. It’s about a southern marching band, and their trials and tribulations as they attempt to kick ass (Sorry Ian for taking your phrase and running with it…) The band leader’s inspiring mantra is “one band, one sound,” and it takes them almost the entire course of the movie to understand what that means and embrace it.

Here at OpenPlans, one of the things I’ve been struck by the most is the way that our product doesn’t seem quite like _a_ product. Now that I’ve been here a while, I get the microapps concept, I’ve seen the architecture diagram, and I more or less understand how it all fits together. However, I’m still sometimes left feeling like we don’t see our product as a single product. In the end, we’re making a website, and it doesn’t matter if it’s monolithic or modular, all that matters is that it does something useful for our users.

Our product will start to kick ass when we start to work backwards from the goal of our _product_ kicking ass.

The Proactive part of the Reactive Section:

So, as promised, here are some of what I see as my iteration goals:

• Get us ready for a successful launch of Sputnik and the release of WP
• Work with Mark, Lindsey & others on the UWSSR site
• Reach out to people & organizations we work with to get feedback and gauge interest
• Keep everyone in the office abreast of new developments (of all types) by blogging or writing to the list
• Work with the mapping and UI teams to develop the concept for the first go at wiki mapping
  
• Work towards articulating more medium- and long-term goals for OpenPlans
  
• Work on a calendar for OpenPlans development. See the beginnings, including the short term milestones for Sputnik, here: http://tinyurl.com/2d88y9
• Backport existing opencore blog posts into our new real blog
  
• Do what I need to to relieve Rollie of design duties so he can focus on Sputnik.

Ok, on that note, I’m going to sign off for the night. Blog post take 1, that’s a wrap.

Comments: