Skip to content

Decide if Blossom is a SproutCore 3 candidate. #746

Closed
erichocean opened this Issue Mar 12, 2012 · 30 comments
@erichocean

Update: the votes are in, and by a vote of 7:1, Blossom will not be the basis for SproutCore 3 at this time.

https://github.com/fohr/blossom

See the announcement here: https://groups.google.com/d/topic/sproutcore/q_oCL0dzJTw/discussion

@erichocean

Here's what I mean by a "SproutCore 3 candidate":

  1. That the Blossom codebase is intended to be the basis for SproutCore 3. As a reminder, it's based on the 1.4.5 runtime, has the statechart framework from 1.8 and the datastore framework from 1.8.

  2. That the node-based buildtools in Blossom will be further developed to support the existing SproutCore project structures. Right now, the buildfile is manual (it doesn't automatically know that a folder in, e.g. 'apps' is an app).

  3. That the community will work together to bring forward those features in SproutCore 1.8 that we want to continue with in SproutCore 3. I have carefully maintained all of the code from SproutCore 1.4.5 so that this can be done.

  4. That the license for Blossom would be changed to MIT. I am not attempting to change SproutCore to a GPL'd project.

@topherfangio

I would propose to break this into multiple, smaller issues. For instance, I think almost everyone is in agreement that the new build-tools should be created using Node.js, most people are in agreement that 1.4.5 should be the new foundation (although not everyone), and it seems to be very split on whether or not the view layer should be merged.

Does splitting this out help the discussion?

@workmanw
SproutCore member

I think that we, as a community, have to slow things down a bit. We have to realize that our target is for enterprise apps and people writing enterprise apps don't like frequent changes. Their applications are large and frequent upstream changes can be very problematic. Whatever we do from now on, has to be slow and provide an easy migration path.

I, personally, am not in favor of canvas based views in SproutCore proper. My personal opinion is that as HTML5 support improves, we'll want our views to be based on DOM elements. Again my personal opinion.

I think moving back down to SC 1.4.5 runtime is likely to break application that were written on SC 1.6+ and I see that as problematic. I do like the idea of node based build tools, however we have to find a way to support SASS as closely as possible for those who have custom themes. Saying to users, too bad you wrote that custom theme, now you have to rewrite it because we're switching build tools is not acceptable. Integrating with something like LESS would be acceptable IMO.

Lastly, I think we still have a lot of issues and clean up to address before we're ready to take SC into any sort of direction. @erichocean you've have been the most vocal about issues introduced in SC 1.6+, it would really be of value if you could provide a list of those issues so they could be evaluated and fixed. Just saying "problems with runtime" does not cut it.

So at this time my over all vote would be not to switch to 'Blossom' as the next version of SC for reasons outlined above.

-1

@dcporter
SproutCore member

Agreed that the node.js discussion is a much less controversial one to have than the canvas view layer discussion. If Erich needs a black-and-white decision on whether Blossom should be accepted whole hog as the codebase for the future of sproutcore, then I am adamantly against. If he's willing to split the conversation then we should do so.

@erichocean

@dcporter The buildtools are already MIT, at the community's request. They can be pulled in now without even consulting me. They've been MIT-licensed since the user group meeting in January.

@dcporter
SproutCore member

That's great news! Thanks for doing that, and for your hard work on that front. Hopefully an effort can be undertaken to begin integrating that. (I'd love to jump on it, but I'm no build tool expert, and I'm very busy at my new job.)

I maintain that moving to a canvas-based view layer is a bad idea. Having a canvasy SC.View subclass could be very very interesting, and there's no reason to not reimplement certain views as canvas elements with appropriate fallbacks (see for example SC.ImageView). But the decision to deprecate the entire view layer in favor of something new is a big one, and it needs a seriously compelling reason. I haven't heard that yet; Erich, can you state (or restate, in which case I apologize) your technical justification for this switch?

I'm also curious to hear your beef with the 1.6+ runtime. =) What specific areas are troubling?

@erichocean

@dcporter "But the decision to deprecate the entire view layer in favor of something new is a big one, and it needs a seriously compelling reason." The existing SC view layer would not be deprecated or eliminated. The canvas stuff is in addition to whatever SproutCore does with its views today.

Regarding my beef with the 1.5+ runtime, I'll defer to @etgryphon on that. He's one of the three SproutCore "project owners" and has the same objections as I do.

@dcporter
SproutCore member

Erich, thanks for the clarification. That should focus the discussion a little. @workmanw, does this change your thoughts regarding slowing down? I would think that it's less of a speed problem if it's an additional capability rather than a break with backwards compatibility?

@geoffreyd

@workmanw You do understand the concept of a "Major Version" don't you? It essentially means 'we have breaking code' or 'we have some major changes' ... if neither of those are true, then you also get dislike from the same enterprise groups you are trying to target, because you've now become stale.

Why are you so strongly opposed to someone proposing a very valid option, who is also saying that they are willing to work with the community to make sure there is as smooth an upgrade path as possible ... to even pause and consider the option, rather than just flat out refuse it?

It's not even like progress on 1.X branch needs to stop, or even slow down (if that's possible). But your denying these enterprise customers something that makes there apps even easier to write. Why not let that be part of SproutCore, with the option for how they want to write there views.

You keep asking for reasons as to why. I've seen plenty of strong reasons for why, but very few (valid reasons) as to why not.

@hvgotcodes

If the existing view layer is left intact, then there is really no issues to bringing Blossom in, IMHO. Enterprise users have their API stability. The bleeding-edge types can play with something new, refreshing, and powerful.

I'm wondering what is really going one here.

At the DC meetup:

I remember Erich offering to build out his proposal.

I remember discussion around building it in such a way so as to be as unobtrusive as possible.

I remember discussion of pulling Blossom in under these understandings.

Erich has done all this. It seems like certain members are just shutting this down, and I'd like to know why.

It's a shame since this seems like the best way possible to keep the technology as stable as possible, while at the same time greatly advancing the state of the art.

@workmanw
SproutCore member

@geoffreyd Of course I understand the concept of major version, please do not patronize me. My concern with regards to moving quickly is that it creates a lot of uncertainty. SproutCore 2.0 was suppose to be the next major version and the out come of that created a large amount of uncertainty surrounding the framework and divided the community. It is my belief that if we announce SproutCore 3.0 as Blossom we will generate more uncertainty about the framework and cause users to steer clear of SC all together.

Additionally, I've expressed that it is my opinion that canvas based rendering is not the best approach forward. I feel that as HTML 5, CSS 3 and other web standards and their support continue to evolve we'll want to keep up with that as best as possible. These are just my opinions, I do not own a crystal ball and cannot say for sure what will or will not happen. I respect that you have your own opinions and I would appreciate the same curiosity.

I'm not denying enterprise customers anything. If they feel that Blossom is right for them, then by all means they can use it. I've never once said that Blossom should not exist. I just don't think it's the best path for SC to move forward on.

The only reason "as to why" I've been looking for is why base it on SC 1.4.5. What exactly is wrong with SC 1.5+. And thus far I have not received any sort of explanation aside from "runtime changes". This is a proposal for "the future of SproutCore" and I'm asking for clarification on part of the proposal. What is so wrong with that? Is there anything actually wrong with SC 1.5+?

@hungle
hungle commented Mar 13, 2012

@erichocean I am thrilled that you have decided to change the license to MIT! Keep up the great work!

I am pretty much in agreement with everyone else that we should pull in as much of the work that Erich has done as possible but I would say temporarily leave out the view for now. I am very interested in the canvas based view that Erich has been working on but having two very different approaches of constructing the views that are not compatible with each other in one framework will just end up in confusion. Unless, of course, I am mistaken and you can mix and match views from the HTML/CSS approach with the canvas approach.

My feeling is that progress should be made to stabilize the current SC 1.X and fixing the large number of issues outstanding, while keeping an eye out on how to make SC less dependent on a specific rendering method and with the possibility of extracting the current view system out into its own package. The users can decide which way they want to go.

@workmanw Can you elaborate on what you dislike about the canvas approach?

@jrogelstad

Based on the DC meeting and other conversations I had been optimistic that the Blossom beta would be warmly received once there was code to look at. Now there is code to look at and that seems to have only further fanned the flames of controversy. I understand that not everyone has had time to look at the code, but the controversy here is whether the idea of incrementing to a new major version that is based upon the introduction of canvas views and clean up work Erich has done is fundamentally a good idea. That is surprising to me because I thought bringing in code that would enable SproutCore to work universally on mobile, desktop and browser environments would be a no-brainer. I shouldn't be surprised, though, because the fact is that SproutCore is several years old now and with or without Strobe it has institutional momentum that makes it difficult to introduce major changes quickly.

I am most certainly for making Blossom the basis of SproutCore 3.0. SproutCore and Blossom could potentially both benefit from being merged together in the established community, but I think it's fine for the core team to say this direction is just too different, that a sub group of special interests is pushing it (including my own), and it's probably best if Blossom continue on its own path. There is no sense in pressing this issue if it is just going to create ongoing hard feelings in much of the community which is what seems to be happening here. This is after all the beauty of open source: that no one needs to be either coerced into or denied anything. Anyone can just go off in another direction and that's okay.

@dcporter
SproutCore member

I understand the frustration of the Blossom folks who came out off the DC meeting expecting a different reaction than they're now getting from the folks who weren't at the DC meeting. That's no fun and I'm sorry. That having been said, those of us who weren't there do have questions and we appreciate the answers we've been getting.

I have a question about the compile-to-native feature: is that compatible with the existing view layer, or would a developer have to use the new canvasy views to take advantage of it?

@hvgotcodes

from what i understand the existing view layer is NOT compatible with the native runtimes. In the whitepaper, Erich points out that one advantage of canvas is it's easy to translate its API calls to native runtimes. I don' t think the same is true for dom based views.

Erich will correct this if I am wrong.

@erichocean

@hvgotcodes is correct. Blossom (today) only includes the code from SproutCore (plus the new view layer code) that is compatibile with the application running on the native runtimes. Basically, no developer-written HTML/CSS.

If Blossom were to become SproutCore 3, then of course we'd need to bring forward the DOM-related view code from SproutCore 1.8. That code would not work on the native runtimes, but the vast majority of SproutCore devs are currently targeting the browser only, and aren't (currently) interested in the native runtimes, so it's not an issue for them.

To answer @hungle regarding "mixing and matching views", you could definitely do that in SproutCore 3. Nothing about basing SproutCore 3 on Blossom would force any developer to abandon HTML or CSS, nor would the development experience for people who like and want to use HTML/CSS be sub-standard or in any way second class.

@mitchless

That the Blossom codebase is intended to be the basis for SproutCore 3. As a reminder, it's based on the 1.4.5
runtime, has the statechart framework from 1.8 and the datastore framework from 1.8.

Before throwing away the 1.8 runtime, I would like to know what is wrong with it in detail. I have seen general statements regarding the mobile/touch support Strobe added and Apple's changes. Without specifics I cannot evaluate this solution, and I am reticent to throw out code that I and others have built upon.

That the node-based buildtools in Blossom will be further developed to support the existing SproutCore project
structures. Right now, the buildfile is manual (it doesn't automatically know that a folder in, e.g. 'apps' is an app).

I think there is wide-spread support for node-based build tools. The challenge is in bringing the theme support from Abbot into those tools

That the community will work together to bring forward those features in SproutCore 1.8 that we want to continue with
in SproutCore 3. I have carefully maintained all of the code from SproutCore 1.4.5 so that this can be done.

Here again, I take issue with this approach. I prefer to identify that which is broken or suboptimal in 1.8 and build from there rather than tossing it and starting over.

To sum up, a canvas-based or native translatable view layer is very interesting but restarting work at 1.4.5 is a deal-breaker for me.

@juanpin
SproutCore member
juanpin commented Mar 14, 2012

WOW. I though the 1.4.5 discussion was closed, @erichocean I still know of more companies that live in 1.6+ than 1.4.5, Actually there is one with MILLIONS of users, I wonder if they will roll with that. Unless you deliver more concrete proof that 1.8 is un repairably flawed then this discussion is just silly.

The idea of canvas views is really cool. What concerns me the most is accessibility and that is a killer as no screen reader can read text rendered in canvas.

-1

@erichocean

Canvas accessibility has already been addressed by the W3C and Blossom. The basic approach is outlined here: https://github.com/fohr/blossom/wiki/Accessibility-with-Blossom's-Canvas-based-UI

This discussion is for SproutCore 3, not for 1.8, 1.9 or later. The community can bring forward as many features to SproutCore 3 from 1.8 as they want (we'll just be leaving the bugs and bloat behind).

@juanpin
SproutCore member
juanpin commented Mar 14, 2012

So the approach for accessibility is to use DOM shadow, which was only recently included to webkit..? so what about older browsers. I think by the time Blossom is ready, the benefit of doing canvas views will be already gone as browsers will be fully hardware accelerated ( no css gimmicks) and you still have to use HTML/DOM shadow to support accessibility.

@publickeating
SproutCore member

Just a couple comments of my own.

As I've said in many previous discussions, I believed that we had to get our own house in order before we could consider any big changes for SproutCore and I'm glad that we've made some progress to that end by getting 1.7, as 1.8, finally capped off. So although we need to continue much more cleaning, bug fixing and community building, I think it's an okay time to start thinking about the next version.

Anyway, I haven't had time to review Blossom, nor Ember for that matter and yes, Ember is something that we need to evaluate as well. For example, I believe Charles Jolley rewrote the runtime which was intended for SproutCore 1.x to use, so that's something we need to explore. The real question in my mind though is what is the opportunity for SproutCore in the future? I don't think we'll discover that in this thread, but I will open another issue to attempt to answer that.

I believe that if we decide where the opportunity is for us to be, then we can better judge how this approach may or may not get us there. That's about all I can add at this time and since this is a big issue, I think it will have to stay open for a while and probably be broken up into smaller proposals for voting.

@topherfangio

@publickeating Thanks for your thoughts/comments. I agree that we need to be thinking about what SproutCore wants to do, and where it wants to go. Would you mind adding a link here to the "future" issue when you've created it?

@kswenson

I suspect everyone would agree that a SproutCore 3 (or whatever it's called) that provides a path forward for all SproutCore users is a worthy goal. In particular, such a unification should provide a sensible migration path for those still using 1.4 and those currently using 1.5+. Stepping a bit further out on this limb, I would posit that most of us would agree that adding a native deployment option to SproutCore would be a great addition -- if we didn't have to give up anything (or too much) to get it. We like to have our cake and eat it, too, like anyone else! It seems to me that what is being proposed is really an implementation question. Erich believes that a SproutCore 3 unification should be based on SproutCore 1.4.5 with the "useful" additions from 1.5+ back-ported as appropriate -- and he's offering native deployment via Blossom as an incentive for backing his position. Others believe that such a unification should be based on SproutCore 1.8, with any bugs fixed and instabilities ironed out. I don't know how to sensibly evaluate these options without more detailed information on how much work is involved in back-porting the useful additions from 1.5+ and/or in fixing the bugs in 1.8 so that it is as stable as 1.4.5 is purported to be. Erich clearly believes that the former is more tractable than the latter, but for most of us that's not so obvious. As a SproutCore developer (currently using ~1.7), I don't particularly care whether SproutCore 3 is based on 1.4.5 or on 1.8, as long as it provides a reasonable migration path for my code.

@sevifives

There are some performance incentives, but I'm really confused why Blossom can't remain as a framework SC can access.
If it can only run on 1.4.5, then make that a stipulation. I don't see what the huge deal is. There's more power, from my perspective, in the CSS/HTML layer now and in the future than might be beneficial in trying to maintain two very, very, very different types of views and all the novelties each would bring.

I like the promise of Blossom, but it requires dumping a lot of work, a complete rebase to an older branch plus back-porting any significant underlying changes.

The 1.4.5 branch isn't going away anytime soon for a variety of reasons. If the call is to, at some point in the future, roll back to 1.4.5, then the perk is that Blossom will work with it.

1.4.5 is... an enterprise addition. I forget who coined it that way around me, but credit to them or all of them.

-1

@erichocean

Thanks to everyone for giving your input. There are 12 individuals who are currently guiding the SproutCore framework, listed here: https://github.com/sproutcore/sproutcore/wiki/List-of-Collaborators. Here are their votes so far:

Project Owners

  • charlesjolley (Charles Jolley) [Honorary] – ?
  • etgryphon (Evin Grano) – ?
  • juanpin (Juan Pinzon) – NO
  • publickeating (Tyler Keating) – NOT NOW, NEED MORE INFORMATION

Reviewers

  • FrozenCanuck (Michael Cohen) – ?
  • geoffreyd (Geoffrey Donaldson) – YES
  • onkis (Mike Ball) – ?

Committers

  • geojeff (Jeff Pittman) – NO
  • mauritslamers (Maurits Lamers) – ?
  • mitchless (Mitch Oliver) – NO
  • sevifives (Jason Dooley) – NO
  • tim-evans (Tim Evans) – NOT NOW, NEED MORE INFORMATION
  • workmanw (Wesley Workman) – NO

By my count, that's 7 in the "no or not now" category, and only 1 in the "yes" category, with 5 unknowns. So even if all remaining individuals voted yes, Blossom would still not be a candidate for SproutCore 3 at this time.

@publickeating has indicated he wants to continue the discussion on what SproutCore will become as a separate issue. Since Blossom as a candidate for SproutCore 3 is now dead, I'm closing this issue; further discussion of SproutCore's future should continue on the new issue once it's created.

Thanks to everyone who participated! It's been a wild 4 months getting Blossom to it's beta release, and the first release candidate is still on schedule for April 1, along with the first two native runtimes: iOS and Mac OS X.

If there is still interest in making a straightforward migration path from SproutCore 1.4.5 apps to Blossom, head on over to the #blossom channel on IRC and let me know. I have a few ideas on how to make that happen.

Best, Erich Ocean

@erichocean erichocean closed this Mar 14, 2012
@tim-evans
SproutCore member

Umm, I didn't actually say no.

I'm acually with @publickeating on this one. It looks really promising, but we have tons of housecleaning and optimizations to do to bring back the speed that people expect to SproutCore.

@workmanw
SproutCore member

@erichocean It is my plan to continue, as Tim put is, "housecleaning and optimizations" over the next few months. This is your chance to speak up about problems with SC 1.8. I promise to review every single complaint you, and anyone else, may have regarding SC 1.8 and do my best to resolve as many as possible. This is your chance to speak up about issues you see with SC 1.8. I would encourage everyone else to do the same.

@nedlilly

As the CEO of xTuple, a company that's working very closely with Erich to bring Blossom to market, for the purpose of porting our Qt-based ERP, CRM, and accounting app, let me add a note or two here. We've been quiet lurkers for over a year, but had our first coming out party in working with @etgryphon and Eloqua to host the DC meetup in January.

We will be rolling out our new product at the Open Source Business Conference in May, of which we're a gold sponsor, and we'll be doing a panel discussion on the process we've gone through in building this product and working with various elements of the SproutCore community. Clearly, the contents of that talk are being determined on a daily basis here. You can see the optimistic preview description of our talk here: https://www.eiseverywhere.com/ehome/31601/50199/?&

Our hope is that people will accept Blossom on its merits, identify any issues with compatibility of code between 1.4.5 and 1.8, and address them surgically. There has been much discussion of the problems introduced into the code during that time, and if people haven't yet seen that discussion, hopefully someone can post the appropriate links.

Here's what I know: In developing Blossom, Erich has bent over backwards to ensure that it could be merged back into SproutCore with minimum fuss in the future. Note that no one is saying when in the future; we're not disagreeing with the concept that the community needs to do more housecleaning and consensus building. I can tell you that we discovered today that with all that future-merge code removed, the Blossom code base is cut in half. (Of course it can be added back at any time). Note also that in all his comments, Erich has pointed out that you're not locked in to the canvas stuff, and that other views would of course be available. We're really trying hard to do the right thing here.

As xTuple goes forward with its plans, we would love to say that we've worked with the SC community to get this outstanding code in the go-forward plan, be it SC 3 or whatever. I would rather get up there and talk about building consensus, and following the standard practice of letting the code do the talking - right now, ISTM that a lot of people who are weighing in on this issue haven't even bothered to review the Blossom code. You should. We have made a significant investment in Erich's work on this, and it is really paying off. I should also note that everything we're paying for is being made available under open source licenses.

We're moving ahead on a very aggressive schedule. We will be demonstrating a full Blossom-based release of xTuple 4.0 with all our existing CRM and Accounting features, and we'll be showing it on multiple Windows, Mac, and Linux browsers, as well as compiled native apps for iOS and Android. Throughout this whole process, we will continue to actively solicit community feedback, and do everything we can to keep Blossom from becoming a fork. I think that would be a real tragedy for a community that is just starting to regain its footing after the Strobe and Ember situations. If anyone would like to talk with me privately about this, please feel free to contact me at ned (at) xtuple (dot) com; you can also connect with @jrogelstad who is a regular here and on IRC.

Thanks to everyone whose passion and hard work has brought SC to where it is today. Please let us work with you to keep it moving forward.

@dcporter
SproutCore member

Thanks for your insight Ned.

(This post is mirrored from the google group.) There's obviously a lot of controversy at the margins here, which eschews the amount of impressive work you've done here.

What about splitting the node build tools project out as a separate effort? Blossom can then benefit from the work that this community would in theory put towards it. (You've already MIT'd this work, so I suppose it's up to us now to push that forward. Would you agree?)

Then, if Blossom is basically just SC (albeit 1.4.5) with a sweet-but-different new view layer, would it be feasible for you to pursue Blossom as a SproutCore framework (the way Animatable used to be, and the way I think handlebars should be)? That would allow you to continue your work, maturing the compile-to-native feature that canvas brings to the table, and building your business on it. Then, if demand for a mature compile-to-native view layer in SC matches the supply, later on you can bring this back around as a framework to merge with SC rather than as an overly-controversial base for building SC3.

Again, since nobody has yet taken the time to tell those of us on the internet about why 1.6+ is seen as unsalvageably bad in some corners, I'm speaking without a great deal of technical understanding here. But I don't see much difference between your potentially awesome compile-to-native layer and, say, handlebars (that is to say, a view layer with different requirements and an incompatible API that lives perfectly happily alongside the main SC view layer). And it's clear you've put a lot of good effort into this. So I guess I'm just wondering if it's possible to get some cake to eat and some to look at.

And for the love of tim would somebody PLEASE explain what's the major malfunction with 1.6+.

@jrogelstad

Ok, I'm going to post this here with the qualification that I am a bit out of my depth on this subject, and I am simply parroting what I've heard some in the know have said in meetings and on chat rooms, but I guess isn't posted anywhere in full public view. Hopefully I can at least get the ball rolling.

The #1 problem as I understand it is that the root responder system was badly degraded in the move to 1.5 due to an effort to support mobile/touch that is basically unviable. Originally, root responder was written to more or less mirror Cocoa's 20 year old implementation and it was around 400 lines of code. It looked like this:

https://github.com/sproutit/sproutcore/blob/8c54dc5a319e402e86319e5a98c21d16744200d8/frameworks/foundation/system/root_responder.js

now it looks like this:

https://github.com/sproutcore/sproutcore/blob/master/frameworks/core_foundation/system/root_responder.js

Notice the code blew up form 400 lines to over 2200, a lot of it to deal with mobile support, and some of it to solve problems that should have been solved another way without touching this code. Root responder is central to SproutCore and this change severely degraded SproutCore's performance. Furthermore, it was invasive with far reaching impact that, like a cancer, spread bugs throughout the framework which have had to be dealt with. Worst of all, the mobile support in the end was never commercially viable, and basically abandoned.

There are major implementations of SproutCore that can not be upgraded past 1.4.5 because of the problems introduced by this major change which, as I understand it, was never fully reviewed outside of Apple who developed it. So for those who are worried about breaking existing users, that has already happened.

The argument by those who have described the impact of this change to me (and it isn't just Erich) is root responder is not fixable. It needs to be completely removed, and the only practical way to do that is to go back to the way it was in 1.4.5, import the "good" changes made since then, and then move forward. This is what Erich proposed months ago, has done with Blossom, and proposed again for SproutCore 3.0.

Other unfortunate changes in 1.5+ include

  • render delegates, which also introduce inefficiencies and complexity
  • the introduction of template views, which don't really fit in the SproutCore paradigm. Most of that thinking has moved to the EmberJS project.
  • A byzantine reorganization of folders and files that splits classes up needlessly.
  • half finished and broken views like tableview, master/detail view, greenhouse, and navigation view.

A lot of people have said they understand cleanup is necessary. The trouble is having people all over the globe hand pick through all this code and vote on everything is going to take forever, and this area of technology is moving way too fast for that. Erich has done most of the work already with input from a small team of folks who really know SproutCore. Like him or not, Erich knows SproutCore like the back of his hand and understands the issues. He wants you to judge the Blossom code on its merits for yourself, but if you don't have time to sort through it all, well then you just kind of have to trust him. Erich has been working with SproutCore since 2007 and has had a major hand in much of its current design. He knows what he's doing. Blossom solves the mobile problem once and for all in a whole new way with canvas view.

I understand this presents a real conundrum for the community that doesn't want to find itself dominated by one individual, and the individual that doesn't want to be held back by a nascent the community that is still trying to figure out what exactly it is they have inherited. I don't know what the political answer is here, but I hope this response can at least help clarify the history a little bit for folks who have been asking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.