Take Flex Back For the Community
The answer to the question “Can it be done?” has been answered. On friday afternoon I checked out the Flex SDK from svn, and I made some modifications. I renamed all the Fx classes back to normal names and I updated all the code references. I replaced the old library manifest files so that the the halo and gumbo code libraries can be referenced independently. I compiled the SDK and have made a couple example app to ensure my changes work. Then I went through the practice of updating my code from the commits on the official Adobe Flex SDK. Taking their change and keeping the code base up to date is relatively simple and I could probably automate it. The easy part is over, changing the code works. I can name half a dozen development shops that run custom versions of the Flex SDK because they needed to fix problems that came up in their projects. Fixing the code is easy. Contributing that code to the community is hard.
Propagating your code fixes to the community can happen in a couple ways. If you are a blogger you can share the problem and the solution so that other folks can find it and then make their own version of the SDK. What you would really like to do is probably submit your addition to the Flex team so that it can be considered for inclusion in the next release of the product. But lets say you do actually get the SDK team to take a look at your patch and for whatever reason (those discussion are had behind closed door so we won’t likely know) they reject your submission. Your only recourse left to release the code you know will benefit the community is to release your full version of the modified SDK allowing people to use and work from your version of the code. Essentially you can fork the Flex SDK project.
What is a fork
Think of a fork in the road. Where once there was one path, now there is two. And who knows if the two paths will ever intersect again. What does that mean to us as a community? Well it means that there is an alternative to the Flex SDK from Adobe that has a feature that the Official SDK does not. Is everything else about the two frameworks the same? That depends a lot on the developer or team that creates the fork. There is no reason the developers can not continue to incorporate the updates from the Adobe Flex SDK. For the community it means a choice about what framework they use to build their RIA applications that target the flash player. To the fork provider it means being willing to accept responsibility for accepting bugs, feature requests and documentation, Just like any other open source project. But having the fork and supporting it does not really solve the initial problem. The problem that we as a community still don’t have a forum for discussion the development of the open source project. All we have really done is create two projects that we don’t get any real input on.
So what does a fork mean to Adobe? What does an alternative framework targeting the Flash runtime change for them? Does it create an environment that includes healthy competition? Does it mean that all the work they have done has not been appreciated by the community? The real question I want answered is does having another framework that includes features and code based on community input challenge them to change the process around how they communicate and plan the development of the Flex SDK?
Because right now, I don’t feel we get any voice. And while Adobe has committed to opening up this process, how do make this change a priority for them? Every day decisions are being made behind closed doors that effect the framework (the open source framework) that we know and love and have built our careers on. What kind of action is required to make Adobe’s top priority making good on the promise of an open source framework?
This is not a small problem that can be easily remedied. The Flex framework has brought thousands of developers to the Flash Platform. The Flash Platform is a key business tool for Adobe. Flex is at the heart of the building “engaging experiences” that all of Adobe’s tools focus on. Flex may have been open sourced, but Adobe is in no hurry to let go of any of the control over the direction of the Framework. Far to many of its money making applications require it. But those tools only ease development utilizing the features in the framework. And there is no reason not to have an open forum for discussion of the features being implemented by the SDK team. In fact opening those discussions will allow the community to contribute more than bug fixes. How many times have you talked to a member of the Flex team about something you really wanted to see in the framework and found out that they had discussed it but didn’t have the resources to implement it before the release. Opening up the discussion around the implementation of features and what features are being implemented allows Adobe to utilize the entire Flex developer ecosystem to make sure that every release is the most amazing it could possibly be.
What can we do
Flex is an open source framework. It is licensed under the Mozilla Public License and as such it is within our power to take what Adobe has given us and do with it what we will. The only stipulation on that is that anything we release in binary form we also release in code form, and that we list what we have changed in the releases, upholding all original licenses on the original code.
Flex is ours. Adobe gave it to us when they open sourced the code. Our jobs as Flex developers depend on that framework being the best it can be. And how can that be the case when everyone is using their own version of the framework in private because they have no means to submit that back, and the community has no way to voice their need for those submissions. The development of “our” framework must be done in the open with the planning done in the open and the input on what gets in open to our voice. And Adobe needs to know that if they can not or will not allow us to participate in the development of “our” framework, that we will utilize our rights to take what they have given us and do what they will not.
Now is the time to use your voice, be that at your local user group, on your Blog, within your company or on your favorite mailing list. Now is the time to make sure that Adobe knows that we will not stand by and allow them to decide what is best for our framework. Now is the time to be loud and make some noise to make sure Adobe knows our desires and intentions. We need them to understand that they have an opportunity to stop us from forking the framework. And that any decision other than to implement an open process for discussion of development and inclusion of features, will result in the community taking the matter into our own hands.
Now is the time. Make some noise.
Excellent blog article, thanks!
Very good points. I’ll completely sign that.
Best regards
C.
Hey Sim,
It’s great to see the passion that you have for Flex, though of course it’s hard to not take some of the criticisms on our process personally :-) I hadn’t responded to some of your earlier posts because I feared they would simply come across as defensive, but I think it’s probably important that we try to be involved more in this discussion.
The crux of your criticism seems to be that the process that we use for decision-making is closed and that there isn’t an opportunity to influence the product. I’m really sorry that this is how you perceive things because it’s certainly not how we feel. For one thing, we’ve made a real effort to post specifications as development was ongoing so that we could receive feedback on features. Additionally we’ve made specific mailing lists/forums available solely for the discussion of what is going on in the SDK. These are linked from the open source site, but there has been very little participation from the community so far. Finally we do have the bugbase and feature request system. I read every feature request and try to give at least a simple reason for why something might be deferred or inappropriate, and other feature requests are in fact implemented. We used the voting system for feature requests to decide that 2-way binding and some of the CSS features were going to be critical to Gumbo.
One thing that we’re considering to help with the feedback process is to have more regular public meetings regarding what is going on in the SDK. Our dev schedule is divided into iterations (anywhere from 4-6 weeks). At the end of one iteration and the beginning of the next we’re hoping to host an online meeting where we can discuss the things that went in over the last iteration and what we expect to go in during the upcoming iteration. We can also try to discuss some of the decisions that were made along with decisions we think we’ll have to make in the future. This is an opportunity for folks to hear what’s coming and also comment on what they’ve seen over the last few weeks. It doesn’t replace the immediate feedback that can be provided over the forums/bugs/etc, but does provide a more interactive setting. We’re hoping we can begin this in a few weeks.
We have another idea that we’re bouncing around that I hope to share in a week or two but won’t get into now.
OK, last thing, and this is where I’m going to look really defensive. I may be totally wrong here, but the majority of the angst around SDK direction really seems to be around the Fx prefix stuff. It’s not so much the direction that Flex is going as the decision that was made to what in the end is a significant implementation detail. We probably could have tried to have the original discussion around this in a more public setting, but it’s a complex issue. The decision that we made is challenging to justify because no solution was especially appealing. There are a number of things that need to be considered: how an application that is being migrated would behave, how CSS should work, how ASDoc should work (as in how can you easily find the right doc entry), how a new user will feel coming into Flex. Are we sure that this was the right solution? No. But it seemed like the right solution to implement in the shortest amount of time so that we could expose the SDK to end users and get feedback.
The feedback from existing developers has certainly been mixed (I haven’t heard anything from new folks). So I’m hoping that we’ll get more input and if we (and the community) decide that we need to make a change we will. And if we do I hope that maybe the community will help us figure out the right way to implement all of the things we need to take care of (only partially listed above). Notice also that I didn’t mention tooling because folks seem to think that our thinking about Flex Builder is due to the commercial impact. That’s not really true, we think about tooling from a pretty generic perspective. We’re not looking to make it harder for FDT or Amethyst or Tofino or any other IDE solution. We try to come up with solutions that will work across the many use-cases that we need to consider as a widely adopted product.
This is a long response to what can be a complicated topic, but we really do want folks to participate in the process. I hope that we can perhaps continue the discussion over on the forums that are set up for this purpose: http://www.adobeforums.com/webx/.3c060fa1/ (available via email once your account is set up at flexsdk-general@adobeforums.com).
Matt
Hey Matt,
I am quite certain that the things I say will hit close to home for you and the SDK team. But please understand that none of my criticisms are directed at you and the team directly. I have built my entire job around providing training and development around the Flex framework and the Flash platform. I am passionate to a fault about it because it is at the core of everything I do. But I believe in the idea of Open Source like I believe in democracy. I believe it is the way to change, and through it the community is responsible for its future. I value every day that you and the team spend writing software because it is for the betterment of everything that I do.
But beyond that, beyond your team of do-gooders is a battle for what is right for the SDK and what is write for the tools and what is right for the bottom line of Adobe stock holders. As such the decisions that go into the development of the SDK are fragmented in purpose. And I hold steadfastly to the idea that they should not be. The SDK should be developed in tandem with the community with discussions of what features are being developed and what decisions being made happening with input from both sides. With the Flex SDK team a contributor just like everyone else.
As a member of this community I feel it is my obligation to present the hard line on this matter. Someone has to be the crazy way left guy that creates the waves of change. Had adobe not chosen to open the Flex SDK I would be happy to sit back and take the the changes as they come. I would be thrilled with the steps you have taken to add transparency to the work you plan on the SDK. But that stands at the crux of the problem. Flex is run as a closed development platform with amazing transparency. And while we get the source with updates as they come, we “the community” can’t be a weight on the fulcrum of those decisions. And yet some how an open source project has major changes implemented to it based on the needs of the tools being developed to support it. That is not an open process. In fact its just wrong. Its the tools job to support the language, and its the languages job to support the developer.
The community has to be the path. The needs of the community have to be the reason.
I’ll be honest Matt, I don’t know if the community is ready to support the open development of a framework. And the path that I am currently on is that I would hate to see the official Flex SDK suffer because I rallied for change too early. But I believe that a flash platform framework driven by the community is needed. And wether that starts as Flex or comes from something new we wont know for a bit yet.
Steering an iceberg is not a fast process. And that is only considering that the path of the iceberg is intended to change. The things I feel are right may never be echoed by the management at Adobe. In which case waiting for it is useless and I am better to start trying to rally the community now. Because the other side of this is that maybe I really am the only crazy person who things this should happen. And if that is the case then the community will never rally, and I will go back to ranting in my dark corner.
Please don’t take my noise as a knock on the hard work that you and the SDK team have done. In response to you being defensive, you should be :) You work hard and are doing what you feel is right. But you are also working inside confines of what is right for Adobe and not just what is right for the community. You are the middle ground between crazy-wave-making-me and the iceberg. But when the people that steer the iceberg decided to open source this project they gave the community the responsibility to challenge them and ensure that our needs are met, even if we have to take ownership and do it ourselves.
@Matt
1st off thanks, now my input:
“The crux of your criticism seems to be that the process that we use for decision-making is closed… it’s certainly not how we feel”
Unfortuntly, this seems like a case of bad commuication by Adobe and the Flex team. If notable community experts get the impression of closed doors, then *certainly* the rest of us get this impression as well.
“but there has been very little participation from the community so far”
I’m a solid dev, and not an expert but I can contribute in things such as testing and low level optimization; But, the Adobe ‘open source’ site is a galactic disaster and discourages me from getting invloved. It has so many webpages that just go around in circles – filled with text that is verbose, this frustrates me to a great deal. As opposed to somehting straight foreward like:
http://framework.zend.com/download/latest
or
http://code.google.com/p/papervision3d/
Everything is here and easily notable. I avoid the seamingly endless pages and confusion. If I want to get to the Flex dev mailing list I have to register, then choose the lists, add the lists to my account…. go though my account prefs… read some directions….. then set up some other preferences…..jeeeezzzz. If I want to submit a feature request I am directed to create another login for some “Bug and Issue management”? HUH? I thought I was submitting a featue request.
Right on papervisions google HOME page I see “Getting started” > “Papervision3D Mailing List”.
Next when I finially do get to Flex SVN, this trunk…. is nothing like I have seen….what IS all this stuff and where do I go to learn about it? There are countless subfolders filled with things I vaguely understand and if I want to learn what it is…. where do I go? Is there even a ’src’ folder? Here is a classic example.
Flex trunk Read Me:
http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/README.txt
vs.
Zend Trunk Read me:
http://framework.zend.com/svn/framework/standard/trunk/README.txt
*What* is the Flex team thinking with this?
I just spent 5 minutes or so twirling through all these SVN directories and Adobe’s website and I am clueless. I feel like the project is unessarily complex and disorganized – even if it isn’t. This just convinced me to delete my Flex sdk bookmark on my SVN client.
Adobe just lost one potential contributor to Flex SDK.
“We have another idea that we’re bouncing around that I hope to share in a week or two but won’t get into now.”
Saying stuff like this is what gives people the impression of ‘closed’. Why not post these ideas the Flex team has? Even if it is ’stupid’ or ‘incomplete’
That’s the whole point.
As Matt’s request I have voiced my opinion on Adobe’s forum:
http://www.adobeforums.com/webx/.59b790da
I made another post where I pointed out what I considerd were inconsistencies in Adobe’s “Open Source” policies.
Have you considered just checking out the sdk from Adobe, and pop it onto sourceforge or google code. Make the changes you feel are needed and see who else jumps on. I donno if that is against the Flex sdk license, but…screw it…see what happens.
@Alan,
Thanks for continuing to make some noise on this matter.
I have checked out the code and made my modifications. But I am really trying to find a way to not have to release my work. Despite my recent posts, I really do like Flex, I am just unhappy with how decisions get made about feature implementation.
This post is really a last ditch effort to inform people about the problem before I start a new adventure. That is, of course, to create a community driven framework for the Flash Platform.
wow wow wow!!! As a beginner in such things with Felx,flash and everything (I mean..I’am a beginner), I have to say Thanks… your post ist very interesting and useful.
I actually find all this quite complicated, but I do that just as a hobby and maybe one should have your passion to be a guru in these things. So, I congratulate you for your effort and dedication!!! Well done!
Uh oh…I guess it’s time to put money where our mouth is… Just got this s few moments ago…
See you there….
“A new discussion was started by Matt Chotin in
General Discussion –
Announcing a Flex Community Feedback Forum
WHEN: January 28th 10:00am PT / 1:00pm ET / 6:00pm GMT (duration 1 hour)
Come speak with the Flex SDK team to voice your interests and concerns. This
session will be an opportunity for the community to talk about the Flex SDK
itself and discuss our management of the SDK open source project. Please
bring your questions and feedback as the session will primarily be led by
you (and could be short if there’s not a lot of input).
The meeting will be broadcast via Connect:
http://adobedev.adobe.acrobat.com/techweds
** enter the room as a Oguest¹ using your First and Last name **”
Here is a classic example of skewed priotities(although its for Flex Builder and not the SDK per se).
https://bugs.adobe.com/jira/browse/FB-13214
Unbelievable, first of all that this was not caught in QA, and then to categorize it as “feature request” instead of “show stopper” is completely bogus.