PDA

View Full Version : RO SVN Access -- I beg you!



dh_swing
8 Feb 2007, 9:34 AM
Great things happening here to be sure...

Jack - what would it take to have you guys make the development branch available on the web?

Is there a reason you are holding back this branch? The advantages of being able to maintain compatability with the breaking changes, experiment with sandboxed code, and provide valuable feedback to on-going initiatives would be huge.

Is this a bandwith issue? If so -- I'm sure there is a willing group ready to assist (myself included).

Thanks again for the work being done here.

Regards,

_Terry

jason
8 Feb 2007, 12:51 PM
i would 2nd that - it would be great to get some type of access. at the moment i'm not using any of the controls, grid, etc because i'm worried that my apps will be forever stuck on an ancient version of the libs. if you could do a branch in subversion, that is really the "industry standard" way to move forward with a new codebase. then theoretically you can still do bug fixes on the old branch at the same time you are working on the new one.

obviously we are all grateful for the work you are doing, though, i hope it doesn't sound like complaining. just chomping at the bit to get at your new code!

brian.moeskau
8 Feb 2007, 1:26 PM
I believe that the main thing holding Jack back from doing something like that is that he's not much of an SVN expert. Maybe someone with experience admin'ing SVN projects can provide some more detailed guidance on the best way to get things set up for everyone's benefit.

jason
8 Feb 2007, 2:05 PM
definitely understandable - svn is there to help and you don't want to spend all your time fiddling with the version control system vs writing code ;-) alternatively you can just put up a separate repository altogether for "experiemental" code. branching gives you some side benifits if you're still working on the old branch as well.

if you use tortoisSVN, branching and merging aren't that bad:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html

dh_swing
8 Feb 2007, 3:39 PM
Agreed that TortoiseSVN (http://tortoisesvn.tigris.org) is an awesome client extension for subversion.

While not strictly along the lines of their mission statement, I'm willing to bet that Tigris (http://www.tigris.org) would love to host this project. Registration looks easy, and all the tools you need to successfully run this project from a subversion repository are right there.

Thoughts?

_Terry

Herm
8 Feb 2007, 4:24 PM
...I'm willing to bet that Tigris (http://www.tigris.org) would love to host this project...
It's actually already hosted on Google's project hosting. Details: http://www.yui-ext.com/manual/svn .

dh_swing
8 Feb 2007, 6:26 PM
Herm,

I realize there is an existing repository; I guess my hope is for a more formalized development process that would result in a steady stream of commits vs once a month mega commits. This should be pretty easy by simply tagging minor revisions and branching when you want to sandbox. This way, all interested parties can follow the flow of the development process -- which is valuable.

The Tigris site offers the kind of framework that can help foster a project like this.

Thanks,

_Terry

tryanDLS
8 Feb 2007, 7:43 PM
Herm,

I realize there is an existing repository; I guess my hope is for a more formalized development process that would result in a steady stream of commits vs once a month mega commits. This should be pretty easy by simply tagging minor revisions and branching when you want to sandbox. This way, all interested parties can follow the flow of the development process -- which is valuable.

The Tigris site offers the kind of framework that can help foster a project like this.


I think that for some projects, the concept you're discussing works well. However, one of the biggest challenges faced here is support for inexperienced developers. The fact is that a lot of users here have difficulty working with code that a) isn't fully documented or b) doesn't include fully functional examples. The cut and paste mentality of old school web development is still very prevalent. Releasing code on more frequent basis would exacerbate this problem, and make support even harder since determining what version of components someone is using would be difficult. We see this problem already with people who see that they can access the latest code from SVN, but then have difficulty.

It should also be noted that it's been less than two months since the last release and the code base is currently undergoing a majar refactor. While it would nice if it could be done incrementally and released to the community, the fact is that work is being done at the lowest levels of the framework and it's not necessarily possible to do it peacemeal.

Unfortunately, this project isn't operating, nor funded like the Mozilla Foundation. Jack's not getting paid other than the occasional contribution, and the mods and others that provide support here are completely uncompensated.

jason
8 Feb 2007, 10:43 PM
hey tryanDLS,

i pretty much agree with everything you said as far as complexity and having people testing the code before it's even finalized. it is why groups have formal develoment practices, though there's no question they make things tedious sometimes. and with nobody really getting paid, you can't really demand anything of anyone!

I think i still would say that branching - iwhat jack is doing right now - a major refactor - is textbook for a branch. even if he gives nobody access to the branch, it would at least give him some version control over his current work. I don't know about you guys but i get paranoid if i go too far on any code without committing once in a while.

i hope that this is coming across as a helpful suggestion and not just me being annoying!

jack.slocum
9 Feb 2007, 3:28 AM
There are a variety of things holding me back from making a commit. It started primarily because the grid was screwed and I didn't want to break anyones code. Next is the fact that there are now quite a few api changes that will need formal documentation (upgrade path) and I don't want to be answering questions about that while trying to hit my 15th deadline (my personal deadline for beta 1).

Now a new thing has been added and that is the possiblity of a commercial license option, or a support license or something (I still haven't centered on any particular path yet), but something where I am able to earn some kind of income. The sad fact is right now my income is less than the guy serving at McDonalds and I don't know how long I can survive with 2 kids in diapers and a pregnant wife on that kind of income ;). Other options I am considering are some kind of fund-raiser or a new "donate for specific features" page where top donations = top priority. For the people who have made donations, I appreciate it very much.

mdissel
9 Feb 2007, 4:23 AM
I've got no problem at all with a commercial license for a nice price and i suspect that more people think this way :wink:

If that's what holding up your svn commit, don't think any longer and create a page where we can place the order for a commercial license.. :D

Thanks

Marco

KimH
9 Feb 2007, 4:29 AM
Do you have a new "deadline" for the 1.0 beta that you can and will share with the rest of us? We're having customers asking us when this new API will be released and we'd love to be able to say just "well... on monday" or "in two weeks" or "no later than christmas 2012" :lol:

That said we'd love to support you somehow. The problem with donations are that we don't have an invoice for the financial department. If we can make some kind of agreement for an extension to .Ext (of course we pay and then it will be BSD license if you like... hope this goes for others that may "buy" you to do something) then we'd love to pay something to have it extended and/or just paying for a commercial support agreement.

We're really looking forward to the submit. We have several projects in the "hold"... just waiting for this API :?

Keep up the tremendous great coding you're doing!!!

Best regards,
Kim

Webnet
9 Feb 2007, 6:01 AM
My team is also waiting on this api complete a big project. Your new menu/Grid will play a HUGE role in our system.

Jack, you neeed to boost your income and from what I read on this post, we will support you!

PuritysDisciple
9 Feb 2007, 6:50 AM
I'm not sure how many communities are in pretty much full support of a payed support licence, but it seems you have on here. The yui-ext library is so far above and beyond anything else out there that no one minds paying a little.

I have personally used Prototype, MooTools, Pure YUI, and a myriad of other libraries, and YUI-EXT is the only one that I am happy enough with to spend the time to really learn how to utilize its enormous power and eligance.

Keep it up Jack, and if you need some income, I'm 100% sure the community will support you!

mnugter
9 Feb 2007, 8:42 AM
I would really like a beta (or alpha) code quality too, I'm also holding back some projects, waiting for the new release (especially the new grid).

I've been looking around here for some time now and I'm busy implementing the yui-ext library into some of our new applications. I made my boss promise that after I finish the first (and largest) project he will donate a nice sum to you Jack :)

I have implemented the library into a private (paid) project and as soon as I finish the project (should be within the next two weeks or so) I will also donate. The yui-ext library saved me a lot of time and really impressed my client so I think Jack deserves a little money :) Can't afford much though, buying a house :) Think I can spare something like 50 euro's.

greyknght1
9 Feb 2007, 9:16 AM
There are a variety of things holding me back from making a commit. It started primarily because the grid was screwed and I didn't want to break anyones code. Next is the fact that there are now quite a few api changes that will need formal documentation (upgrade path) and I don't want to be answering questions about that while trying to hit my 15th deadline (my personal deadline for beta 1).

Now a new thing has been added and that is the possiblity of a commercial license option, or a support license or something (I still haven't centered on any particular path yet), but something where I am able to earn some kind of income. The sad fact is right now my income is less than the guy serving at McDonalds and I don't know how long I can survive with 2 kids in diapers and a pregnant wife on that kind of income ;). Other options I am considering are some kind of fund-raiser or a new "donate for specific features" page where top donations = top priority. For the people who have made donations, I appreciate it very much.

I was hoping that you would do something like that. For some reason if it is "free" the org I work for thinks it is bad, but if you pay for it, now that is a different story. If you set up an option for $1000 a server licence or something like that, I bet I will be having procurement paying about 6K right away. Anyway, just let me know what you are thinking via your blog!

digital.alterego
9 Feb 2007, 11:01 AM
Nice article how you can earn money from your oss project:

http://www.damnsmalllinux.org/income-guide/

mdissel
9 Feb 2007, 12:04 PM
If you set up an option for $1000 a server licence or something like that, I bet I will be having procurement paying about 6K right away. Anyway, just let me know what you are thinking via your blog!

Maybe something like this:
- 0.33 release for free (only bugfixes)
- starting from 0.4 create a developer license (one for each developer)
. $ 250,00 free upgrades for one year (and maybe a nice discount if you buy this month :-) )

If you switch to a not-free-licene you should use some kind of obfuscator to protect the code..

Thanks

Marco

KimH
9 Feb 2007, 1:22 PM
I have no problem paying for something like this API which is far better than anything I have seen before. That said I believe that it will kill this project if commercial use of it will require payment. Of course Jack would get the income he deserves, but what else will happen?

I think that by commercializing the API you will probably "kill" at least half of the projects that has already implemented the 0.xx release. Many projects will be more expensive than what they are worth. If commercial user of the APIs is totally free like today then it will encourage even more developers to use the API's and maybe this API will be the "standard" for browser-based applications. When it attracts the wide audience then Jack will get more request that will bring him the donations for custom widgets (which I believe should be put into the core APIs or as "plugins" even though someone has paid the initial development of them).

What is needed - in my oppinion - is the already known BSD license granting everyone (personal or commercial) the right to use it free of charge. I know Jack will not get any payment be giving it away for free, but if there were a commercial support subscription that was payable and which would give the paying parties higher priority when reporting bugs then Jack would get payment for this. If a commercial company (or anyone else for that matter) needs a widget that is not part of the API then they can pay Jack to create it. The company will get the "plugin" they need and Jack should be "allowed" to publish it as a plugin to the core API (or even implement it in the core) for everyone else to benefit from under the BSD free license.

My hope is that since Yahoo haven't already given Jack a large amount of money (I'm wondering why?!) then maybe the Eclipse foundation could consider donating some money to Jack for making a future version of the API "like" the Eclipse way of coding applications. Would it be nice to be able to have the same XML-based configuration of a UI that could automatically create a scheleton of an Eclipse and a browser-based application? I'd love that!

toastr
9 Feb 2007, 1:49 PM
Jack, would you be able to clarify what you're thinking about with the commercial license?

Anything other than $$ for support (e.g. $$$$ per deployment) would likely mean that I'd not be able to use it anymore and I need to start looking for a replacement (asap...)

I fully appreciate your need for income, hopefully you appreciate your communities need for more detail.

I also assume since the .33 release is already available and licensed, this applies to .40?

jratcliff
9 Feb 2007, 9:22 PM
I vote for an "optional" paid "maintenance" plan where if you pay a yearly maintenance, you get x number of support calls and/or x number of votes to help prioritize software enhancements, new features, bug fixes.

For us in the corporate world we would need an invoice to make accounting happy and then it would help Jack out at the same time. I think there are many of us out there that would like for the companies we work for to donate but we have bosses who either don't want to pay for something that is already free, or don't think free software is worth using (the 'you get what you pay for guys').

The bottom line is this, we as individuals can only afford to pay $ and $$, but corporations can afford to pay $$$ and $$$$. For the corporations to pay, the software needs to "sound" commercial. Telling your boss you want accounting to "donate" via "paypal" for some software doesn't sound as good as telling your boss you need to "purchase" yearly "maintenance" for Ext and here's the "invoice" for it so let's put it in our yearly budget.

Then, we as the developers using Ext are happy, our boss is happy, accounting is happy, those that can't afford maintenance are still happy, and most of all, Jack is happy and can afford more than Happy meals for his kids. :wink:

ilazarte
9 Feb 2007, 11:39 PM
jack you can always do what others do with os software, offer your services as a consultant expert on the technology.

Preston
9 Feb 2007, 11:44 PM
I am also in the position that costs for licencsing would kill the use of ext in my project, so i would also have to look further. Money for an optional "paid" support/maintainance option would be great though.

Well, in the end it´s all up to what Jack wants to do with his fine work. I understand that an income is really necessary :)

jratcliff
10 Feb 2007, 8:50 AM
Here's another idea. Why not have a "partner" program? IBM has a "Business Partner" program that gives users/companies access to "extras". I think they charge $2,000/year. Jack can do something similar where perhaps those that pay for it get some "extras" like more code samples or whatever. Again, you keep the code opensource and free and those that can afford to pay for maintenance or be a "business partner" can. Again, for us in the corporate world it just needs to be "commercial sounding" and words like donate and paypal aren't commercial sounding for some. :)

dfenwick
10 Feb 2007, 9:52 PM
Licensing is a very sticky issue. If you make it a commercial license, the license incompatibility with other open source applications prevents others from using it in other open source applications. Even the current license has incompatibilities with the GPL and LGPL, making it difficult to include in any open source application that is protected under the FSF.

I'm not an enormous licensing bigot like some folks in the FSF world are, but there are cases when things can get very sticky, particularly when you have copyrighted source and you know someone is violating your copyright and commercially repackaging your source in another package. This happens quite often, and one of the good things about the FSF is that under the GPL and LGPL, you have at least some organizational support behind you.

I am an alumnus of the Samba team. I spent over 10 years dealing with these licenses, license incompatibilities, and specific licensing violations of the Samba code. It's a mess, particularly when you know there is a decent source base you'd like to include in your application but can't due to license incompatibilities.

From my perspective, I'd love to see the Ext libraries changed from the current licensing model to the GPL or LGPL and rather than selling commercial licenses of the product sell 2 things:

1) Support services via some level of SLA. You'll probably need some level of staff to pull this off if the SLAs are anywhere tight

2) Paid extensions to the library, with the stipulation that changes get rolled directly back into the open source distribution

I can certainly see the allure to creating a commercial distribution for your libraries, but having done that for a few years of my life (I wrote commercial components for a few years back in the early 1990s), my fear is that you'll eventually lose interest (a common occurance), and eventually those commercial paying customers will be stuck with a source base for a good library that is no longer maintained. The only reason I say you'll lose interest is because you, like me and many others, have mouths to feed. If it doesn't have large enough commercial success, you'll eventually have to take a job with someone else, rendering your Ext library somewhat of a 'hobby'.

The weaknesses of open source is that it's difficult to pay the bills if you exclusively write open source software and you don't have a high rolling sponsor to help you. There are many open source developers out there that are bankrolled by some of these companies (IBM, Sun, SGI, HP, etc.) while there are others that have very little sponsorship at all.

The strength of open source, on the other hand, is seen when there's a lack of true 'ownership' over code. While there may be a project lead, and most good open source projects have a somewhat heavy handed strong leader (Linus Torvalds, Andrew Tridgell, Havoc Pennington, etc.) to steer the project in the direction they envision it going. Sometimes there are negative impacts to that, such as the XFree86/XOrg split, but for the most part successful projects are usually pretty smooth. With the lack of a sense of 'ownership', code can evolve even if someone on the project moves on to other things.

I understand the difficulties one faces financially when trying to build something you want others to use, and the commercial option always seems like a decent prospect. Using myself as an example, I made about what I would have made from a typical software development house writing commercial apps and libraries, but I incurred an enormous time loss due to doing it. I'd venture to say my average work week was 60 - 70 hours and I was juggling so many balls, I eventually threw in the towel when I got to the point where my software was being obsoleted by other types of software and widgets.

Anyway, just my $0.02 about the whole topic. If it goes commercial I'll be unable to use it in 2 different open source applications I was considering. Your library would set the webmail world on its ear. Since all of the current open source webmail applications have rather large warts, that was one of the targets I'd been considering. The other was in the Samba management world, but I haven't really even thought through the design of that system yet.

Animal
10 Feb 2007, 11:26 PM
Surely some company will sponsor Ext in the same way Dojo is sponsored. Dojo have managed to inveigle IBM haven't they? What bandwagon jumping, non-technician at IBM approved that?

I mean IMHO, Dojo is flaky, incomplete, non cross-browser, undocumented, slow, cumbersome. The source has comments like "// I don't understand this" and such like!

Ext is a high quality product from the start.

jack.slocum
12 Feb 2007, 11:53 AM
Thanks for all the input guys. The commercial license is going to happen, and I have created a thread for assistance on how it can be made to work for everyone.

http://www.yui-ext.com/forum/viewtopic.php?t=2676