The Adobe walled garden of knowledge
DIGG IT!
9
Comments
Published
Thursday, May 29, 2008
at
5:58 AM
.
As an ecosystem we do not share knowledge very well and over time this has essentially created a very large walled garden. If you are in-the-know regarding the ecosystem or sub-segment of it, you can see all the value clearly and know where and how to get what you need to succeed. If you are outside the wall (new to Adobe tools and technologies), you see a very large intimidating wall that looks proprietary at first glance.
I don't think anyone in Adobe had a vision of building a large wall that looks proprietary but alas here is this wall and behind it is an ocean of knowledge on how to make great experiences. Actually we have spent a great deal of effort to tear down the wall around our runtimes and core technologies with Adobe Labs, Open Source Flex, Blaze DS, Bugs.adobe.com, Open Screen Project, and Tamarin but we still have a vast quantity of knowledge in the community that is not shared.
I believe that the root cause is actually that a majority of our output is compiled and thus the source code and context remains hidden from view. View Source in the browser really enabled anyone to learn HTML/JS and this "forced sharing" makes it feel much more open. SWF on the contrary is a dark magic and how it works and how to make it do amazing things is not shared automatically. It SEEMS closed and proprietary because the source code is not present and thus the knowledge and context behind great projects are by default locked into a vault. On one hand it is really great that these formats are compiled but on the other we must do extra work to share knowledge. I believe that the "lack of sharing" is the subtle gravity that is holding back our ecosystem and that if Adobe made it easier to share knowledge we would move dramatically forward, actually violently forward.
There are some large projects underway at Adobe, "ION" and "Hyperdrive", to tear down these walls and force knowledge into the open. I am looking forward to working on them with you and helping the community share knowledge more openly, more easily. I also want to make sure that anyone sharing knowledge gets full credit for their contribution and that value flows towards those that share in the community.
Back to tearing down this wall...
Details coming soon!
Ted :)
I don't think the 'View Source' thing has a big part of responsability here. Look at Java, applications have always been delivered as bytecode-thus-hidden...
In fact Java seems open-source because there are plenty of big projects that are open-source... So somehow the open-sourceness of the company comes from the ecosystem around it. So in my opinion your latest moves (gumbo, blazeds, swf, openscreen) go in the right direction.
'You are on the right track Adobe' :)
Interesting project names ("ION" and "Hyperdrive"). Gets the imagination spinning...
This sounds like a good direction to take, so good luck!
HA! Thanks for the profound post, Ted. I'm sure I speak on behalf of the Adobe community that we are anxiously awaiting to see what you all have up your sleeve.
Something like a mix between SVG and Flash would be a good choice too. Not compressed SVG, only an easy way to create code directly from HTML. Of course not to create weighted application like Flex ones. Just to create graphics and animations when Flash is a better choice than Javascript. It could favor Flash adoption instead of Javascript in many cases and help to learn how to use Flash player.
With this pseudocode, the mandatory option is to have a report of a public API exposed by the animation that could be exploited from HTML without to have to expose the complete source. Like exposed API of ActiveX, DLL, etc... This allows reuse of the application without opensourcing it. It is a good choice for many corporate project (not all of course).
On the long term (standardization adoption by search engines), this solution offers a way to expose meta tags, or deeper method to reference the content of the animation.
tek,
I am not sure the problem is technical in nature. I would love to see a human readable SWF format but that still would not promote sharing. Great points though!
Ted :)
Ted,
I also think that showing more source code would have little relevance for the majority of programmers. I think there is a huge difference in both approaches taken and the code produced by average (enterprise or web) developer and Flex Team member.
There is a huge gap between sample application code and framework source that puts the later out of reach of app developers.
Cookbook was the step in right direction for JS/HTML folks. However, I still believe Adobe overreaches "migration" path for that group of developers - after all Flash and AJAX markets are booming now and migration is not welcomed by most.
Take a look at Silverlight watchers. By providing simplistic development model and tight integration with their stack M$ will indeed migrate significant number of developers to the platform - the key here is simplicity and familiarity. Adobe has advantage with bigger and more "vocal" Java community but keeps (IMHO) loosing time.
Time for Cookbook to become Culinary University where you can take on larger topics ( ie North Italy cooking vs how to boil pasta). It starts on lower level - with dissecting the qualities of each ingredient and progresses on showing how they work together. The samples have to show how you progress, step by step to complete solution rather then showcasing technologies and products. And as it is the case with any creative cooking, you always have to keep adding fresh stuff from the market to the staples.
Now that you are moving toward our sweet spot - Platform Training Solutions - consider the opportunities it gives to community. My favorite is "bootcamping" for enterprise client - going to the client site 2 weeks prior to major training, spending 2 weeks on working their application into courseware, adapting it to the clients companies best practices. By using recognizable code (their code in a lot of instances), environment and practices people progress at amazing speed. Given a choice which code to choose in training - canned or clients - I always choose clients - something to try.
I started working on the new book - the approach I am taking is to drive from the point where other books stop. For example, instead of making another boring definition of pattern I just describe it in one paragraph for people who are new and do not want to check it on Wikipedia. Then I show where and how it is used in Flex framework and how you apply it in real application - with the largest impact possible getting them right to the "best practices". It works.
Regards,
Anatole Tartakovsky
Farata Systems
Anatole,
Amen to the Culinary University, violent agreement here!
Ted :)
The fact that Adobe started paying (some...) speakers at Max is already good step forward.
On the other hand: .NET also took years to become popular and their Visual Studio is way more expensive. Looking at the fact the Deloitte is looking for Flex developers in every state of the US as part of its 'emerging technologies' department is a very good sign (but clearly shows that RIA is currently 'just' an emerging technology).
One thing that could help a lot is getting more companies to build (affordable) Flex components (with source included). This way you can be confident that you don't end up in a situation where you have to build complex components yourself. Because lets face it: some essential components have been added to Flex 3 but the majority of the components hasn't been enhanced (or is it already possible to have tabs on the left or right of a TabNavigator)...
You must be a real Star Wars fan because the two hyperlinks within this article point to the Star Wars site - http://www.starwars.com/databank/technology/hyperdrive/
Frankly, I am a Star Trek fan so your Hyperdrive is our Warpdrive. However we both get there one way or another.