On Sun, Feb 24, 2008 at 03:08:10PM -0800, rygle wrote:
It is hard to contribute meaningfully as a non-hacker. These lists require one signup, and then to use them meaningfully (ie: like a forum), another signup on nabble. I don't know how to create new pages, even if I can create new sections within a page. Again, another signup to do that though. Wouldn't it be great if one signup did both a forum (replace the email list) and the wiki? Wouldn't it also be great if that one login let you update your extension on the Inkscape extensions section? Or the same login would let you comment on other extensions?
It certainly would be great to have a unified authentication system. Implementationally though, it's far from trivial. Something built on either LDAP or OpenID would probably work best - we'd just need someone to set it up for us. I've heard that Launchpad is implementing OpenID, and while I don't know the current status, perhaps it'd be easiest to wait until that's in place. Then it'd just be the work of adapting our existing site, tools, and so on to leverage that.
I agree that it would be great to have a menu item that led you to http://extensions.inkscape.org, and let you click on the page to install them. Like xpi's for Firefox, they could be a zip or gzip archive just renamed to make the association with Inkscape work. They could contain all the same stuff (.py and .inx files), just packaged up with a simple zip and rename operation. Clicking on the file would put it in /{home}/.Inkscape/Extensions on Linux or /Application Data/{username}/Inkscape/Extensions under windows (don't know about Mac, but you get the idea), and the rest would just work. Juca, I think the autoupdate option is a good second step, but lets take first steps first.
This is something I've thought about as well ever since we first implemented extensions. However, lately I've changed my mind. On most operating systems there are already good systems for deploying packages and automatic package updates to users (synaptic on Ubuntu, for instance), so we'd be putting a lot of effort into essentially reinventing an existing wheel, for just a few differences in capability.
As a counter to Firefox's admittedly sexy plugin system, consider that the vast majority of successful open source projects who *don't* implement their own unique package delivery systems, and just rely on the OS to do it, as is proper.
As I mentioned, this would allow a leg-up for would be developers. People who don't have a clue how to program C/C++ let alone use SVN/CVS or Docbook could be given another way in. Heck, some people who can't even write scripts could package existing scripts.
Perhaps, but I think the quality of contribution from people with no knowledge of these fundamental technologies would by definition be lower, and I don't think the quantity of such contributions would necessarily be that much less either.
I am a huge champion of getting more people involved in contributing to open source, and I know that removing barriers preventing them from contributing is a wise move. However we need to take care that we're not solving it simply by giving people crutches. I would argue that the time and energy that would be required for us to implement an Inkscape-specific extensions management system would be better invested in teaching and writing docs to help the people who don't know C, SVN, DocBook, etc. to be conversant in them. Someone who will be able to contribute good extensions would most likely have the technical aptitude to learn these skills to the levels needed within a few afternoons; further, these are good skills to have in the larger realm of open source, enabling that person to contribute much more widely.
In the open source world, barriers to entry just discourage contributors. Yes, the Contributor/User ration is low, but surely some of that comes down to making it easy to get in.
There's truth to this, although I suspect a number of the barriers are more sociological (like not feeling they *can* contribute, not having easy access to training materials, etc.)
Bryce