Charting a course

[Ben Clinkinbeard]

I guess it only makes sense to begin the group by discerning what it
is we want to accomplish and what we think is the best way to go about
doing it.

My personal aim, which I know is different than some of yours, is
simply to establish a small group of highly talented and respected
members of the Flex community that can earn a greater voice within
Adobe in regards to the direction and priorities of the Flex SDK. I am
not terribly confident we'll accomplish that but am willing to try.
Some of the first things I think we should decide on are the
following.

* What is the purpose of this group?

I've stated my personal opinion above but would like us to establish
an official direction and purpose, which I think will be essential in
guiding and focusing our discussions.

* Do we invite Adobe employees into this group?

I think I am probably leaning towards yes, but I think something could
also be said for condensing our discussions and conclusions (hopefully
we'll have some of those) and simply presenting them to Adobe. We all
know they've got their hands full and I'd hate for this group to be
seen as yet another list for them to monitor.

* Which issues are our priority?

To put it right on the table I despise the Fx prefixes. I think most
of you share that opinion. That being said, I think the main reason it
deserves priority is that if its not changed soon its there forever.
Would everyone agree that is one of our main priorities? Is it the top
one at the moment? What else do we see as priorities?

Once we establish a consensus on these items I think we can probably
dive right in, so the sooner everyone can share their thoughts the
better.

Also, remember to let me know if there are other people you think
should be members of the group. I don't think we should increase the
headcount significantly from where it is now but realize I have
probably overlooked some potentially valuable contributors.

Thanks!
Ben

[twgonzalez]

Hello All, for those of you who don't know me, I started working with
Flex 2 back when the first public alpha was released, and then quickly
got involved in the private beta. I have been working with Flex
almost continuously since then. Along the way I had an opportunity to
meet many of the people at Adobe responsible for Flex, and in some
cases collaborate with them (via being one of the Degrafa team members
and other projects) and I think I have a pretty good insight into what
constrains them and what their motivations are.

I give the background above as context before I respond to Ben's
stated goals, but I am sure there are others here who have similar
backgrounds and probably longer term relationships with the folks at
Adobe with potentially clearer insights than my own.

In my opinion, Adobe is going to do what is in the best interest of
Adobe. While that sounds obvious at face value I think it is
important to always remember in these discussions, as I believe at
times it gets forgotten. This does not mean that Adobe is evil,
uncaring, or doesn't want a prosperous community around Flex, it is
just a reality. Adobe is attempting to do something very
challenging, and that is take a very purpose driven commercial
software culture and produce a platform that wraps "open-source"
goodness around it. This is very different than an open-source
movement becoming commercial, or a company starting out with an open-
source offering and driving commercial success around a product or
service halo. This is a very strategic move for Adobe, and more
than anything I believe the primary driver is increasing developer
adoption rates (one again, kinda obvious.) Hopefully the preceding
paragraph does not come off as some pedantic diatribe, and helps us to
frame our expectations in a realistic manner.

I think the challenge we have as a group is that we are primarily
motivated by a different set of interests than Adobe is. I think we
all want Flex to be the best language/tool it can be. I also think we
all enjoy the community aspects that a group like this brings. For
some of us (at least myself) it has been our first entrée into open
source community efforts, for others it may be what they are used
to. At the crux of it I see a dichotomy between our interests,
desires, motivations and those at Adobe. There is also quite a bit
of overlap as well.

Personally one of the primary goals I would have for this group,
outside of resolving specific technical gripes, is forming a more
consistent and direct line of communication with those on the Flex
Team, and as a result having an influence on the direction of the
product. Bug voting, and 100+ connect sessions are probably not very
effective for Adobe or the community. If we as group become a vocal
and public voice for the community that the rest of the flex
developers and more importantly the "yet-to-be" flex developers that
Adobe is targeting, I think we will carry a lot more weight with our
Feedback. I believe Adobe sounded resistant to a "steering
committee", but if we leverage the community to help rally in what we
believe is best for Flex and the community, and we have the eyeballs
to legitimize it, I think we stand a lot to gain, and it would benefit
everyone.

I don't see why Adobe wouldn't agree to a monthly meeting with a small
group of community representatives where some of the technical issues/
decisions are at least aired and discussed openly. I am not a huge
fan of the Fx prefix either, but I know Ely is a pretty sharp guy and
he has spent a lot of time thinking about the reasons why that was the
best choice. I don't know if he ultimately is right, but I would sure
love to hear directly from him what the factors where that went into
his decision making process. I think the easier we make it for
Adobe to communicate with us - and as a result the community, the more
success we will have in accomplishing our collective and personal
goals with regards to the direction of Flex.

So if you have read this far, in conclusion, I think for me a goal of
this group would be to create a forum where we could have consistent,
direct, open communication with Adobe on the direction of Flex, and be
part of the decision making process while there is still time in a
development cycle to effect change in the platform.

- Tom Gonzalez



On Jan 29, 5:13 pm, Ben Clinkinbeard <ben.clinkinbe...@gmail.com>
wrote:

[David Tucker]

Hello all,

First, thanks to Ben for setting up the group and giving me an invite.

Second, for those of you who don't know me, I have been working with
Flex since Flex 2 Beta 2. I started as an independent developer, then
became a web/application developer at Georgia Tech, and now I work for
Universal Mind as a Flex/AIR developer. Recently I was one of the
authors on the AIR 1.5 Cookbook - and I blog regularly at InsideRIA.

Third, I agree with Ben on the purpose. I think he stated it well -
Adobe needs a group of Flex professionals to provide input on current
bugs, future planning, and issues like backwards compatibility. While
many items are just common sense, Adobe needs input on those items
that initially sound good on paper - but break down (or just stink)
when they are actually implemented in the real world (items such as
the Fx prefixes).

Fourth, for what it is worth, I believe that we should invite 1 (maybe
2) Adobe employees to the group, but don't push a level of expected
participation. They can be involved as much as they want. We should
still prepare a 'group summary' for large items (such as the Fx
prefixes) and submit it to someone like Matt Chotin (even if there are
Adobe members in the group). These 'group summaries' would need to be
thorough and well stated, so that Adobe clearly understands what we
are propsing.

Fifth, I think we should utilize our strength of numbers. By
combining efforts on such things as voting for bugs in the bugbase, we
can use the group's influence to make smaller items clear to Adobe.

Finally, I think the Fx prefixes would be a good initial item from the
group. I think we need to discuss between ourselves what would be the
best working solution - and then prepare the single 'group summary' to
send to Adobe (with the best workaround and plan for moving forward).
Obviously some organizational priorities will also need to take place
to get this completed. After that, we may just want to get a list of
items to address.

Hope everyone is well,

David Tucker
--
Software Engineer II
Universal Mind, Inc.
e: david....@universalmind.com
w: www.davidtucker.net

This email, and any attachments thereto, is intended
only for use by the addressee(s) named herein and may
contain legally privileged and/or confidential information.
If you are not the intended recipient of this email, you
are hereby notified that any dissemination, distribution
or copying of this email, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in
error, please immediately and permanently delete the
original and any copy of any email and any printout
thereof.

[Doug McCune]

Hello all,

My name is Doug and I like romantic beach getaways and binge drinking.

One of the themes that has come up over the past few months is the feeling that decisions were made without consulting the community, and the direction was already set in stone before the issues were brought up (I guess I'm really only talking about the Fx issue, but maybe other people have other gripes of a similar nature). I propose that in addition to thinking about those Flex 4 issues (which we may or may not be able to change), we also focus on what I consider to be the biggest thing that will be coming with future revisions of Flex: the List controls. The Flex 3 list controls, when used in a very basic way, work fine. But when you start using the advanced controls (DataGrid, variableRowHeight, complex item renderers, switching item renderers on the fly, custom skinning of item renderers, etc) then it all goes to hell. And don't even get me started on the "advanced" controls like AdvancedDataGrid, the OLAP controls, GroupingCollection, HierarchicalDataView, etc. That set of components is completely unusable (I've tried over and over again and every time ended up swearing and breaking things).

From what I can tell reading the Flex 4 spec page there is absolutely nothing to do with Lists and virtualized items in the planning for Flex 4. This means that we will be using the same Flex 3 List controls until some future revision (Flex 5?). The good news about this is that it means there is plenty of time to be involved in the planning of how these controls should work. My personal opinion is that the current list-based controls should be scrapped completely (just like the Gumbo components were a fresh start). Virtualized list controls are absolutely essential to every application I build (and I'm willing to venture that they're used in any real world app any of you have built). We need really solid list controls, with a top priority on performance and ease of customization. I'm tired of wading deep into the ListBase class only to find out that every time I select an item an entire iteration over every item in the dataprovider occurs. Basic lists can and should be made simple (with the same principles applied as the current Gumbo components).

So that's my suggestion for a future planning item that I'd like to keep tabs on.

Doug

[Ben Clinkinbeard]

"If we as group become a vocal and public voice for the community that the rest of the flex developers and more importantly the "yet-to-be" flex developers that Adobe is targeting, I think we will carry a lot more weight with our Feedback."

I think this is a great point, and one that I hadn't fully considered until reading it here. If we can position ourselves as something of a middleman between Adobe and the community at large, Adobe may have more incentive to keep us in the loop. I obviously don't mean that everything would pass through this group, but we could offer to be somewhat of an ambassador for both parties. Part of what we're doing here is obviously trying to represent the general community's needs and concerns to Adobe, but I think we could also be very valuable to Adobe if we were to voice support for and help to further explain decisions they make. In other words, I think if a majority of the members of this group publicly advocated (via our blogs, speaking engagements, etc.) in support of a decision the Flex Team made, the general community would be more likely to view it favorably. I think positioning this group in that way (at least in part) to Adobe is one of our best chances to be granted the access and input we're hoping to obtain.

Ben