Not signed in (Sign In)

Categories

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

Help keep Vanilla free:
Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.

Add-ons: [Sticky] Open Sourcing our Add-Ons

Bottom of Page

1 to 43 of 43

  1.  
    • CommentAuthorDavidK
    • CommentTimeNov 16th 2007
     # 1
    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?
    •  
      CommentAuthorDinoboff
    • CommentTimeNov 16th 2007 edited
     # 2
    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.
    •  
      CommentAuthorTiggr
    • CommentTimeNov 16th 2007
     # 3
    Great ideas! :-) It would be worth the effort!

    Tiggr
    •  
      CommentAuthormattucf
    • CommentTimeNov 16th 2007
     # 4
    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.
    •  
      CommentAuthorWallPhone
    • CommentTimeNov 16th 2007
     # 5
    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/
  6.  # 6
    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
    •  
      CommentAuthorDinoboff
    • CommentTimeNov 16th 2007 edited
     # 7
    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.
  8.  # 8
    then their should be one Vanilla extensions project with each extension as a sub project
  9.  # 9
    Agreed.
    •  
      CommentAuthorjimw
    • CommentTimeNov 17th 2007
     # 10
    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.
  11.  # 11
    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
  12.  # 12
    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.
    •  
      CommentAuthorDinoboff
    • CommentTimeNov 17th 2007 edited
     # 13
    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.
  14.  # 14
    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.
    •  
      CommentAuthorDinoboff
    • CommentTimeNov 17th 2007 edited
     # 15
    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.
  16.  # 16
    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
    •  
      CommentAuthorDinoboff
    • CommentTimeNov 17th 2007
     # 17
    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.
    •  
      CommentAuthorMax_B
    • CommentTimeNov 17th 2007
     # 18
    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.
    •  
      CommentAuthormattucf
    • CommentTimeNov 21st 2007 edited
     # 19
    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.)
    •  
      CommentAuthorDinoboff
    • CommentTimeNov 21st 2007 edited
     # 20
    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.
  21.  # 21
    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
    •  
      CommentAuthorklip
    • CommentTimeNov 30th 2007
     # 22
    well, I'm little bit scared of anybody making changes in "my" add-ons.
    Everybody can whenever contact me with a patch or anything and if I don't agree adding it to the code, everybody can make another add-on based on my latest version. Though I don't know how does user system on Google Code work.
    Anyway I feel much better using my own subversion repositories than third-party's one.

    So at the moment I use my own repositories which have also anonymous read-only access:
    svn://tomas.klapka.cz/var/svn-repos/vanilla/extensions/FixLanguageDefinitions/
    svn://tomas.klapka.cz/var/svn-repos/vanilla/extensions/ExtensionLanguageLoader/
    svn://tomas.klapka.cz/var/svn-repos/vanilla/languages/Cestina (not yet released complete czech dictionary definitions)


    also I guess it is possible to use subversion externals to link subversion repositories so it is at least checkoutable/updatable


    @MySchizoBuddy: svn implementations in IDEs are often buggy, I recommend using svn in a command line or to use TortoiseSVN (only on windows).
  23.  # 23
    klip the idea to have all of them in one place. not hundred different ones.
    although your more than welcome to use your own svn
  24.  # 24
    How to upload files to Google code using TortoiseSVN
    http://code.google.com/apis/gadgets/docs/tools.html
  25.  # 25
    instead of /trunk use /extensions like below
    svn checkout https://vanilla-friends.googlecode.com/svn/extensions/ vanilla-friends --username myschizobuddy
  26.  # 26
    dinoboof would u mind if i change the directory structure
    the current one is nonstandard, i cannot checkout trunks of extensions in one command i have to do that manually for each extension
    •  
      CommentAuthorDinoboff
    • CommentTimeDec 3rd 2007
     # 27
    I set it like that so that each extension is independent from each other, so that each extension has its own branches and tags.

    What structure could we use?
  28.  # 28
    default one
    /trunk/extensionName/
    /branches/extensionName/
    etc
    •  
      CommentAuthorklip
    • CommentTimeDec 3rd 2007
     # 29
    maybe you can make a project containing "all extensions" by linking them to the same svn server but different repository folder by svn externals.
    This reminds me I wanna try it, but I'm too tired right now. 1:20AM here.
    •  
      CommentAuthorDinoboff
    • CommentTimeDec 3rd 2007 edited
     # 30
    @myschizobudy: ok. jQuery seems to do that.

    Add the trunk, branches and tag folders and put your extensions there, I will put mine when I have some time for.

    Leave the vendor and wiki folder, and leave the extension folder for now.

    About the comments... Try to always add a comment to your commit. If it's about an extension, start the comment with "MyExtension: blah blah..."
  31.  # 31
    i spend the whole day and all i could do was add a empty folder.
    svn on mac seem to suck really bad. i cannot understand how to use them.
    gonna fire up windows and hopefully i'll be able to put my extensions on google code
    •  
      CommentAuthorklip
    • CommentTimeDec 4th 2007
     # 32
    so finally I found some time and tried svn externals and it works just nice, though I haven't tested commit changes in code of fetched parts, but I think everybody can use direct repository if needs to do changes there, if externals is not working.

    so I have different repository for each of my projects:
    svn://tomas.klapka.cz/vanilla/extensions/FixLanguageDefinitions/
    svn://tomas.klapka.cz/vanilla/extensions/ExtensionLanguageLoader/
    svn://tomas.klapka.cz/vanilla/languages/Cestina    and I need one repository where is all of it and maybe also some other extensions not from me.

    so I followed this article

    I created empty repository svn://tomas.klapka.cz/vanilla_resources/ with trunk in it (svn://tomas.klapka.cz/vanilla_resources/trunk)
    then checkouted it somewhere:svn co svn://tomas.klapka.cz/vanilla_resources/trunk ./vanilla_resources_from_klipthen I run svn propedit:
    svn propedit svn:externals ./vanilla_resources_from_klip
    Now it opened a system editor with empty file so I filled it by this content:
    languages/Cestina svn://tomas.klapka.cz/vanilla/languages/Cestina/trunk
    extensions/FixLanguageDefinitions svn://tomas.klapka.cz/vanilla/extensions/FixLanguageDefinitions/trunk
    extensions/ExtensionLanguageLoader svn://tomas.klapka.cz/vanilla/extensions/ExtensionLanguageLoader/trunk
    Then you have to cd ./vanilla_resources_from_klip
    svn update     and it should fetch/checkout all repositories you set as external. Now you only svn commit -m "Added externals for my czech language add-on 'Cestina', and extensions FixLanguageDefinitions and ExtensionLanguageLoader"
    and that's it. so if I want to fetch all my stuff now, I just do:
    svn co svn://tomas.klapka.cz/vanilla_resources/trunk ./vanilla_resources_from_klip
    •  
      CommentAuthorMax_B
    • CommentTimeDec 4th 2007
     # 33
    BTW, the "trunk/branches" scheme is not mandatory at all. SVN is just a directory tree. You can do it as it fit best your need.
  34.  # 34
    yeah just that every one does it this way, the documentation on google code all assume trunk, that was my first stumble block, i kept looking for trunk but it wasn't there
  35.  # 35
    apparently tortoiseSVN is able to detect the directory names. As I was committing the /tags directory it gave me a warning that I should first switch to the /branches or /trunk , and asked me to confirm that i want to commit the tags directory anyway. So apparently the names are sort of important
    •  
      CommentAuthorDinoboff
    • CommentTimeDec 5th 2007 edited
     # 36
    It would have warm as well if you have tried to commit to /path/to/something/tag/something
    •  
      CommentAuthorTomTester
    • CommentTimeDec 5th 2007 edited
     # 37
    Note:
    After some bad experiences with Tortoise (slowwww PC) I'm quite pleased with RapidSVN.
    Check it out and see if it works for you: http://www.rapidsvn.org/
    • CommentAuthormxsquare
    • CommentTimeDec 7th 2007
     # 38
    Are all the add-ons for vanilla open source? Can they be used as part of a commercial site or product offering?
  39.  # 39
    they are all GPL as far as I know. If you use it for commercial site and you amke changes to the code, you have to give the changes back to us.
    •  
      CommentAuthorDinoboff
    • CommentTimeDec 7th 2007
     # 40
    Not exactly.

    You can do what ever you what want with them on your site, commercial or not. But if you are distributing a product using them, you have to use the same licence.
    •  
      CommentAuthorDinoboff
    • CommentTimeDec 7th 2007 edited
     # 41
    Also, you should ask the author how does he want to licence his add-on if he didn't state it.

    The ones in the Vanilla-friends repository are GPL v2; and if you put your add-on in it you should check everything is compatible with GPL. BSD-like licences are compatible.
    • CommentAuthormxsquare
    • CommentTimeDec 7th 2007
     # 42
    Thanks for the info guys. That was really helpful!
  43.  # 43
    ok i messed it up can someone fix the structure.
    right now its like this /trunk/Blog/src/default.php
    I want the src directory to be removed and the structure be /trunk/Blog/default.php

1 to 43 of 43

  1.  
Add your comments
    Username Password
  • Format comments as
 
Back to Discussions Top of Page