I've been kicking this idea around since the last release, and would like to put it out for discussion for us to do in 0.47...
Extensions have proven to be a great way for people to contribute new ideas to the project, but unfortunately the maturity, quality, and maintenance put into the extensions can vary quite a bit. Unfortunately, a consequence is that they complicate our core Inkscape codebase releases.
* Old extensions sometimes break, but their original developers aren't available to fix them. It's a regression, but is it important enough to block the release?
* Extensions are quick to write, yet having to wait a full Inkscape development cycle to get them formally distributed to users seems rather excessive.
* While extensions won't make Inkscape crash, they certainly can have serious bugs, but it's currently hard to roll fixes out to users. We wouldn't roll a new point-release of inkscape just to fix extension bugs.
It seems that a logical solution would be to establish an inkscape extensions package separate from the Inkscape core, that could be released with more or less frequency, as appropriate.
Along with that would be an 'unstable' extension package, that would contain scripts not as ready.
I think our existing release processes could handle this additional package; it'd just be one additional piece to rev and upload. However, I would love to see a new team of extension writers form around this and take ownership of maintaining it and producing releases as appropriate (and hopefully more frequently than the core codebase).
Let me know your thoughts.
Bryce
Bryce Harrington-3 wrote:
Let me know your thoughts.
This sounds like a terrific idea for incrementally improving functionality, much like Open Office, Joomla, or Firefox. It's also a leg up for would be developers.
Why make a collected package of extensions, when you could go the whole hog and let people update extensions individually on a special extensions repository page, marking which release it is compatible with?
Rygle
On 2008-February-24 , at 09:17 , Bryce Harrington wrote:
[...] I think our existing release processes could handle this additional package; it'd just be one additional piece to rev and upload. However, I would love to see a new team of extension writers form around this and take ownership of maintaining it and producing releases as appropriate (and hopefully more frequently than the core codebase).
Let me know your thoughts.
I'm not sure how relevant all this would be but here is my opinion.
I think that extensions (both effects and import/export filters) but also palettes, gradients and patterns, are things that are really meant to be handled by the "broader" Inkscape community (i.e. not necessarily people with commit rights to an SVN repository, be it Inkscape's or a specific extensions one).
At the same time, I am under the impression that this community is quite scattered presently, both regarding support, potential contributions or showcases of the project. To get support there are several mailing lists, a handful of forums, the answers site and I am probably forgetting some possibilities. To showcase artwork and potential howtos there are the Inkscape group on Deviant Art, the new inkscape gallery and various others, the terrific screencasting and tutorials sites, and eventually there are several people just posting stuff on their blogs. Contributing to some of those is somehow limited in that you would have to contact the site administrators to get posting rights before doing anything. And, I don't want to presume anything, but if I were them I would probably tell you to post your tutorial somewhere on the web and so that I link to it afterwards. To contribute things to Inkscape itself, there isn't much possibility other than writing an email to the devel list and waiting for someone to pick it up and potentially commit it.
All this scatter and otherwise lack of functionality has, I think, one main cause: Inkscape's current website is not dynamic enough. If there was a forum on the site, people wouldn't have started one, if there was a place to post stuff, people would have started posting tutorials, extensions or quick tips to it. There's nothing wrong with these sites currently (they are of great quality), apart from the fact that their scatter tends to disperse attention. For example, I, for one, would really like to follow what happens in the forum(s) or check if I can help on the answers site. But it would require to log into several different places, identify new things each time, and potentially re-read the same stuff several times... so I just don't and mostly limit myself to reading the mailing lists.
So I think there are two potential next actions on this:
1- Provide a way to *aggregate* the existing information on Inkscape's main website. There is no point in undermining the efforts of the great people that have set these sites up and to recreate the same thing on Inkscape's website. However, it would be great to have *one* place where you can quickly skim through what's new in all these locations and identify posts that are interesting (to you), even if to answer you have to be directed somewhere else (in an ideal world there would be a common posting interface with potential access in a browser and by email but that's probably not going to happen ;) ). You can think of it as a kind of a planet-Inkscape for forums, mailing lists, galleries, and tutorial/screencasting sites. For those concerned about the potential high activity in such a place, I am following some mailing lists which are far busier than inkscape- devel and find that it does not demand more time: skipping stuff is easy and by having a broader content to start with, you end up focusing more on those posts that really interest you or where you are particularly competent. It is win-win for everyone. Eventually, such a gathering point would be a good place to direct users to the right service: if you have a usage question please post it to the answers site, if you detected a reproducible bug please submit it to launchpad, if you want to discuss a new feature please use the mailing list, if you want to post artwork go there, to just chat with friendly Inkscape users go here, etc. This would avoid duplication and give more focus to each of the resources Inkscape currently generates.
2- Provide a new place for people to post content (or turn one of the current services in one). Something where one can just log in and post an extension (<- see, this is where I come back to the actual subject of the post!), a new palette/pattern, a new SVG tutorial, a file template, an xml keys file, etc. for other to download. Those kind of content that are not yet posted somewhere else. To avoid this becoming a inextricable mess with time, simple posting rules should be enforced and a rating system used, to leverage the 'wisdom of the crowds' in the very trendy web 2.0 way (hell, shouldn't we be talking of web 3.0 by now?). ccHost seems like a good base for such a system but there may be other solutions too. On the desktop side of things, this would be accompanied (in the same ideal world as before ;) ) by simple installers which can handle the various forms of content and put them where Inkscape can see them (e.g. opening a gpl palette with Inkscape would do the right thing and move it in the palettes directory). This would allow Inkscape to evolve continuously between releases. Come release time, the best of these new items can be cherry picked and more thoroughly supported (translated etc.) before inclusion in the release. Having those items already available online would also put less pressure on including them with Inkscape. I think many extensions/templates/examples currently included with Inkscape are fairly specific and would have been better suited in a place like this.
I think both these points would make good SoC projects, and would fit with Bryce ideas about SoC 2008: they won't be interacting with Inkscape's code directly but would be valuable to the project and the student. Ok, here it is, let me know what you think.
JiHO --- http://jo.irisson.free.fr/
As a user and lurker, can I make a suggestion?
I'd like to see an "extensions Gallery" that is handled in a similar way to Firefox or Joomla!.
Let anyone contribute, but have some light-touch "policy/quality" control within the Inkscape devs.
The Joomla! extension library has a couple of nice features where users comment on their experiences and can rate extensions too. It then becomes almost self-policing. The good extensions rise to the top and the trash sinks...
Hope this helps and is not impertinent. Just my thoughts.
Inkscape is a great tool. Thanks to all involved.
Alan
it would also be cool to have an extensions dialog similar to firefox one that sends you to the extensions gallery, so that you can pick one and install it.
If you could see extensions descriptions from within inkscape and request install without having to open a webbrowser it would be even better. It could be similar to the ocal import dialog.
Juca
...also, firefox checks for extension updates on startup, so you can easily follow all your extensions new releases.
Juca
Has anyone seen the new gimp plugin registry? They have just moved to a new structure for much the same reasons being discussed here.
-Rob A.
On 2/24/08, Felipe Sanches <felipe.sanches@...400...> wrote:
...also, firefox checks for extension updates on startup, so you can easily follow all your extensions new releases.
Juca
I agree with all the above.
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 am essentially treating them like a forum via nabble. Something on the Inkscape site would be excellent!
The wiki does provide some means of input, but it's very limited to the pre-existing structure (or lack of). 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?
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.
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.
When I studied marketing, there was a lot of talk about barriers to entry. Companies like M$ often use barriers to entry (like file formats) to further a monopoly position, but are now learning the hard way that barriers to entry lead to trouble. 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.
Lets take down the barriers to entry for Inkscape. One login for http://forum.inkscape.org forum , http://wiki.inkscape.org wiki and http://extensions.inkscape.org extensions . One central website that aggregates content that's out there, but that also attracts people to put their content on it in preference to starting their own blog. One click extension installation.
Rygle.
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
On 2008-February-25 , at 01:23 , Bryce Harrington wrote:
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.
I think I disagree with you in this. What software does rely on packaging systems alone for its add-ons? The software which I know to do this on linux (python, perl, R) all have an internal package system that works just as well. Those deb/rpm packages are for convenience only, because indeed packaging systems are convenient (oh dear how much do I miss apt-get update!). Some other programs are split in several packages on linux (main program+language packs comes to mind) but are just bundled a single big one on other platforms (this is what we don't want to do anymore). The only projects I see which are largely modular and which rely entirely on the packaging system for it are X and the linux desktops (KDE, Gnome, etc).
Overall this highlights nicely one important point: how valuable is the cross platform aspect of Inkscape to the project? If "cross platformness" is a priority, then Inkscape should deal with its own add-ons itself, so that it does the same thing on all platforms (and documentation can be consistent, etc.). You can remark that the exceptions I cited above are X based OSes only, and IMHO they can be exceptions because of this: because all these OSes have packaging systems they can rely upon. (Based on the reading of your blog I think I know your personal opinion about this. I understand it and agree with you, but well, those MacBooks are so nice you know ;) )
My second point is that there is no need to make this thing fancy, it should just be "download and double click to install". Items can be downloaded from an online repository with a browser (that what they are for after all, no need to reinvent that). Opening the downloaded item with Inkscape would just copy it to the appropriate directory. Implementation may be simple too. I think Inkscape already has environment variables pointing to these location (e.g. ~/.inkscape/ templates, palettes etc. on linux). If it does not... well it should (and it'd make my life much easier for some OS X integration I'm planning :P) and it probably won't be hard. Provided the extensions are aware of the environment variables (which I think they already are) this could be done with input extensions and simple shell scripts. Like: <inkscape-extension> <_name>Gimp Palette Input</_name> <id>org.inkscape.input.gpl</id> <dependency type="executable" location="extensions">gpl_input.sh</ dependency> <input> <extension>.gpl</extension> <mimetype>text/gimp palette</mimetype> <_filetypename>Gimp Palette (*.gpl)</_filetypename> <_filetypetooltip>Gimp Palette</_filetypetooltip> </input> <script> <command reldir="path">gpl_input.sh</command> </script> </inkscape-extension> and #! /bin/sh rc=0 cp -f $1 $INKSCAPESHAREDIR/palettes/ || rc=1 exit $rc
There are probably some things wrong with the code above but you get the idea. Some file extensions may need to be tweaked a bit to ease recognition by Inkscape (such as the .xml keys or .zip extension packages) but other than that it seems straightforward (well... *seems* ;) ).
As for he updating process, I am not sure how useful this would be. One would get updated core extensions with each release of Inkscape. How frequently would an extension be updated in this lag of time? The real bonus of having extensions separate from the main code is, IMHO, to get new _functionality_ between the releases, not really to get more frequent updates. As for non core extension, getting new versions when they break should not be that hard. At least I don't think this is particularly needed at first.
Eventually, one argument against an extensions package is that it does not allow to choose among the extensions. The goal is to have a large number of extensions in the end, and I would not want the additional clutter (in the UI I mean) caused by many things I won't use (or if I should have everything, I might as well have both Inkscape and the extensions in one package). Inkscape extensions are typically small so they cannot be shipped each in their own package. Overall, I think extensions will be too numerous to be shipped in one package and too small to be worth packaging each independently.
OK, now I'm going to bed.
JiHO --- http://jo.irisson.free.fr/
On Sun, Feb 24, 2008 at 11:35 AM, Mihaela <myhaella5@...529...> wrote:
jiho wrote: 1- Provide a way to *aggregate* the existing information on Inkscape's main website. I was surprised that Inkscape website didn't have a forum, it felt like something really essential was missing.
I think I proposed this already - why don't we link www.inkscapeforum.com from the front page?
On 2008-February-25 , at 00:39 , bulia byak wrote:
On Sun, Feb 24, 2008 at 11:35 AM, Mihaela <myhaella5@...529...> wrote:
jiho wrote: 1- Provide a way to *aggregate* the existing information on Inkscape's main website. I was surprised that Inkscape website didn't have a forum, it felt like something really essential was missing.
I think I proposed this already - why don't we link www.inkscapeforum.com from the front page?
We do actually ;)
What I am thinking/dreaming of is an online app resembling GMail with a compact list gathering of all the new messages/entries from several places, with small snippets of what's inside the entry and clear labels (this comes from Inkscape-user mailing list, this comes from the forum, this is a tutorial etc.). Somewhere one can skim through all the latest news, read them or get a preview and quickly decide where to go next.
I would personally like it to fetch: - posts to inkscape-users http://dir.gmane.org/gmane.comp.graphics.inkscape.user or nabble or... - new entires in the Answers and Blueprint sections of launchpad https://answers.launchpad.net/inkscape/ https://blueprints.launchpad.net/inkscape/ - messages in inkscape forum http://www.inkscapeforum.com/ - links to/rss feeds of inkscape tutorials and screencasting posts http://screencasters.heathenx.org http://inkscapetutorials.wordpress.com/ - new entries in a putative extensions/palettes/gradient section of the website - new items from the dedicated section of Deviant Art http://inkscape.deviantart.com - new items in Inkscape Gallery http://www.inkscapegallery.net/en/splash
And possible include: - inkscape devel - bug reports - ... for more developer oriented minds. But I those can already be consolidated using an email client so it may not be primarily useful.
I may start a Blueprint when I get a chance. If someone feels like he/ she wants to start it first, please do, I'll just add my thoughts afterwards.
JiHO --- http://jo.irisson.free.fr/
Serve that all up via a single RSS feed and I think you have a winner!
-Rob A>
I would personally like it to fetch:
- posts to inkscape-users http://dir.gmane.org/gmane.comp.graphics.inkscape.user or nabble or...
- new entires in the Answers and Blueprint sections of launchpad https://answers.launchpad.net/inkscape/ https://blueprints.launchpad.net/inkscape/
- messages in inkscape forum http://www.inkscapeforum.com/
- links to/rss feeds of inkscape tutorials and screencasting posts http://screencasters.heathenx.org http://inkscapetutorials.wordpress.com/
- new entries in a putative extensions/palettes/gradient section of
the website
- new items from the dedicated section of Deviant Art http://inkscape.deviantart.com
- new items in Inkscape Gallery http://www.inkscapegallery.net/en/splash
And possible include:
- inkscape devel
- bug reports
- ...
for more developer oriented minds. But I those can already be consolidated using an email client so it may not be primarily useful.
I may start a Blueprint when I get a chance. If someone feels like he/ she wants to start it first, please do, I'll just add my thoughts afterwards.
JiHO
On Mon, Feb 25, 2008 at 3:27 AM, jiho wrote:
I would personally like it to fetch:
- new entires in the Answers and Blueprint sections of launchpad
That's a good point. We need to at least link to them from main page. On my short-term todo list now :)
Alexandre
On Sun, Feb 24, 2008 at 01:47:42PM +0100, jiho wrote:
On 2008-February-24 , at 09:17 , Bryce Harrington wrote:
[...] I think our existing release processes could handle this additional package; it'd just be one additional piece to rev and upload. However, I would love to see a new team of extension writers form around this and take ownership of maintaining it and producing releases as appropriate (and hopefully more frequently than the core codebase).
Let me know your thoughts.
I think that extensions (both effects and import/export filters) but also palettes, gradients and patterns, are things that are really meant to be handled by the "broader" Inkscape community (i.e. not necessarily people with commit rights to an SVN repository, be it Inkscape's or a specific extensions one).
I'd agree. When we started OCAL it was with a hope that it would service this side of the community, and to a degree I believe it has. I hope that as the OCAL import/export functionality matures, it will play a big role in this.
I'd like to see more progress towards this goal of making community contributions more seamless and distributed during 0.47, however the quantity of infrastructural work needed to support this would be too much for a single release. Hopefully the codebase refactoring work, and the website rework, will provide a better underlying platform to build these sorts of things on in the future.
At the same time, I am under the impression that this community is quite scattered presently, both regarding support, potential contributions or showcases of the project. All this scatter and otherwise lack of functionality has, I think, one main cause: Inkscape's current website is not dynamic enough.
Right, so this dips over a bit more into the website restructuring I mentioned a few weeks ago. Once the 0.46 release is out the door there should be more time to focus on it. I'm trying to keep our goals with it modest and achievable, but am hoping once we have Drupal in place, other volunteers can more easily run with ideas for adding more dynamic capabilities to it.
So I think there are two potential next actions on this:
1- Provide a way to *aggregate* the existing information on Inkscape's main website.
2- Provide a new place for people to post content (or turn one of the current services in one). Something where one can just log in and post an extension (<- see, this is where I come back to the actual subject of the post!), a new palette/pattern, a new SVG tutorial, a file template, an xml keys file, etc. for other to download.
I think both these points would make good SoC projects, and would fit with Bryce ideas about SoC 2008: they won't be interacting with Inkscape's code directly but would be valuable to the project and the student. Ok, here it is, let me know what you think.
I think it's a very good idea for Drupal customization for community collaboration. If we have something defined enough for a student, and have someone (maybe you?) willing to mentor a project or two, it sounds feasible. I'd encourage you to flesh out the concepts in a blueprint, for people to collaborate on ideas; sounds like several people have similar desires in mind and it'd be nice to get them fleshed out in a more detailed fashion.
Bryce
participants (9)
-
Alan Lord -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Felipe Sanches -
jiho -
Mihaela -
Rob Antonishen -
rygle