Since I first blogged about the issues surrounding the F04 EULA, and the restrictions it places on sharing code, there has been a very informative discussion going on in the comments between myself, Nigel Pegg, and a few other members of the community. Nigel has done a great job trying to explain the issue from Macromedia’s perspective (thanks Nig).
The super-condensed summary of this discussion (and my apologies to anyone I misrepresent here) is that developers would like the freedom to distribute and use modified versions of the built-in classes, but Macromedia is concerned this will lead to confusion if they update the component framework internally, and they do not want to see a competing framework emerge.
Now, this issue as it relates to sharing code in the community is one we can debate somewhat leisurely, as it doesn’t have a major impact beyond slightly retarding the growth and learning of said community. The real problem arises when you look at how it impacts real, paid projects!!
With the current EULA, I am locked into the framework Macromedia has created. I am not permitted to extend the existing framework, or modify Macromedia’s components, except through their API. Well, I can, but I am then not legally able to give/sell that modified source code to my clients – many of whom aren’t too thrilled when they get a compiled application with no source. This is a big problem, and one that needs to be addressed immediately. What if my client’s project requires a modification to how the accordian pane works? With the current scheme, I would have to write a brand new component from scratch, because I’m not allowed to modify the existing component and provide the modified code it to the client.
I think this whole thing is like banning the sale of Aspirin because someone might take too many and overdose. Instead, Aspirin includes usage directions and warnings on it’s packaging. We’re not allowed to distribute code because some developers may not use it correctly, or may not understand the implications of using it in their projects. Why can’t we follow Aspirin’s lead, and educate the community on the implications of using modified versions of the built-in classes in their projects? For example, I’d be happy to include a brief disclaimer at the top of my class files explaining the issue and/or pointing developers to a MM Technote on the issue.
Anyone have any more ideas on this topic? It’s an issue that will affect us all, or at least those developers creating complex RIAs (and isnt’ that what MM keeps telling us to do?).
I was wondering why soo much source code was missing…
This is crazy dude. I myself loved to follow Macromedia’s framework back in MX, but I fear I was one of few who did whole-heartedly. Most people I talked to, even those who pioneered the research into the area either rolle their own components and/or frameworks and at the very least modified Macromedia’s.
This isn’t going to change anytime, and further if past history is any indication will simply increase. Look at all of the frameworks that came about in MX:
– yours
– function framework for Flashcom
– my own way of handling WebServices calls for Flash Remoting via extending Remoting stuff via Observer patterns
– ACK
– JACK
– FLEM
– fluid.com’s XML framework
– the plethora of XML classes used as basises for many other frameworks + web service classes
– PHP Remoting derivatives (FlashPHP, AMFPHP)
– Ghostwire
– PowerSDK
There are a lot I’m leaving out. Regardless of my opinions on why poeple create such things, I really think forcing people to utilize a framework is ridiculous; case in point, we’re hiring someone at my company for a Flash Programming position who has experience in creating application frameworks. After determining whether or not Macromedia’s does what we need it to do, we’ll then determine what needs to be done to create a new one for us.
I mean, hell, look at import… it starts with MX. They practically make it very easy for us to create our own.
…damn, suddenly I sound like an open source loud mouth liberal, didn’t mean for that to happen. At any rate, I don’t see how this protects them financially; with the plethora of code, many people could definately rewrite things for the better or create new things, both code wise, and grahpically wise for themes.
A big, “Booooooo!”.
Well, if we have to respect perfectly the EULA, we’ll have a big problem!
Yesterday I found a bug in the ScrollPane component. The “scroll” event is not called when you “scrollDrag”. Looking in the code, I found what looks like a mistake in the “startDragLoop” function :
super.dispatchEvent({type:”scroll”});
should be:
_parent.dispatchEvent({type:”scroll”});
What am I supposed to do with that ? I can’t correct it and give the code to my client ? I must rewrite a new one ? This is a bit ridiculous!…
This will definatly make me pause before i use the new version of flash for paying jobs. In my professional services company we have to do what the client wants. Finishing the project with the right content is always the priority. Elegant code and structure is only nice if it costs them nothing. I have had to hack all kinds of components(MM and others) to get what i need(which i document in multiple places for future developers who use my files). I understand MM’s concern but they really ought to leave it to the market to filter through what’s good and bad-evetually a quality structure will emerge with heavy support. Developers should be aware of the ramifications of their actions and document what changes they make. MM job is not to take that freedom away from us. I would suggest -to further your comment idea- a way to tag the divergence so the extension manager would show it if a class is used in a component that will change the core framework(Icon/big read text at top of discription pane).
EULA BS: There has GOT to be a comprimise…
Reading Grant’s blog about the EULA stuff (original, new findings). Man, what a crock. Most of my clients, however, have custom written solutions. The scope of the projects are changing added with what I can now do in 7, resulting…
Actually, here’s a ridiculous suggestion, but one that may become necessary if MM doesn’t address this problem: What if someone builds a little app that creates and applies code delta packets. You could modify a MM class, then run it through the app – it would compare it to the original class, and create a new document that describes the changes. You could then distribute that “delta” document to another user who could apply it to a copy of the original class to re-create your modified class.
It’s stupid, but it might just work if we’re forced into doing things this way.
Cheers.
It fits perfectly into the big picture, imho. Starting with the devpacks, MM decided to cross the line from a developer’s tool company to an enduser products company. Central even takes it one step further. (The fun part about central is, that MM has no idea what to do with it.) The future role of a “developer” is to click together some components produced by MM and to sell this stuff.
In some way its a democratic process. Everybody should be able to build a RIA without prior knowledge.
On the other hand the niche, professional flash developers live in, is going to become smaller and smaller.
Think about F7. What if the bad usability of the new IDE is intentional? Think about the documentation? What do you need documentation for? Why do you bother to write your own scripts ?
As a professional developer, you should start asking yourself if you shouldn’t change to Java or .NET. I do.
EULA components
EULA components: Grant Skinner and others have been talking about modification of Macromedia components (see comments in this link and previous item there). Nigel has some info on the technical background, but if this is a hot issue in the…
Its interesting at how Macromedia expects the developers out there to lock themselves into using the v2 framework or go your own. Personally I looked at the v2 framework with an open mind, and i found nothing but troubles. I found the whole Window component hard if not annoying to work with, the skinning system to dependent on “colorization” and not on element specifics, furthermore you paid the heavy price of code spread-outs in order to leverage a few kb in size? (personally, its not worth the gains).
I ask most of you this, if we are expected to rely on MM for our technology? how do we as a flash community evolve? to me the existing framework was a simple solution to emulate what products like “Visual Basic Studio” does, in that drag and drop components onto the stage for RIA development.
Furthermore, what about those who relied on the v1 framework? how quickly these guys have been totally abandoned by the new v2 framework? hell some of the components from v1 themselves are totally gone?
Nigel has also casually mentioned here and there that the v2 where done to a tight deadline? To me that did not invoke me with confidence, especially when faced with the development of an Intranet application that my company will rely on. No offense to Nigel as he is a very gifted developer (along with his team), but if users out there can fix problems that either he and his team haven’t thought of, that or fix them on behalf of the MM engineers? then why should those developers be penalised?
Retardation of code is one thing to kick and scream about, but most of us know the score in that if we stray from a off-the-shelf framework such as the v2, all bets are off and Macromedia doesn’t and is not obligated in my book to support us.
If its a matter of Intellectual Property? then why did we buy FMX2004? The upsell that I heard mentioned was things like “CSS support” being belted out time and time again? only I look at the code / concept and all thats inside FMX2004 is a CSS emulator?
I just think its silly expectation to assume the development community will blindly follow the v2 framework and if they want to extend it or change it, its a demand on them to re-write it all.
Good work grant, I personally use your EventDispatcher and the whole removeAll feature was something I too love and use allot.
Grant Skinner et l’EULA (suite)
C’est toujours la confusion totale sur ce sujet (voir mon premier billet ici). Macromedia a avantage à régler le cas rapidemment, ça commence à chauffer. Quand des types comme Bokel disent “As a professional developer, you should start asking yourself…
since mm is following java: wats sun’s eula regarding modifying/distributing the crs code or java classes?
At least i dont feel bad about bitching for the last few months… if i understood correctly..mms says use our without modifying or make ure own…
honestly i make my own components anyways why? cause mm’s components dont always work or fit into real complex ria which need everything customized and its more stable for me to write my own and try go thru and understand someone elses… if i used 8 of their componets to make a new one and theres a stupid bug… its faster for me and my team to fix code we wrote from scratc than trying to see how forms work or if childscreens are not working right… just cause they wrote it doesnt mean i dont step thru it to find a bug.
but does this justify ditching flash mx 2004 pro? (should have been called flash 7…please lets just call it its real name and not a bs marketing label)
no. mm’s components are good for small/medium RIAs(another marketing label to distinguish applications from websites made with flash)
for large apps..i dont know yet… the only thing i really like about flash 7 is the player and right click context menu. packages? we kinda had that…now we just dont need to type as much.
mm seems to have hired a bunch of new ppl…i think they made a few hiring mistakes or someone needs to be fired… there seems to be too many issues with using flash 7. flash 5 to flash 6 was so nice. flash 6 to flash 7 invloves learning new syntax, junking all ure old code cause no interop, cant share /modified code.
looks like mm forgot who made their app wat it is in the first place. and i dont think the ‘great mothership’ is always right… theyre adapting ideas from existing pogramming environments & public standards…
im not dissing mm…. i think the marketing team has more weight since stock market is bad? did they make a few mistakes at the wrong time? be over ambitious with mx 2004?
nick
Well, if we have to respect perfectly the EULA, we’ll have a big problem!
Yesterday I found a bug in the ScrollPane component. The “scroll” event is not called when you “scrollDrag”. Looking in the code, I found what looks like a mistake in the “startDragLoop” function :
super.dispatchEvent({type:”scroll”});
should be:
_parent.dispatchEvent({type:”scroll”});