PrioritizingOpenSourceProjectInvolvement

This page exists mostly for people to whine about how we want to do more stuff than we have time for. But also for us to talk about our specific priorities and to share our prioritization strategies.

See Also

Discussion

Here’s my personal prioritization strategy:

  1. Identify the projects that I think will have the most impact.
  2. Other considerations, not as important as total impact:
    1. if the project can lead to an academic publication
    2. if there are actual, specific individuals lined up who are actually interested in using the project
    3. if there are other people interested in working on the project with me
  3. Choose 1-3 projects. Modify this choice as circumstances change.
  4. However, if something else comes up that seems “so cool that I just can’t not do it”, then go ahead, especially if you can do something quickly.

My current priority projects are WikiGateway and Parliament. Why?:

  • I feel that WikiGateway will have a huge impact in the long term, because it will provide a way for people to write software for wiki users that works with different wiki engines, thereby overcoming TooManyWikiEngines. It will also help enable MobileText and other InterWiki stuff. Many of the other wiki projects that I’d like to do someday could make use of WikiGateway.
  • I feel that Parliament could have a large impact in the long term, because we need ways for geographically dispersed groups which meet only in asynchronous online forums to make decisions. A lesser (but more probable/practical) advantage is helping people in real-life Robert’s Rules-based meetings. And even if it doesn’t catch on, maybe it will inspire other software that does.

Both of these projects could also lead to academic publications (at the OnlineDeliberationConference and at WikiSym). Parliament also satisfies minor criteria #2 and #3: there are actual people who might use the project (the UCSD student government), and there is someone to work on the project with (Dana Dahlstrom).

An example of something that I was just burning to work on one day, and so did, was the ReputationBudgetClientExample.

Zooming in on BayleShanks’ “Identify the projects that I think will have the most impact”:

How I find something worth doing:

  • Pick something I want to do, something I believe in doing. (Something neat, but hard.)
  • Figure out: What is the problem? Why is it hard? What could make it easy?
  • Figure out a solution to that problem. (It, too, is probably hard.)
  • Figure out: What is the problem? Why is it hard to implement the solution? What could make it easy?
  • Figure out a solution to that problem. (It, too, is probably hard.)
  • Figure out: What is the problem? Why is it hard to implement the solution? What could make it easy?
  • (lather, rinse, repeat)

Starting from nothing, how do you build a free encyclopedia? You invent wiki. Or computer chips.

So I highly value solutions to problems that make it easier to solve other problems (that themselves make it easier to solve still other problems.)

This prioritization scheme is based in an ethic of OnceAndOnlyOnce. The goal is to reduce problem solving repetition. It is called Wiki:BootStrapping by Wiki:DougEngelbart.

It is interesting to look back, and see that the people pushing these various efforts forward were very much aware of what they were doing. NorbertWiener? didn’t just happen to stumble upon computers. DouglasEngelbart? didn’t just happen to be in the right hobby at the right time. TedNelson didn’t just think, “Hunh, I guess computers sounds kind of cool.” These people, and the people who decided to follow them, were consciously thinking about where this was going, and they were strategizing.

At some point, it becomes hard to know just what projects are more helpful than others. Projects just smear into a plane of “just plain super-helpful,” and it is quicker to just act, than to spend more time thinking. (i.e.: Given a choice between 3 options, it may be quicker to just do all of them in arbitrary order, than to actually spend the time thinking through which is actually better than the others.)

That said, we’re all operating in parallel. If you pick something, undoubtedly other people are working on the others.

I suppose this shows another criteria: You don’t want to pick something everybody is working on. It is preferable to work on something that only a few people are working on. That way, we cover more ground. No point in making the 100’th IRC client: Perhaps explore a different idea, that people aren’t paying as much attention to.

We should, though, consider this beyond just OpenSource projects: There is also writing in WikiPedia, writing in wiki. There is translation. There is teaching. There is activism. There is making companies and business. There is drawing, singing, encouraging. There is thinking new thoughts, performing analysis, thinking critical. ThinkTalkAct. There are many ways of helping out in the world, helping us all to find spirit, freedom, love, understanding, life.

Hmm, kinda makes me feel guilty for working on a video game ^-^

I guess I’m approaching things from a bit more of a “newbie” point of view, I find it hard to imagine myself participating in a “serious” open-source project yet. So, building skills is definitely something to take into consideration. Then I can think of changing the world (OK, of course, I already do).

Some time ago I decided that since I did not want money from my free software development (I get my money elsewhere), I might as well try to be famous. So I put a lot of effort into stuff like helping out newbies on the newsgroups. It was fun to do, I was good at it, and I enjoyed the reputation I was gaining. Groups:&as_ugroup=*emacs*&as_uauthors=Alex+Schroeder yields over 1000 results.

Then I discovered that I had some urgent need myself and I wrote some code for it. It was fairly pleasant because it “scratched an itch” of mine. Using the “be famous” rule, I decided that everything I did would be done for maximum reputation impact: Announcement on the newsgroups, submission for inclusion in the main distribution, proper mailing list, proper website, etc.

This is how I ended up with the projects I’m still involved in: Emacs and Oddmuse. I don’t do much programming outside of these two, however. All I do is hang out on #emacs and #wiki… :)

Why fame? I don’t think it will translate into a better-paying job. I just enjoy being a respected member of a community. Fame is also a good proxy for immediate usefulness. If other people like what you are doing, then you’re helping them right now.

I generally don’t have lofty goals because I am a design conservative by character. I am hard to motivate by a visision of something. A vision is fine if I can imagine the concrete steps that will lead there. If the gap between what we have and what we want is too big, I’d rather work on something else. This is why I prefer to solve current problems rather than future problems.

I know that this kind of approach can be explained using some other term, at first sight “fame” might be misleading. But then again, at the time I was reading a lot of roman history books, and fame often seemed like the only measure for a life worth living. Maybe that’s only true in the surviving sources due to self-selection ;). Anyway, if you weren’t famous at the end of your life, you were nothing. And while I do hope for life after death, I don’t know about it. And since I don’t have kids, there’s only my values and my name to leave behind. :)

Lion’s recursive “build the tools to solve other problems” approach to determining impact is right on. I also agree with Lion that after a few steps up that chain, you wind up with a big list of “just plain super-helpful” ideas and then you just pick some of them.

Re: games: I forgot to put “fun” as one of my criteria. I think this is as important as “impact” to me: I generally only consider projects that are fun for me (not necessarily “maximally” fun, for instance I guess some other projects would be more fun that WikiGateway, but WikiGateway is still fairly fun).

Other things being equal, I’d do something else which was just as fun but had more impact, but if I really wanted to work on a game, I wouldn’t let a lack of impact stop me.

Re: fame: My minor criteria “should be publishable” is really a special case of “should increase fame”. I want to increase my “fame” for the purpose of satisfying one of my career goals, which is to become a tenured professor someday.

On a related note, the Sex and Cash theory].

I wish we had a prioritized chart of projects that we were interested in.

I know that I am interesting in ConnectionPoints?, and various other things. But they would probably be easier to write if we had automated server installation & configuration, a ComponentSystem for these things.

Then there’s the WikiNodesNetwork?, which I work on, and the balancing of ThinkTalkAct. Regardless: It would be nice if we had a prioritized chart. I just don’t know if it’s feasible. Perhaps we should try it.

Sure works good at work!

Well, examining workplace methods:

  • Periodically, we brainstorm about what we can do.
  • Then we say: “What would this bring us?”
  • Then we look through it, and decide, “Here’s what we’re doing.”
  • Then we do it.

This isn’t work, but perhaps we can do the same thing. It would likely need to be done over a longer time frame, though.

Prioritizing doesn’t just make sure your actions are better chosen- it also gives you enthusiasm- confidence that you’re doing the right thing.

Personally:

  • BayleShanks and I talked about it, and we agree: PICA would probably be a major step.
  • MachineCodeBlocks, it is clear to me, are a major boost as well. I think it has clearer benefits, and shorter time to set up.
  • LocalNames is not nearly as beneficial. However, I believe in finishing what I’ve started. It’s not all gloom: I still believe in it, and am learning a lot finishing it.
  • WikiNodesNetwork? appears to be working. People I don’t even know are extending the networks. I’ve learned about all sorts of wiki that I wouldn’t have otherwise known about. It’s the sort of thing where the more you turn the wheel, the further you get. (As opposed to stepping functions.) This was a really good thing to do.
  • SocialBookmarkingToWiki, God smite me now for not doing it immediately, is short, and I have no excuse for it not being done now.
  • It’s great Alex is working on RSS caching right now. It’s going to make HubAndSpokeWikis work, I just know it. We won’t fear posting elsewhere.
  • We could have a thing that makes a mailing list out of any wiki, … This could help the mailing-list only people adapt to wiki. I’m still judging this concept. A “wiki accelerator.” It might even revolutionize wiki use, if it proved popular and easy enough.
  • ConnectionPoint would be incredible, (wiki annotation of all static nodes,) but would only be a feature of the mediums it was installed on. You’d have to invent a ComponentSystem before it would be widely deployed. (Or maybe not? Maybe people’d just implement it 1,000 times over, for every medium? That’s how wiki improves, so far…)
  • ComponentSystem - which would help out all mediums, but is outside our expertise. It’s probably a lot of Apache work, or something. Lots of heavyweights are working on this.

Speaking of which:

  • One factor in deciding what to do is recognizing what your skills are. That said, this can be over-perceived: We are capable of stretching ourselves in ways that we are afraid to. (“Yes, you can learn that language, or find someone who can write in it that you can motivate.”)

Your description about how you prioritize at work implies that we would actually work on what the community decides was important, rather than what we individually want. While I wouldn’t be totally opposed to that if there was a way to budget only a tiny amount of my programming time for “the community”1, otherwise it’s not something I want to do

But perhaps you are just talking about making a chart (without the power to tell us what to do), which I think is a great idea. We could start by listing our individual priorities, and then we could work on our group priorites. Let’s put it on a separate page:

CommunityWikiProgrammingProjectPriorities

Oh, totally. I totally agree.

I was talking about a shared chart.

My theory is that with a shared chart, we can fill each other in on things we hadn’t realized.

And it frames things for conversations like: “Is PICA more fundamental than OverHear? Does OverHear help PICA more, or does PICA help OverHear more?”

yadda yadda yadda- yeah. You already know.

Footnotes:

1. I only get to code once in a blue moon, so my per-day output is small – but I also wouldn’t want to “save up” the dedicated time and then dedicate an entire coding weekend to CommunityWiki, because those weekends come so rarely that I really want to use them for my own projects

Define external redirect: DouglasEngelbart WikiNodesNetwork ConnectionPoints NorbertWiener

EditNearLinks: TedNelson OpenSource

Languages: