OpenCore Software

What’s New in Opencore 0.13

The biggest changes in this release are:

• Plone 3 required!
  
• Many things are noticeably faster, because Plone 3 is faster than Plone 2.5.
• Lots of minor bugfixes and usability improvements

For more details, see CHANGES.txt in the opencore source.

This release also requires a data migration that is not backward compatible! Let me say that again:

This release requires you to run a data migration that is not backward-compatible.

Once you upgrade, you can’t go back.

Always Make Backups!

Ahem.

Also, if you have your own code that runs on top of opencore, you should plan on doing thorough testing and may need to modify your code to run under Plone 3.

How to Upgrade

First, make a backup of your ZODB.

Next, run a pre-upgrade migration as described here:

https://svn.openplans.org/svn/opencore/trunk/docs/Plone2.5-Plone3-migration.txt

Note that you need to be on Opencore 0.12.1 (or later, if we ever do an 0.12.2 etc.) to have that migration script available. So if you’re running an earlier version, you’ll need to upgrade to 0.12.1 first.

Then you’re ready to upgrade to 0.13. For this upgrade, I highly recommend leaving your old build alone in case something goes wrong, and create a new build from scratch in a parallel directory. As with previous releases, Opencore still doesn’t work via easy_install, you have to get it by checking out the tag from subversion: https://svn.openplans.org/svn/opencore/tags/0.13.0 and then install using python setup.py develop. You’d also have to install Zope 2.10 and our plone 3 Products tarball. Or use TOPP’s usual build tools which will do all that for you.

I highly recommend the latter approach, it’s a lot more convenient. We have requirements profiles ready for you to build:

• For a pretty stripped down opencore build (just Opencore, Zope, Zeo, and supervisor; no Tasktracker, no Wordpress, etc.), you can use these requirements: https://svn.openplans.org/svn/build/requirements/opencore-minimal/tags/opencore-0.13.0
• For a full-featured build like openplans.org, with wordpress and tasktracker and everything, you can use these requirements: https://svn.openplans.org/svn/build/requirements/openplans/branches/opencore-0.13
  
  … although I’m not sure that’s the right place for that requirements set; Doug Mayle, the deployment manager, could overrule me and put it somewhere else. I’d suggest keeping an eye on https://svn.openplans.org/svn/build/requirements/releases where the final requirements are likely to show up once Doug does all his work to prepare for deploying to openplans.org. That would also be a good sign that we’re getting confident enough to deploy it ourselves

After you upgrade, you’ll need to run the post-upgrade migrations. Again, see:

https://svn.openplans.org/svn/opencore/trunk/docs/Plone2.5-Plone3-migration.txt

Start things up and you should be all set!

Special Thanks

The Plone 3 porting was almost entirely performed by Rob Miller. It was a big job, thanks Rob for moving us forward!

Support

As always, if you have any problems, contact us on the opencore-users mailing list or look us up on the #openplans IRC channel on freenode.

I will be on vacation until 2008/08/25. Good luck while I’m gone

– Paul Winkler

Hi folks, opencore 0.12.1 was released today.

This is a bugfix release with no user-visible new features.

As with the previous release, it still doesn’t work via easy_install, you have to get it by checking out the tag from subversion: https://svn.openplans.org/svn/opencore/tags/0.12.1 and then install using python setup.py develop. Or use TOPP’s usual build tools which will do that for you; however, we don’t yet have a requirements profile ready that uses this tag. You could modify requirements/opencore-req.txt if you have an existing fassembler build that you want to upgrade.

The biggest changes in this release are:

• Force project content deletion to be done via POST; if it’s a GET, redirect to a confirmation form. Reduces chance of accidental content delete by non-javascript clients. Thanks to Alex Clark for being so helpful and patient with us on this one.
• Added migrations/unmake-sites.py script to unmake the local sites at the app root and the Plone site root. Run this JUST BEFORE updating to a Plone 3-based version of opencore, which will be the next feature release, version 0.13. Do not run this migration under any other circumstances or you will break your site! For more info, see: https://svn.openplans.org/svn/opencore/trunk/docs/Plone2.5-Plone3-migration.txt

As always, if you have any problems, contact us on the opencore-users mailing list or look us up on the #openplans IRC channel on freenode.

I will be on vacation until 2008/07/31, I’m hoping my fellow TOPP employees can provide support while I’m gone.

– Paul Winkler

Get it from https://svn.openplans.org/svn/opencore/tags/0.12.0

I am not uploading a package to Pypi because we still have some work to do before opencore works as an egg. I expect to be working on this over the next few releases. For now, the most reliable way to install is still setup.py develop (or use Fassembler which does it for you).

This is as good a time as any to announce that I hope to release about once a week for the rest of the summer! I will miss a few due to vacations. But hopefully 0.13 will be released by July 21.

What’s new in 0.12.0

This is a summary of user-facing changes. For a complete list, see CHANGES.txt in the source code.

* New form for deleting accounts. This is not linked to from anywhere yet, but if you need to delete a spammer, or if a user wants to leave the site, point your browser at people//delete and fill out the form.

* Zip file export view of project wiki pages. This is not linked to from anywhere yet; you have to visit projects//project-wiki-export.zip. Page attachments are not included.

* Email obfuscation for discussion list views

* fix team AttributeError reported by user on summary page

* fix site_url AttributeError reported by user on password reset

* fix user reported UnboundLocalError on pending page

* possibly resolve user reported error on attachment delete

A decree from the release manager:

Until further notice, we will use the common three-component major.minor.patch version numbering scheme, as popularized by Apache and many other projects.

• Major releases (e.g. 1.0.0, 2.0.0) indicate major featureset milestones or large backward incompatibilities.

  Our major release number will remain 0 until further notice (i.e. until we figure out WTF a 1.0 release would mean).

• Minor releases (e.g. 0.12.0, 0.13.0) indicate new features.

  Minor releases may also require data migrations and will generally also include all the bugfixes since the previous minor release.

• Patch (aka “point” or “micro”) releases (e.g. 0.12.1, 0.12.2) may only contain bugfixes, and must be 100% backward compatible.

  No new features are allowed in a patch release. No data migrations may be required by a patch release except as strictly required for a critical bugfix, in which case I might decide to bump the minor version anyway.

You might notice with this policy that minor numbers will get bumped quite often. That’s okay. There’s nothing wrong with numbering a release eg. 0.87.0, except that it would strongly suggest a need to re-evaluate the 1.0 milestone

This is basically the same numbering scheme that we’ve had since we broke out of the infinite 0.9.7.x loop. The main difference is organizational - one person (me) will be paying attention to keeping it consistent. That was the only real problem with Ethan’s previous plan.

I’m going to be playing Opencore Release Manager, starting now. Let me explain what that means, and relay some plans.

Scope

I’m just talking about opencore, the Plone extension at the heart of the openplans software stack.

I’m not talking about any other part of the openplans software stack (tasktracker, wordpress, deliverance, …)

I’m definitely not talking about openplans.org the website.

Opencore needs a release manager?

Opencore was originally created by TOPP for www.openplans.org. So opencore releases have historically been driven by the needs of www.openplans.org’s deployment schedule. Since our deployment process doesn’t require a formal opencore release, releases tend to be a rare afterthought.

But there are at least two things that more formal releases would help with:

1. Lower the barrier for other community members to get started using opencore.
2. Let the world know about what we’re doing.
   

My overarching goal is to promote a lively community of developers and users for opencore, and provide some balance to TOPP’s path of least resistance–to only worry about our own deployments.

Why me?

Ethan asked me to do it and I was happy to volunteer. (If you don’t know who Ethan is either, this picture should suffice: http://www.openplans.org/people/ejucovy )

Who?

I’m Paul Winkler, a Zope user and developer since 1999, a TOPP employee since October 2007, and Opencore’s release manager since right now. http://www.openplans.org/people/slinkp

What will determine the release schedule?

I want to decouple Opencore’s release cycle from the TOPP deployment cycle. Douglas Mayle has volunteered to act as the openplans.org deployment manager; he and I have tentatively agreed on this plan:

• Opencore releases will be on a time-based schedule, TBD.
• Features that aren’t ready in time for a release can just wait until the next release.

  Rationale: Feature-driven releases inevitably get delayed and delayed, and the features don’t get done any faster.

• Openplans.org deployments will be on an independent time-based schedule. (I believe the plan is to deploy weekly.)
• “Must-have” openplans.org features and fixes can be deployed independently of the opencore release cycle by putting them in a new package that layers on top of opencore.
• Openplans-specific code and text (like the current copyright notice) will be gradually moved out into this new package.
• The aforementioned openplans.org customization package does not exist yet; we need to create one ASAP.
  

Of course TOPP’s own needs will continue to drive a lot of opencore development, which is a good thing; but that shouldn’t be a burden on you, the wider opencore user/developer community.

Does the Release Manager have to be a TOPP employee?

No. I’m just the first. It should be a rotating job. It’s my hope that before long, people outside TOPP will be willing and able to play this role.

When will the job rotate?

Don’t know yet.

What does the Opencore Release Manager do?

• Manage the release schedule (not TOPP’s deployment schedule!). This does not mean I’m the dictator, just the point man and coordinator.
• Shepherd release candidates through a stabilization process.
• Create and announce final release packages.
• Document upgrade process.
• Document any backward incompatibilities.
• Draft and enforce relevant dev process standards (e.g. which branches or plugins should you commit bugfixes or features to).
• Document this process for the next release manager.

At this stage, I’ll also be acting as a sort of ambassador between TOPP and the wider community. Which is a bit silly, as every opencore contributor does that to whatever extent they wish. But I think for now it’s useful to consciously formalize it as part of my job. I will make an effort to:

• Solicit community input about decisions we need to make for opencore.
• Remind TOPP employees to discuss and make decisions about opencore out in the open. If you have a real-life relevant conversation I’ll try to remind you to post a summary to the mailing list.
• Keep the community updated on changes to our build process. If we break your builds, you can complain to the opencore-user or opencore-dev mailing list, and you should expect a response from me.
• Lobbyist for the community: e.g. prioritizing and scheduling feature requests and bugfixes.

There will of course be other forces at TOPP driving things with other priorities, but *my* role will be to ensure that the community’s needs don’t get ignored. This is more about release management than development management: I’m not in charge of deciding which features get done when. But whenever good code comes from the community, we have a responsibility to get that code released in a timely manner, and generally be as responsive as we can.

What about the rest of the stack?

We realize that most of the non-TOPP users of opencore are using some or all of the entire www.openplans.org stack. We’d eventually like to be making formal releases of all the packages, and possibly some kind of “batteries included” big meta-package; but that’s in the future. For now, opencore is our fastest-moving target and the most in need of release management.

Release Numbers

We supposedly have a policy now (Ethan proposed it here: http://tinyurl.com/4ybpro) … but we haven’t been sticking with it. I’m going to draft a proposal for a simpler convention and process. More on this in a later message.

Releases, Eggs, and Builds

I’d like to be releasing versioned eggs of opencore to PyPi. These should be installable into a suitable Zope/Plone instance using nothing more than easy-install.

(We have made a few releases to PyPi, but they aren’t actually usable … some files are missing.)

For bootstrapping a full stack including Zope, Plone, and other non-egg stuff, TOPP will continue to use and develop our Fassembler build tools. But it should become easier to do without that, if you want.

Branch Policy

We are currently trying to follow a “Stable Trunk” practice. Experimental and risky code should not be on the trunk.

Developer Infrastructure

This is only tangentially related to release management. I just wanted to note in passing that we’re planning a more thought-out integrated home on the web for opencore development. We’re calling this the “TOPP Dev Center” for now. Other open-source packages from TOPP will live there too.

In the meantime:

Wiki and mailing lists are at: http://www.openplans.org/projects/opencore

Trac (bug tracking) is at: http://trac.openplans.org/openplans

If you need a Trac account, just ask. (I wish we could take anonymous bug reports, but we got trac spam. There is a guest account, but I’m not sure of the login details.)

If you want SVN commit access, first you should send some bugfixes and features as patches (either in trac or on the dev list). We’ll happily give commit access to people who have a history of submitting good patches. There will be a contributor agreement you’ll have to sign, somewhat similar to Zope’s.

Current Road Map

Some things coming up in the short term:

• Plone 3

  We will soon be releasing a version of opencore that runs on Plone 3. Rob Miller has done all the hard work and we just need to QA this branch and merge it back to the trunk.

  Currently, the plan is:
  

  1. TOPP will create a release candidate from the plone3 branch.
     
  2. TOPP will QA this branch.
  3. TOPP will deploy this branch to www.openplans.org.
     
     When that goes well, I will:
  4. Branch off the current opencore trunk to an opencore-plone2.5 branch
  5. Make a final stable release from the opencore-plone2.5 branch (to be followed by bugfix releases as necessary)
  6. Merge the plone 3 branch back to the trunk.

  This will definitely happen this summer; hopefully even in July. More concrete dates will be forthcoming.

  If people in the community expect to continue using the Plone 2.5 version for a while, I would like to hear about it so I can serve you better.

• Easier “plugin” management using z3c.autoinclude. This will replace our usage of zcmlloader, doing the same job but better (and other people are actively developing it).
  

Some ongoing maintenance tasks I’d love community help with:

• Opencore is slow. Let’s make things faster. (But let’s get plone 3 merged to trunk first, it already helps substantially.)
• The test suite has a lot of problems. More on this in a later message.
• Dependency cleanup. I suspect there is cruft in the Products “bundle” that we don’t actually use.
• What do you guys want?

Going forward, this road map should have a permanent home prominently linked in the aformentioned dev center. There is already such a page at http://www.openplans.org/projects/opencore/planning but it badly needs an update. I’ll be looking to revive that.

Questions?

Whew. Sorry for the length. Feedback would be most welcome.

- PW

This showed up on my radar today. It’s a cute little hack, if a bit rough. (I’ve already posted a couple patches).

It could easily be generalized, there’s nothing really zope-specific about it, all it really cares about is a path to a common-apache-format access log and the PID of a process to watch memory. The result is a nice little Flot graph where you can select a range and see what URLs were hit during that time.

Here’s a screenshot of an example from a flunc run against opencore (the “basic” suite):

So what does this tell us really? I’m not sure. Multiple runs show that the graph generally starts around 400 MB and ends around 500 MB, but what happens between does not seem consistent. So I’m not sure if this little app is really that useful for opencore.

Robert and I have been working on the opencore feeds. Currently, these are only used by the project summary page, but looking at the site, we have many things that could be feeds: Latest Projects, Latest Members, Recently Updated Projects, just to name a few. This blog post is sponsored by the word ‘agnostic’, where agnostic means “optimistically not incestuous code” and “incestuous” means “code that unfairly presumes coupling or functionality that destroys perceived modularity and forces binding to a framework even when the desired functionality should not depend on the framework”. Okay, those are just words. The idea is that incestuous code is badly coupled code. Its a word I use alot to describe code I don’t like, because something can (perhaps wrongly) be described as modular but be completely incestuous. Agnostic is the antidote (and the antonym) to incestutous.

Sorry for that gratuitous introduction. The point is that I think what we did with feeds is not a bad model:

[So I tried to upload this image through wordpress’s xinha.  Of course, horrible things happened, so now I’m just linking to it.  GUIs are my bane; did i mention I’m now editting this in html mode, as I almost always do, even though basically i want text ]

This is a horrible diagram with symbolism that only makes sense to me. So let me describe. You have a bunch of content (projects, mailing lists, etc) that provide feed data. They may provide feed data in more than one way, but that’s another story. Instead of having the wild west, I make an interface called IFeedData that forces the feed in the standard format. In this way, I have decoupled what the feed comes from from what a feed is. IFeedData (and its items) have some things that are mandatory to define — the essence of what a feed is — and what is optional.

Moving further right on the chart, there are a bunch of templates. Any of these templates can be used to render any feed. Some of them will work better with particular type of feed than others — for instance, if the feed doesn’t have icons, the portrait_feed_snippet.pt is pretty silly; but each can render the basic functionality of “what a feed is”, and may support optional items, conditionally displayed if they exist. To extend functionality, add a new template.

So we have feed providers, which give us feeds, and templates, which display feeds. How are they used?

So we have this viewlet manager, which has a bunch of viewlets. The viewlets have some sort of context which gets adapted to give a feed. The viewlets *also* have something that says “use *this* template”. In other words, the viewlets decide how the feed is displayed.

I’m not writing this to say “ooooh! look at this cool pattern i helped make!” I’m writing this as an illustration of how something that isn’t (amazingly) incestuous can work. Notice you have decoupling on every level. You have content providers which have rules to transform them to feeds. You have feeds, which have various templates that can be used to display them. You have viewlets, which contain the display logic, tell how to adapt their context to the feed, and choose the template. On top of that, its a simple system: abstract enough to handle anything I can imagine atm, but concrete enough to actually use.
There are problems going forward that I haven’t conquered yet, but I am at least comfortable with the pattern.

It’s time for my weekly rant about stuff that took way longer than it should have!

The Zope 3 component architecture was created to be both cleaner and more flexible than Zope 2. A lot of hard-learned lessons went into it, but man, it sure is hard to debug sometimes.

A little while ago I broke the project create view on the pleiades branch. Yesterday afternoon I noticed the problem and started troubleshooting.

The error was puzzling:

2008-01-04 19:11:35 ERROR Plone

Traceback (most recent call last):

File “/home/pw/opencore-geo/opencore/zope/Products/CMFPlone/FactoryTool.py”, line 147, in __getitem__

self.invokeFactory(id=id, type_name=type_name)

…

File “/home/pw/opencore-geo/opencore/src/Zope-2.9-branch/lib/python/zope/interface/adapter.py”, line 696, in _add_named_adapter

for b in target.__bases__:

AttributeError: ‘tuple’ object has no attribute ‘__bases__’

­

In between were about fifty lines of code twisting through the bowels of Zope, mentioning none of my code at all. And the problem only occurred when doing project create through the web; project creation unit tests worked just fine. That’s never a good sign.

I could get into the debugger right before the problem, but in the middle of the traceback was a call to zope.hookable which I couldn’t step into because it’s in C and pdb is pretty much useless with C code (if you have any tricks to share here, I’d love to learn them). I’d step to that point and boom, get the error. No way to get in any deeper.

After several hours, Whit said something like “you’re pretty deep in to not know what caused this”. In other words, stop trying to debug it and figure out when the problem occurred; there must be clues in SVN. Good suggestion; I get kind of single-minded in pdb sometimes, and need a nudge to try a fresh angle of attack. Whit thought maybe my openplans site instance was hosed somehow, breaking the local site manager stuff (which is apparently kind of dodgy in zope 2.9), but creating a new one didn’t help. Then Ethan mentioned that he’d seen the same problem on his own build of my branch. So it’s not just a local oddity.

So, just before I left last night, I started doing human-binary-search on my SVN commits. The problem didn’t occur at the branch point and did occur in my last checkin; so, check out a revision halfway between and try it. Rinse, lather, repeat. I had to run home but I was quickly weeding out a lot. Today after lunch I resumed the search and in a few minutes determined it was r12176. A pretty big checkin with a fair amount of refactoring, but nothing jumped out at me. I checked out that revision and started poking around.

Clearly from the traceback it’s an adaptation problem, but what kind? From previous encounters with zope.hookable, I suspected that my acquisition context was wrong, giving me the wrong SiteManager implementation (Whit and Ra had been very helpful that time; it turned out to be inadequate unit test setup.) And some things I’d seen in my pdb sessions pointed that direction too.

Eventually I resorted to a crude manual search algorithm: Remove or disable big chunks of the changed code until the problem went away. But nothing I could find in the changelog seemed to matter. The weirdest thing was that I could rip out all references to my code from the rest of opencore, and the problem still happened. As long as opencore/geocoding is installed, even if it isn’t used anywhere, the problem occurs.

Time to get even more crude. I removed opencore/geocoding entirely, and all references to it from the rest of opencore, as a quick sanity check. Yep, problem went away. OK, bring back the module but don’t load its ZCML. Not surprisingly, the problem doesn’t occur.

This is starting to smell like the opposite of what I thought. It’s nothing to do with acquisition context. (With hindsight, I know now that the problem isn’t that an adapter of mine wasn’t being found; it’s that the adapter registry has been f***ed up somehow so other lookups are failing. But since I couldn’t get deep enough in pdb, I couldn’t see exactly what adaptation was failing.)

Now I try loading my ZCML again, but first delete big chunks of the configure.zcml to see which directive triggers it.

Aha! It’s apparently caused by the presence of some browser:page directives that register views that I’m no longer even using anywhere at all. I’d even added a comment above them in that revision:

­XXX these pages are useless now? remove. ­

This is very confusing. Those registrations had been in the configure.zcml for a long time and hadn’t caused a problem until this checkin. Now, I could repeatably cause the problem by putting them in, and fix it by taking them out. WTF?

Well, I can think about it more later. For now I just want to apply the same fix on the head of my branch and make sure it works there.

And it doesn’t.

So maybe now we have some other adaptation problem. Sigh. Then I remember something else. I’d briefly experimented with creating a wrapper on a view by doing IFoo(some_view), but discovered that I can get it to work in zope 3.3 but not 2.9. However, I’d never taken out the provideAdapter() calls that I put in while trying that; they seemed harmless enough and I wanted to remember what had worked in 3.3, so I’d left them in with a comment.

Harmless. Hah!

It turns out that in two of those calls (which I don’t think I’d actually ever tried in 3.3), I’d provided a tuple of interfaces for the “provides” call, which is accepted without complaint, but later on causes the problem.

So there were two causes. I still have no idea what was wrong with those browser:page directives.

That’s the trouble with all this indirection. When everything works, it’s incredibly flexible. When something goes wrong, all the signs point every direction other than the real problem. And just understanding what’s going on under the hood can be really painful. I think I get the joke now, but I’m still not laughing!

Anyway. Rathole escaped! Just in time to not have to worry about it all weekend. Yay!

The performance of our site is not too hot. Here’s my rough take on why and what we can do.

One of the biggest and simplest-to-solve problems that we have is the resources. There’s a lot of files involved in loading up our site. Actually requesting a page isn’t great, but it’s not really that bad on its own. The other resources are what really causes the delay. Several things can be done:

1. We should combine all our CSS and Javascript into less files. We currently have 3 CSS files (two of which are identical ), not counting the IE files (which are also duped). There should be 1 CSS file and 1 IE CSS file, and no more. There should be probably 1, maybe 2, Javascript files, not counting Xinha. Xinha should be a separate single file (with no extra files loaded up with XHR requests). It’s not impossible to combine image files, but it’s kind of tricky and annoying, and we don’t have a lot of image files so it’s probably not necessary.
2. We should do all the best practices for fast loading Javascript. At least one I know of which we aren’t doing, is to put the

   tags at the end of the document so that the browser loads and renders everything before trying to load the Javascript.

3. In addition to combining, we can compress for a bit more speed.
4. Also in addition we can move the resources to a different domain.
   
5. We should worry about caching headers, etc, but we could kind of ignore these last three if…
   
6. … we use a Content Delivery Network. And I think we should use a CDN. I wrote up some notes in #1056.

That’s kind of low-hanging fruit. This stuff can make it harder to maintain the Javascript and CSS, so we need ways to turn this stuff on and off for development. Not hard to do, just something we need to keep in mind.

I don’t believe that clustering will help us much at this time. Clustering would be creating more Zope instances, all reading off the same ZEO instance. I don’t think this would be terribly hard to implement, but our problem right now is more latency than throughput (from what I’ve been able to tell). That is, we aren’t overburdened by traffic, and yet we still aren’t return results quickly. We could profile the system and see what’s taking a long time. We might find some small offenders taking up lots of time. The fear is that we just find that there’s lots of pieces that can’t be extracted or easily improved that collectively take a lot of time. There has been some performance reviews on Zope and Plone, and performance has increased (I think under 3.0, which we are not running). It doesn’t seem sensible to recreate that work on an older platform, so we’d have to update. Though we might find problems in our code, which we could resolve without upgrading. But we could also find that there are no big things to improve, and that Plone 3.0 provides speed gains but nothing dramatic. If that’s the case, well… there’s no easy solutions. We could start doing caching all over with memcached or other caching techniques, inside Zope. This can lead to regressions, exploding memory usage, and just generally it’s a crude (but very common) technique. Caching is more about working around the problem than addressing it, in my experience.

Anyway, if we get there, then we have something else entirely to talk about. For now the resources problems are very solvable.

Once again, I’d been thinking of making a blog post about what I’m working on (short version: I’m taking a break from REST configuration (I’ll leave the puns as an exercise for the reader) to work on what basically amounts to a server-side optimization for the Vespucci project) but I find myself more interested in this discussion on the OpenCore dev list. I thought about making this post an email to that list, but the comments I’m planning to make are basically tangential to the thread there.

What I take away from that thread is that we the OpenCore developers are planning on making people on openplans.org more like projects, with their own featurelets (mailing lists and task trackers and such) to go along with the wiki that’s currently provided. This seems kind of weird to me; as my understanding is that openplans.org is about projects and making it easy for groups with similar goals to collaborate and share skillsets and experience. It’s not clear to me how letting a person track personal tasks or run a personal blog is helping to accomplish that. Instead, I would think a generalization of my earlier thoughts on blogging would be more appropriate: have tabs on the user account page for each of the available featurelets, but show them as a filter on the entire site rather than unique content. So, the task tracker tab would show only tasks assigned to the user, the mailing lists tab would show threads the user participated in, etc. That would let you see things from a people-oriented point of view without creating this kind of island of content where the user has their own personal stuff on a site that’s supposedly intended to help them share with others.

Of course, I have no idea whether this really makes sense. I often find that ways of doing things that make sense to me are kind of lost on non-developers (like when I bitch to Windows users about how hard it is to change file extensions on their platform and they stare blankly and wonder what possible reason you could have to want to do that). But, I’m not a developer on OpenCore so hopefully my perspective on things isn’t too tainted by elbow grease.

Another thought that occurred to me while thinking about this is that if people are projects, and people can be members of projects, then OpenCore obviously supports having projects as members of projects. This excited me more than a little (being a computer geek, I of course love hierarchies!) I think if that sort of nesting of projects is allowed then you can structure things in a way that makes a lot of sense. For example, you can have an Organization be an entity recognized by openplans.org in the same way that People and Projects currently are. An Organization could probably be nearly identical to a Person, but with some string changes (an organization has a logo, not a photo, and services rather than skills, etc.) Of course you can’t log in as an organization either. Organizations and Projects could have as members People, Projects, or other Organizations (think of local chapters or subdivisions for Organization->Organization, and planning committees for Project->Organization) ), and People wouldn’t be allowed to have any members, of course. The neat thing that I see here is that the membership wouldn’t have to be exclusive; in the same way that People can be members of multiple Projects, Projects could be sponsored by multiple Organizations. Organizations could have multiple parent Organizations as well (like Geoserver could be both a subdivision of TOPP and a member of OpenGIS).

Anyway, like I said I’m not really aware enough of OpenPlans to know whether any of what I said is really applicable. To follow in the recent trend of posts on what success is for openplans, I’d say it’s probably not measured by how well the software models the relationship between people, projects, and organizations But I do think that modeling them well makes it easier to present them in a navigable way (that is, making it easier to find projects that are related in the types of ways our software knows about). If our goal for openplans.org is to bring projects together, then it’s probably a step in the right direction.