I read JD's post about "Open code, formats, or conversation?"
Wanted to make a reply but got rejected for "Questionable content"... Yeah I know, probably an over enthusiastic filter or it just doesnt like me but anyway, here's what I wanted to say.
Hmm,
Addressing the "community" aspect:
Send a response when people submit a wishlist item or request to join a beta program and dont get accepted.
Make the Devloper site more about delivering what the developer needs than pushing the newest MM feature or product (like flavour of the month with MM is clearly Video so almost every article is about Video). Maybe this is a perception thing but I find MSDN site to be a knowledge source where as the MM Developer site is probably the last place I look if I want information about Flash.
Adressing the open source vs closed source aspect:
I personally dont mind closed source but it needs to be very high in quality, very broad in scope and well documented i.e. I mean it has to be such that dont really want or need to touch it anyway. I would say that I dont feel that this applies at the moment to the AS2 Framework, WebServices, DataBinding and JSFL Wizards, some of which MM has made open source and some of which it hasn't.
That said I also dont really see a benefit that closed source gains a company when there is no real threat of a loss of critical knowledge to a competitor or some misue of the code and I dont understand the logic behind MM's choice of what to open source and what not to (though I dont mean this is an attribute unique to MM by any means lol).
If your software has commercial value (that is you charge for software licenses and people are willing to purchase licenses), then there is ALWAYS a 'real threat of a loss of critical knowledge to a competitor or some misue of the code'. Don't you think so?
ReplyDeleteBest regards,
Burak
Burak,
ReplyDeleteNo I dont think that is always the case, though in many cases and in particular with smaller companies yes its true.
Take for example the source code of the Flash framework.
MM make money from selling boxes of Flash not components.
A competitor to Flash (the program) would gain nothing from the source code to the components which are all actionscript based and since MM make no money directly from the components they wouldn't lose anything from a rival component producing company (say like us) seeing the code as however many components we sell MM wouldn't see the sale of Flash drop by a single unit (in fact if anything sales might go up).
Same argument goes for WebService classes/DataBinding and the JSFL Wizards.
Where there would be an argument is in relation to the player source code. Certainly the misuse argument is valid, someone could spoof the player. Competition wise, yes there is also some justification to say that a company could use the source to create a competiting product that reduces the sales of Flash. Though MM clearly have the resources to sue in such circumstances.
On the other hand I think for say ASV it would be a serious problem as someone could just recompile your code and start selling a rival product with little problem.
Although it can be argued you still retain copyright, for smaller companies you just dont have the resources to enforce those rights.
To take another example if MS released the entire Windows source code and if a company took that recompiled it and sold it as PSBlinds(ignoring the fact that they can still be sued for copyright) it is unlikely it would sell a single unit as there is so much more to why Windows sells than its code.
"... rejected for questionable content...."
ReplyDeleteYeah, sorry, I got rejected a lot there too, if that's any consolation... comment-spam has dropped remarkably at the markme.com weblogs with this multi-layer system, but sometimes I wonder what the filter might be ojecting to, myself....
I wrote:
"what's the first thing that comes to your mind about how Macromedia can improve in this area...?"
Yes, getting something beyond the immediate auto-reply when mailing the wishlist has been a frequent request. So far I don't know of any product team which has found a sustainable way to do it. (From what I've seen, about half of the incoming to wishlists is misrouted, and should go to support, or (even more usually) searching the site first.)
For much of the "Why isn't Feature So-and-So-already in the app?", then statistically this info is usually already in the public conversation, even though the answers to "Why no right-to-left scripts yet?" rarely seem to satisfy. This-all doesn't mean it's not a good goal, it's just not as readily attainable a goal as might be imagined.
Both wishlist and beta input should get at least the automatic confirmation, though, even if they don't have a human writing each reply. I know there was one beta snafu a few months back where a mechanism broke down when an owner was out-of-town, and Macromedia mail has sometimes been on blacklists which can halt delivery, but from what i've seen wishlist and beta input should be getting an immediate automatic confirmation, at the least.
For DevNet stuff, they're always soliciting authors (hint hint ;-). I do know that different issues have different themes, and video is certainly a hot theme right now, but when I've looked at the RSS notifications I've seen a wide array, particularly when looking across a month or two....?
"MM make money from selling boxes of Flash not components." For what it's worth, that's true, but usually not as important as people think. Studio is the biggest-selling authoring package, but Dreamweaver sales have always been significantly larger than Flash. With the ease of swiping digital bits I'm not sure how much longer software sales will really work, because a minority ends up paying for the free riders. Many software companies are diversifying into institutional licenses, training and certification, and in Macromedia's case software licenses to hardware manufacturers. The "boxes of Flash" are a real revenue source, but I don't think boxes are the main revenue source any more. (I realize this is slightly off-topic to the main point you were making, though.)
Hmm... for source code issues, there's another factor too, and that's when one piece of software includes code from more than one creator. (SWF licenses Fraunhoffer MP3 compression, the Sorenson video codec, the Nelly-Moser audio codec, likely more.) There's sort of a split between free-to-copy projects and compensate-to-copy projects... collaborations which are all open-source tend to stay that way, while collaborations which are not seem difficult to go open-source.
thanks for taking the time to write this... I'll make sure other people in the company are aware of this address, thanks.
jd/mm
Hi Blackmamba,
ReplyDeleteYou have your points. Open sourcing some parts of a product may be a strategic move. But then the company should decide on that. I still think that there's ALWAYS a treat. It's up to the company to take any risks. (If someone is making money selling components, then there's a business opportunity there. MM should decide if it's too small a market for them to enter or not, considering future projections. Maybe components are not a direct source of revenue for MM, but I think people purchasing Flash are happy they are there. Where would Flex be without any components?).
Regarding to JD's original blog post, I think you just can't satisfy people who think 'open source and open data are the bare minimum'. 'open company', on the other hand, is a good idea, and I think MM has been doing well in that area, nevertheless there's always room for improvement.
Best regards,
Burak