Open Sourcing our Add-Ons

DavidK

I've made a couple of add-ons. A few that I haven't released, a few that I have. When I make add-ons I get them working on my site. Package them up basically and upload them. Sometimes I think the deployment and support or hard-coded stuff I've put in makes the deployment a pain in the arse. Other times I look at other people's neglected and out-of-date add-ons and think how they've already done 90% of the work and I'd be happy to provide the last 10% making the add-on fit my requirements. All of this makes me think: 1) My add-ons would benefit from allowing other people to improve and bug-fix them. 2) Add-ons that others have created could be improved or made more adaptable with the help of others. 3) Any security hole found in someone else's add-on can be fixed by the community. Not to speak of the possibility of being able to apply things like the low-cal extension logic to add-ons that don't support it. I think this is all a good idea, and basically leads to the notion that add-ons could be open sourced under the same GPL license that Vanilla is released under. So I'm thinking, how could this come about, and what's the best way to save neglected add-ons from becoming unsupported? If add-ons also included a URL to a subversion repository then cool, we can get to the code and make changes that others benefit from. But that is dependent on having access to the SVN and if it's neglected the author may no longer be in touch with SourceForge or whoever to grant access. And this has lead me to think... what about having one project that creates Vanilla extensions in Source Forge. The equivalent of PEAR for Vanilla. With lots of extensions in that one place and many developers being able to add their add-ons, quality control/refactor other extensions, etc. Basically I think the idea is pretty sound. And I'm interested in what other extension authors think. Further, I'm willing to GPL all of my add-ons and release the few that I haven't released to help get the ball rolling. I'm even willing to re-write some of the deprecated add-ons to provide energy to the whole thing (such as a decent paginated members page that is light on SQL queries). Anyone think this idea worth pursuing?

Dinoboff

I like the idea. I create the project on google code earlier for that but i didn't have time to work it. I just have 2 extensions (plus one on hold). http://code.google.com/p/vanilla-friends/ Anybody with an extension on the Vanilla repository is welcome to join. I also try to rewrite my earlier extensions and add them to it when I will have some time for it.

Tiggr

Great ideas! :-) It would be worth the effort!

Tiggr

mattucf

My "Auto Hide" add-on is already GPL >= V2 licensed, so if I disappeared off the face of the earth anyone could fix it up. The google project idea is a good one, though, so I'll look into putting mine up there when I have some free time. :-)

Only thing I would stress is the importance of not stepping on each others' toes. The add-on creator should have some amount of time to respond to an issue before anyone else jumps in and takes care of it.

WallPhone

I'll jump on this bandwagon. Like Dinoboff, I have a Google code page that will serve as a repository of my add-ons: http://code.google.com/p/wallphone-vanilla/

MySchizoBuddy

why can't we have these repositories here on lussumo. create a SVN for extensions and let users check in/out code. Mark shouldn't allow everyone access to the vanilla svn, but the extensions svn would be great

Dinoboff

That would be more work for Mark.

It would be easier to manage something like that on google code; it's google's server, you have has many project owners as you want to manage it. jQuery code is hosted on google-code with some of its addons.

I tried to join WallPhone project, and see that the join project link doesn't allow to request to join. If you want to join my project, leave me a whisper with your google account email.

MySchizoBuddy

then their should be one Vanilla extensions project with each extension as a sub project

Minisweeper

Agreed.

jimw

I think that this should be kept here, too. Also, concerning GPL isn't the add-ons code automatically under that licensing? Or do we have to add some text stating that explicitly?

I have no problem with anyone taking my add-ons and making them better. That is what a community is all about. I am no expert in php or javascript and would appreciate code-review by others. Each one of us has knowledge from our experience that can improve others work.

MySchizoBuddy

it says 2.6MB of 100MB used up.
that sucks. only 100Mb storage, is this total storage of all revisions of svn or just the current revision
Should vanilla extension be a dummy wrapper linking to all the other extensions.
I don't like extensions per user way. I can see wallphone has created a project under his name and have files for extensions. It should be just the extension, you can look at all your projects by clicking on your username, but don't compile files under a username

Minisweeper

If anyone wants to put any of my addons on whichever svn you end up using you're more than welcome. I'm also quite happy to upload any new versions of any addons which the svn community comes up with to the addons site.

Dinoboff

For the size, there is 2 unusually big extensions (openid and Low-Cal Vanilla) If the size become a problem, google might be able to upgrade it on request or we could also move the svn somewhere else.

MySchizoBuddy

so for the other question, Should the Vanilla-friends project have links to extension projects like (lowcal vanilla), but <u>not</u> actually host it. Low cal vanilla should be hosted as its own project. If you host all extensions in the Vanilla-friends project that will surely mess up the tags.

Dinoboff

On http://vanilla-friends.googlecode.com/svn/ there is no trunk, tag or branches folder. Each extension has its own folder in http://vanilla-friends.googlecode.com/svn/extensions/ and each extension author organise its extensions like he wants to.

MySchizoBuddy

but the front page does have tags, thats how you search for projects via tags. so searching for fckeditor will pull up this huge extensions project when your only looking for just one extension. the issue tracker will get huge as well and hard to manage

Dinoboff

An extension can have its own project so its searchable without being a mess of tags. But there is much interest to link it back to Vanilla-friends' svn. To contribute to its code, developers will have to join its project; they won't be able to edit the code with their permission on Vanilla-friends.

Max_B

I'll join the "vanilla friends" google project next time I'll have to work on Vanilla/extensions. In the meantime, anyone can feel free to add my extensions there if useful.

mattucf

Also, concerning GPL isn't the add-ons code automatically under that licensing?

Actually, you can release modifications or patches under any license you want; however, if you distribute a modified version of the original software (or the software and an extension bundled together), the modifications have to be licensed under the GPL as well.

At least that's my understanding, but IANAL.


------------

Dinoboff, could you give a step-by-step for how authors should join up? It sounds like you're saying to start a project for each extension but use the vanilla-friends svn; how does that work? (I am not very familiar with google code.)

Dinoboff

You just need to give me your email and I will add you to the member list. you will have access then to to the svn. You can create you extension there: http://vanilla-friends.googlecode.com/svn/extensions/. Each extension should have its own folder there.

MySchizoBuddy

how do i use svn in kimodo. IDE
i given it the path to where svn is, now what do i do next to upload the extension to google code