OpenWetWare talk:Software/Subwikis

From OpenWetWare
Revision as of 12:00, 6 December 2006 by Austin J. Che (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Austin Che 15:07, 17 October 2006 (EDT):

This is slightly different from having private pages on openwetware but I believe it solves all the problems with private pages (and more). It also touches on the issue of the openwetware software distribution.

The basic idea is to host wikis for others. My envisioned scheme is something like the follows. We have * be a place for subwikis. People can request a subdomain, let's say SUBWIKI so they can go to to get to their wiki. The subwiki can be setup however one wants such as regards to permissions. A subwiki can be completely private (i.e. requires login just to read), can be like openwetware which requires login to edit but the user list is controlled by someone else (so essentially a lab can lock down pages that only they can edit), or whatever other form you want.

A bit more technical details. To create such a new wiki is very simple. On the server, one script needs to run that does the following: create a new mysql user/password, a new directory to store the subwiki's file uploads (images directory), and a wiki configuration file that includes the database username/password. That's all that needs to be done. The subwiki uses the same mediawiki installation as openwetware and inherits the same configuration file (including extensions). Of course anything can be overriden by the wiki specific configuration file, but the default is to create an empty, completely separate wiki in terms of database and uploads, yet uses the exact same code base and shares the same settings.

An example I've set up is at which is pretty much an empty database with almost exactly the same settings as openwetware. I'm also playing with OpenID. Try logging in to the test server at Special:OpenIDLogin and entering (i.e. your user page on openwetware). The idea is that you can log in to the subwikis using your openwetware username/password.


  • Requires minimal work on the back-end to setup for us
  • Essentially no extra work for subwiki maintenance (i.e. upgrades)
  • Possible single sign-on with openwetware
  • We share and make better use of our new server resources (network reliability, backup, etc.)
  • Can automatically move existing wikis to be hosted by openwetware
  • Easy to move pages (manually and perhaps automatically) from subwiki to openwetware.
  • People no longer need to maintain their own wiki/extensions and trying to match with openwetware. All subwikis immediately get all mediawiki and extension upgrades
  • We've also talked about perhaps using the hosting of private wikis as a means of supporting the public wiki (i.e. some fee for us hosting the wiki).


  • Jamesh008 16:08, 18 October 2006 (GMT): I really think private wikis will encourage more and more labs to start using OWW. I know there is some hesitation as soon as I explain what OWW is about to less enlightened folks!
    However I would not want to see any private wiki need a login just to read, that really defeats OWW as I see it. Editing is another matter and is what bothers people so much.
    How much do you think it will cost to host say 100 private lab wikis? When does the cost become high enough for OWW to start charging, would a donation be more along OWW philosophy, is there a make a donation page like [1]?
    • Sri Kosuri (talk) 11:16, 18 October 2006 (EDT):This is something we come back to over and over. I think it's more a matter of our own organizational capacities. Who deals with downtimes/backups/user accounts/etc? What do we do when Austin leaves (god forbid). Many of us have our own private wikis, but we are willing to maintain that ourselves. Most of the people that help run the back-end of OWW have vested interest in getting information more open. We all benefit from it. However, many people do not really want to invest the effort to maintain private lab pages to everyone. Another option we talked about is we hope to deal with this in the future is to have a OWW distribution. In this manner people could download and maintain the software themselves, with a super-easy ways to move a page onto OWW for 'publication'. You can also imagine doing a public/private partnerships with private wiki hosting companies that are popping up all over the place. Anyways, this is definitely a topic we should bring back to the steering committee, especially considering Austin's progress
  • Jamesh008 16:11, 18 October 2006 (GMT): If you start offering private wikis and get en even greater response than now then lots of labs will be on OWW. Talk:Main_Page has a discussion ongoing on how to handle this. Can we add categories/tags to lab pages along the lines of what they do, type of research, specialisation in techniques? Then get rid of a list of labs on the front page all together. I like the map idea as a replacement, if it is zoomable like google.maps then finding who is near by would be a cinch.
    • I like the map idea too. I also think we need to become far more serious about catergorization. Once again, we need to find out how to do this for us... Any volunteers?
      • Jasonk 12:36, 18 October 2006 (EDT): map is a great idea.
    • Jasonk 12:36, 18 October 2006 (EDT): Hi james, thanks for all your great comments, youre hitting on some of the bigger issues on OWW, and its great to hear the challenges other folks face in trying to convince labs to join OWW. you mentioned that editing is what bothers people the most, but we've also found that people are worried about other's 'scooping' their research, etc. So people have asked for read-control, edit-control, etc. The question for us has been can we make either of these work within the mission of the site: "The goals of OWW are to support open research, education, publication, and discussion in biological sciences and engineering. We promote and support collaborations among researchers, students, and others who are working towards these goals."
      • Write-control -- we've found that while this is a common concern among people that we are pitching OWW to, it ends up being something that they can get over. In particular, we haven't had an incident of vandalism to date, everyone has logins tracked to a single user, any negative change can be reverted back in seconds with the wiki software, etc. Practically, this isn't as scary as it first seems to people. That said, it would make it easier to get labs to join if we allowed write-control, but what would they be joining at that point? Essentially we would be offering them a free wiki hosting service -- it wouldn't be part of OWW at all. I can't edit it as another OWW user, and so they really have their own community independent of OWW. There are lots of other free wiki hosting sites (like jotspot), it doesn't seem like we would be providing anything more than those sites do already, and we would risk labs doing the knee-jerk thing and just making everything write-controlled.
      • Read-control -- This one is slightly more tricky, since presumably collabroation can be increased, by giving scientists some space where they can share ideas outside the public eye at least until they are comfortable sharing them more broadly. In most cases we can encourage both collaboration and open sharing on OWW, but this is one instance where they seem to butt heads. Hence Austin's proposal for read-restricted pages.
      • would love to hear your thoughts on any of this, thanks.
        • Jamesh008 14.34, 19 October 2006 (GMT): I will admit that I would be unlikely to put my unpublished research onto an open source forum. A lot of effort goes into generating data, grants and more importantly ideas! I am sure you all have some concerns although I am not sure how many of us work in labs where we don't even talk shop with those across the corridor because of fear of scooping...

Austin Che 11:12, 18 October 2006 (EDT): For cost, as long as we stay within the abilities of our server and network capabilities (very likely), the cost of hosting 1 wiki is the same as n wikis. However, we are spending a significant amount for our hosted server. I'm not sure that read only wikis is more in line with OWW philosophy. A private wiki that requires login to read doesn't affect you as you won't even know it exists. But a public wiki that people intend you to go to but you can't edit is just frustrating and anti-wiki. Read-only wikis involves people getting over their fear of wikis whereas completely private non-readable wikis cannot be forced into the current openwetware structure.

  • Jamesh008 14.34, 19 October 2006 (GMT): The more I get used to it the more I agree with you, OWW is open, end of discussion (not!)
  • Sri Kosuri (talk) 11:22, 18 October 2006 (EDT): Austin, how do we handle which OWW users have access to any particular wiki. Can we make one normal OWW user, a superuser for another wiki? How do they add new users?
    • Austin Che 11:43, 18 October 2006 (EDT): The easiest solution would be in that script for creating a wiki, to give an existing OWW user sysop privileges. They would have to manage the wiki in any way that mediawiki allows for (unless our ums is rewritten to allow multiple wikis, etc.) I think it would be possible to limit the create user page to sysops. I'm not sure about the openID stuff as the login and create account appear to be the same page.