Adobe plaatst broncode Flex weer achter slot en grendel

Adobe zal de eerstvolgende versie van Flex niet langer geheel open aanbieden. De open sdk, waarmee Flash- en AIR-applicaties kunnen worden gebouwd, zou in botsing komen met het werk aan de gesloten runtimes van beide Adobe-producten.

Deepa Subramaniam, product manager voor de Flex-sdk bij Adobe, heeft laten weten dat de public repository wordt gesloten. Ook patches die vanuit de Flex-ontwikkelgemeenschap worden aangedragen, worden niet meegenomen in de eestvolgende versie van de sdk. Deze draagt codenaam Hero en krijgt onder andere ondersteuning voor mobiele versies van Flash.

Volgens Subramaniam is het voorlopig niet mogelijk om Flex open te ontwikkelen, omdat het werk momenteel niet goed is te combineren met de in-house-ontwikkeling van de Flash- en AIR-runtimes. Beide zijn closed source. Zo zouden de huidige builds van de nieuwe Flash-runtimes nog niet rijp genoeg zijn om te worden vrijgegeven voor het publiek, zo schrijft The Register.

Het besluit om patches voorlopig niet te accepteren zou zijn ingegeven door een moeizaam implementatieproces bij Adobe. De softwarefabrikant wil eerst kijken hoe dit traject is te verbeteren voordat patches vanuit het publiek weer in de broncode van Flex worden verwerkt. Hoewel Subramaniam zou hebben aangegeven dat de opensourcestructuur van Flex twee releases verder vermoedelijk wordt hersteld, toont het huidige besluit aan dat het voor Adobe moeilijk blijft om zijn opensourceprojecten met de gesloten AIR- en Flash-producten te combineren.

Reacties (53)

[ipaqlinux48]

Spijtig, was misschien wel een kans geweest om Silverlight naar de toekomst toe te verdringen.

Ik zeg niet dat Silverlight beter/slechter is dan Flex, maar het is wel zo dat er achter Silverlight enorm veel meer resources (lees programmeurs) zitten dan Flex.

[PPie]

Microsoft zelf heeft gezegd dat Silverlight niet de toekomst is voor het web, maar dat daar HTML5 voor gaat zijn.
Zie nieuws: Microsoft: html 5 en niet Silverlight is cross-platformtechniek

Ik denk dus dat Microsoft hun resources richting HTML5 gaat bewegen.
Ook Adobe is daar al mee bezig, ze hebben een Flash -> HTML5 conversietool:
http://blogs.adobe.com/jn...tml5-conversion-tool.html

[Apache]

Waarop baseer je dat?

Flex is sterk gericht naar de java community en enterprise development, waar het toch wel redelijk is aangeslagen.
Ik denk dus dat er emer serieuze resources zitten achter flex dan achter silverlight wat naar wat ik zie nog niet echt voet aan de grond heeft gekregen.

Verder vind ik dit zeer jammer, ik weet hier welke features ze bedoelen waarom ze de flashplayer momenteel niet in sync kunnen laten lopen en welke delen ze momenteel specifiek niet kunnen commiten en wat voor de problemen zorgt.

Ze zouden beter gewoon open kaart spelen over die feature en hem nu voor testing ter beschikking stellen, zo wereldschokkend is het helemaal niet.

Door NDA's kan ik niets vertellen buiten dat Silverlight het al wel heeft ...

[MSalters]

Ik denk dat je met "Java Community" meteen het pijnpunt te pakken hebt. Oracle is eigenaar, en die hebben zeker resources, maar gaan ze die ook voor Flex inzetten? De rest van de community wantrouwt Oracle en zal zeker geen resources gaan inzetten als Oracle vervolgens het eigendom op Flex kan opeisen.

Microsoft heeft dat probleem niet. Ze hebben de resources, moeten iets nu Windows in belang vervaagt en IE verdwijnt, en hebben geen ruzie met de community. Toegegeven, da's ook omdat die community fundamenteel anders in elkaar steekt.

[Verwijderd]

Kunnen al die resources er niets eens voor zorgen dat silverlight behoorlijk beschikbaar is onder Linux? (Beetje irritant dat ik niet fatsoenlijk een uitzending terug kan zien onder linux zonder allemaal vage wine/mono achtige hacks uit te hoeven voeren.

[mvdejong]

Nadat verschillende grote spelers in de Markt al bezig zijn met flash af te branden, gaat Adobe zelf nu ook nog eens een behoorlijke groep fanatieke aanhangers tegen zich in het harnas jagen.
Bij HTML-5 kunnen ze de champagne opentrekken.

[HerrPino]

Het duurt nog wel een heel aantal jaren voordat HTML5 volledig gespecificeerd en vastgelegd is. Heb mensen horen zeggen en gelezen dat dat nog wel eens tot 2020 zou kunnen duren.

[i-chat]

dat hangt ook af van de huidige webontwikkelingen. als flash vandaag vermoord wordt (door de gemeenschap) en alle webonwikkelaars en os ontwikkelaars besluiten geen flash support meer te leveren in hun browsers en ander platformen, zal er vermoedelijk nog in 2011 een html 4.5 standaard worden afgesproken. waarin de meest triviale html5 functies alvast worden opgenomen.
Je hebt dan kanst dat ze bijvoorbeeld een <video codec='$name'> constructie zullen gaan aanhouden waarbij je dus als 'eindgebruiker' zelf verantwoordelijk bent voor het installeren van de geschikte codecs... zodat ze de controversie rond die tag nog even uit de weg kunnen gaan...

in de huidige vorm en met de juiste inspanningen (noodzaak) kun je in no time alvast een tijdelijke oplossing op tafel krijgen.

[Simyager]

*zucht* Maar met HTML5 kan je heel Flash nog niet vervangen. Alleen op video gebied. Zelfs daar werkt het nog niet perfect aangezien je niet kan kijken voordat de hele video is gedownload.

Dus het streamen gaat lang niet zo lekker met HTML5 dan met Flash. HTML5 is sowieso al lang nog niet echt nog vastgelegd en mensen schreeuwen nu al moord en brand tegen Flash.

Ik geef toe soms is Flash echt ronduit bagger, maar helaas heb ik het wel nodig om videos en andere interactieve sites te bezoeken.

Je kan veel doen met PHP,HTML5,etc. maar lang niet alles, want dan hadden we geen eens Flash meer namelijk.

[DeuTeRiuM]

Maar met HTML5 kan je heel Flash nog niet vervangen. Alleen op video gebied. Zelfs daar werkt het nog niet perfect aangezien je niet kan kijken voordat de hele video is gedownload.

Niet waar. Het ondersteunt geen 'streamen', dat is wat anders... in deze context althans. Groter probleem is het codecs verhaal.

Je kan veel doen met PHP,HTML5,etc. maar lang niet alles, want dan hadden we geen eens Flash meer namelijk.

PHP heeft niks met flash te maken... dat is server side.

HTML5 standaard is nog een draft. Flash is niet een standaard, maar 1 bedrijf dat het maakt, dus daarmee een soort van standaard. De opensource implementaties zijn een tikje karig, dat reverse engineeren is niet echt ideaal. Gelukkig gaat dit veranderen.. adobe heeft zelfs een tool gepresenteerd waarmee je flash naar javascript kan omzetten. Adobe zal uiteindelijk de Flash IDE wel ombouwen, of iig een compiler javascript toevoegen.

[Reactie gewijzigd door DeuTeRiuM op 22 juli 2024 14:15]

[max3D]

Toevoeging:
dat tool is geintroduceerd door Adobe zelf zoals je kan zien op het blog van John Nack (adobe werknemer, maar wel bekend van zijn oude werk als freelance met rich content flash sites voor grote bedrijven). Zie hier http://blogs.adobe.com/jn...tml5-conversion-tool.html

Daar staat ook een filmpe dat de conversie laat zien. De discussie op het blog is ook wel amusant en verheldert wel veel dat vaak niet tot mensen doordringt.

Adobe is NIET geinteresseerd hoe je hun content tot je neemt zolang als je hun content productie tools maar koopt. Het is een misverstand dat ze een vendor lock op Flash player willen oid., want daar verdienen ze niets aan. Ze willen bruikbare content voor het weg genereren en verkopen daartoe een lijn produkten. als je met Java (lang geleden) of met HTML wil afleveren bij de client maakt hun niet uit.

Omdat er weinig populaire alternatieven zijn en HTML5 tot nu toe niet uitgekristalliseerd is tot een alom bruikbaar interactieve standaard (zelfs de video tag is door de codec ruzie nog niet gesettled) zullen ze Flash players uitbrengen, maar het is niet hun core business en dat weten ze zelf heel goed. Zie dat blog.

[ZpAz]

Niet waar. Het ondersteunt geen 'streamen', dat is wat anders... in deze context althans. Groter probleem is het codecs verhaal.

HTML5 ondersteund wel streaming hoor, zo kan je de keynotes van Apple live volgen via HTML5.

[PPie]

*zucht* Maar met HTML5 kan je heel Flash nog niet vervangen. Alleen op video gebied. Zelfs daar werkt het nog niet perfect aangezien je niet kan kijken voordat de hele video is gedownload.

Dat kan zeker wel. Apple gebruikt dit bijvoorbeeld voor de Keynotes.
Die worden gestreamed.

Tevens, wat is het overgrote deel van het Flash gebruik?
Filmpjes afspelen!
En dat kan zeer goed met HTML5...

[erikdenv]

Er zijn veel Flash-spelletjes, het zijn vaak simpele spellen maar mijn kinderen (6 & 9 jaar) spelen ze graag.

[i-chat]

daar heb je dan weer de canvas tagg voor... html5 blog van crisp hier @tnet laat daar mooie voorbeelden van zien (html5 browser wel vereist).

[zeemeerman2]

Apple gebruikt niet echt html5 voor streaming als ik me niet vergis. Ze gebruiken ergens een technologie die te vinden is in QuickTImeX, waardoor je de filmpjes niet kunt streamen in 10.5 Leopard of Windows. En die OS'en kunnen welzeker html5 aan!

[MaestroMaus]

Ik heb in de opensource gemeenschap nog nooit fans van Flash gezien tbh. Veel van die mensen gebruiken Linux en Adobe krijgt het niet voor elkaar om een fatsoenlijke plug-in daarvoor te schrijven. De ontwikkelaars bij Adobe hebben blijkbaar ook een hekel aan Linux: http://www.phoronix.com/s...?page=news_item&px=NzkyOA en http://www.phoronix.com/s...?page=news_item&px=NzkzMw.

Zelfs de reverse-engineered plug-ins die maar een beperkt aantal features hebben werken beter dan wat Adobe aan de Linux gemeenschap geeft.

Nee, de meeste mensen in de opensource gemeenschap zullen zowel Adobe als Flash niet missen.

[i-chat]

tja, adobe en opensource - dan zie ik apple dat nog eerder doen ... en apple hoe goed hun producten volgens veel aanhangers dan ook zijn, staat nu niet bepaald bekend als "het open platform'

of om het in één twit te zeggen: #adobe @ #!opensource #fail waz te verw8& @lol

[dev10]

Toch doet Apple behoorlijk wat met opensource. Zo is Darwin, de basis van Mac OS X gewoon opensource.

WebKit, door Apple geforkt van KHTML, is ook gewoon open-source. Met name de laatste is wel heel netjes dat ze dat gedaan hebben. (Ze moesten ook wel, vanwege de fork van KHTML)

[Verwijderd]

Zowel Darwin en WebKit zijn forks van bestaande OSS projecten (FreeBSD, NextStep en KHTML), dus in dat opzicht doet Apple wel wat MET opensource.

Het probleem, voornamelijk met WebKit, is dat bugfixes en features niet teruggemerged worden naar KHTML, in dat opzicht doet Apple dus niets VOOR opensource.

[Digistorm]

Webkit wordt ook dankbaar gebruikt in onder andere Chrome en Android, dus in zekere zin dragen ze wel bij aan "het software welzijn van de rest van de wereld" ...

[PPie]

Als KHTML geforkt mocht worden volgens de licentie, maakt het niet uit dat er dan een 2e versie gekomen is die WebKit heet.
En WebKit is open source en wordt ondertussen nogal veel gebruikt, dus daar hebben ze zeker bijgedragen...

[i-chat]

das niet helemaal waar, webkit is zelf opensource het terug mergen is niet verplicht. volgens de GPL, forken mag ook en dat doet apple. niets staat khtml in de weg om die code /fixed dan zelf te backporten.

[blouweKip]

Het probleem, voornamelijk met WebKit, is dat bugfixes en features niet teruggemerged worden naar KHTML, in dat opzicht doet Apple dus niets VOOR opensource.

Echter al die fixes en features zijn GPL dus kunnen gewoon overgenomen worden door het KHTML project..

[latka]

De dag dat NextStep opensource wordt stap ik over...

[Yakotb]

Dat komt omdat Darwin een losstaand project was, dat door Apple uiteindelijk gebruikt is.

[borft]

de caldav implementatie van Apple, de calendar server heeft apple wel van de grond af aan opgebouwd, dat is geheel opensource. Hetzelfde geldt voor de veel in unix land gebruikte prinserver CUPS, dat is ook van Apple.

Dus alhoewel Apple gesloten is op sommige fronten doen ze wel degelijk veel met OpenSource, ook in actieve bijdrages daaraan. Veel fixes/patches voor webkit hebben hun weg teruggevonden naar KHTML.

[elmuerte]

CUPS is gekocht door Apple. Pas sinds 2007 is CUPS een Apple project. De eerste CUPS versie komt uit 1999.

[Reactie gewijzigd door elmuerte op 22 juli 2024 14:15]

[PPie]

Andersom. Apple heeft de core (=Darwin) vrijgegeven, omdat ze deze gebruiken voor OS X. Ze hadden dus niet eerst Darwin, maar (Mac) OS X.

[i-chat]

darwin niet maar bsd waarop darwin gebaseerd is wel, net als webkit dat idd van khtml komt.
apple houd zich daarmee dus gewoon aan de licentie-voorwaarden. er valt hooguit iets te zeggen dat ze geen smerige (voor zover mij bekent) trucjes gebruiken om onder die licentie uit te komen...

maar ik doelde in deze natuurlijk op de volledige userland van iOS en OSX

[Wolfos]

Apple heeft inderdaad wel een vaag open source beleid ja, iOS is zo closed als maar kan, terwijl Mac OS-X ontzettend open en customizable is (iedereen zegt dat Windows zo customizable is, maar eigenlijk is het andersom want in OS-X kan bijna alles met Terminal aangepast worden.).

[Verwijderd]

Waarom Apple hierbij betrekken? krijgen we straks weer zinloze flame reacties.

Apple + open Source: http://www.apple.com/opensource/

[i-chat]

omdat ik even geen beter voorbeeld kan noemen van platformen die geslotener zijn - en daar meer kritiek over krijgen dan, (voor/door ontwikkelaars) dan iOS (van apple)..

daarmee wil ik alleen maar aangeven dat adobe het dus NOG veel slechter doet (naar mijn idee) dan waar apple vaak van wordt beschuldig. - dat is alleen maar referentiekader...

taal is een onmogelijkheid als je geen referentie-kader hebt. PUNT!

[Crazy Harry]

Dat referentie-kader met betrekking tot taal is een smoesje.
De concepten open source en closed source worden prima begrepen binnen het standaard referentie-kader van de bezoekers van deze site. Daar zijn echt geen voorbeelden voor nodig.

Daarbij krijg je alleen maar het risico, en dat gebeurde dus ook, dat je een verkeerd voorbeeld noemt. Je noemt Apple in het algemeen maar specificeert het pas in deze reactie naar iOS.
Dat terwijl MacOS X veel opener is dan bijvoorbeeld Windows (in MacOS X kan je wel degelijk als root tekeer gaan, integendeel tot wat velen denken).

Dat Adobe het dus slechter doet dan Apple wat betreft open source, is dus niet meer dan logisch aangezien Apple, zoals eerder gezegd, daar nogal actief in is.
Wanneer je Microsoft als voorbeeld had aangehaald, had je misschien nog een punt gehad, maar daar zal ik me verder maar niet aan wagen, tenslotte is een voorbeeld geven helemaal niet nodig.

[mashell]

Zijn mensen die twitter syntax buiten twitter gebruiken geen twats?

Ik kan me goed voorstellen dat zowel intern als extern aan het zelfde ontwikkelen erg lastig te handhaven is. Als je eigen code niet open is zul je soms dingen uit de community daarop moeten importeren en dat kan er lastig zijn als je de betreffende ontwikkelaar er niet bij kan roepen.

[i-chat]

dat zal best, maar het was ook wel een beetje trollerig bedoeld zowel richting adobe als richting de nieuwe 'tweet tweet' hype

[Simyager]

OK...

Ik vind het wel goed dat ze de AIR en Flash even verbeteren en helemaal op 64-bit, want zelfs op windows was AIR bij mij te huilen.

Op Linux 64-bit is Flash om te huilen, ook al was het beta. Hopelijk nemen ze nu wel de tijd ervoor om dat alles te fixen, maar ze bedoelen hier waarschijnlijk hele andere dingen mee.

[Reactie gewijzigd door Simyager op 22 juli 2024 14:15]

[simplicidad]

Apple is een van de weinige commerciële bedrijven die open standaarden omarmt imho.

* Delen van OS X zijn open source terwijl dat eigenlijk niet hoeft (BSD)
* Ze kiezen duidelijk voor open standaarden terwijl ze een "microsoftje" kunnen doen om hun dominantie in bepaalde markten te gebruiken om een <iMovie> tag te introduceren. Dat doen ze niet, ze zijn al sinds het begin lid van de WHATWG groep. Voor een bedrijf die altijd veel tegenwind krijgt dat het allemaal te maken heeft met iemand te binden aan 1 platform doen ze wel raar...
* Er is een shitload aan open source apps die patches krijgen (omdat OSX eigenlijk met vrij veel open source spul wordt verspreid)
* Ze doen ook goed werk met hun fork van KHTML (webkit) die eigenlijk in veel zaken vrij veel wordt gebruikt, ook niet in android ?
* Om ontopic te blijven mbt online GUI- ze contributen hevig aan het sproutcore framework (http://www.sproutcore.com/ - MIT license) Ze gebruiken het ook lees ik net op hun iwork.com website
* ...

Ja ze hebben een bepaalde visie mbt hun app stores (al kun je een discussie voeren of dat de versplintering van android app stores de kwaliteit echt ten goede komt - ik denk dat het gewoon een verschil is van filosofie) maar los daarvan om ze nu als een bedrijf de omschrijven die tegen open source of open standaarden is vind ik nu echt wel aan het haar getrokken.

Ze hebben laatst nog hun voorwaarden veranderd zodat ze compatible kunnen zijn met GPL 2. En ja ik weet dat VLC van de app store is getrokken nadat de FSF van zijn tap heeft gemaakt omwille van DRM. Wat raar is want de DRM clausule zit in GPL 3 terwijl VLC GPL 2 is.

Ik weet dat het al even cool is om Apple te bashen (zeker op tweakers) als het in het bezit zijn van iDevices (ik heb er maar 1 trouwens een iPad omdat ik het wachten op een android tablet beu was) maar de waarheid heeft ook zijn rechten. Credit where credit is due

[Reactie gewijzigd door simplicidad op 22 juli 2024 14:15]

[i-chat]

begrijpend lezen is natuurlijk ook een ding: als er al gebashed wordt dan is dat richting adobe. en ik quote...

staat nu niet bepaald bekend als "het open platform'

-

ok toe gegeven misschien had ik kunnen zeggen: 'heeft niet de reputatie' of 'wordt door velen niet beschouwd als' of 'wordt in kritiek vaak niet gezien als... "

maar de werkelijke troll staat toch echt in de twat... euh twiet of tweat tweet "twitterbericht"

[Keypunchie]

[offtopic]

http://www.apple.com/opensource/

en

http://www.opensource.apple.com/

Apple werkt met heel veel Open Source produkten.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 14:15]

[cornedor]

Adobe kan het niet volledig opensource maken ivm DirectX in project molehill (http://www.youtube.com/watch?v=tgwi0lWgX8w)

[Wolfos]

Dat slaat nergens op, zowiezo is DirectX alleen maar een dependency (Adobe gaat trouwens voor multi-platform en zou ook nooit DX gebruiken) maar dat filmpje demonstreert een aparte engine van een ander bedrijf.

[alienfruit]

Waarschijnlijk omdat je anders dingen zit in de nieuwe versies van AIR of de Flash Player bijv. de nieuwe 3D functionaliteit (Molehill) bijv. functionaliteit die ze nog geheim willen houden. Maar blijft het flauw vinden

[Alfredo]

Er zijn twee zaken die meespelen: nieuwe features niet onmiddellijk prijsgeven en interoperabiliteit.

Het eerste is altijd een moeilijk punt. Adobe organiseert jaarlijks het Max-event, waarop normaal gezien alle grote aankondigingen gebeuren. Vergelijk het met Apples WWDC of Microsofts PDC.
De nieuwe release van Flex 4.5 (Hero) gaat gepaard met AIR 2.5. Indien de SDK continue opensource zou zijn (de uiteindelijke release is dat overigens wel, net als de recente Preview release), zouden alle onderliggende API calls onmiddellijk gekend zijn. Dat is nefast voor de manier waarop Adobe zijn nieuwe producten wenst aan te kondigen.

Het tweede probleem is interoperabiliteit. Hero is afhankelijk van AIR 2.5 voor desktop en mobiele applicaties. Het is dan wel mogelijk om de SDK voor het grote publiek beschikbaar te stellen, maar zonder de beschikbare AIR runtime is dat compleet nutteloos. De projecten die je published, kan je namelijk niet eens opstarten.
Vroegtijdig builds van AIR en Flash Player beschikbaar maken is ook geen oplossing. Enerzijds omwille van probleem #1, anderzijds omdat de builds experimenteel van aard en niet stabiel genoeg zijn om continue met Flex uitgebracht te worden.

Het feit dat patches niet meer worden aanvaard vind ik persoonlijk ook vreemd, maar gezien de huidige situatie wel te verwachten. Adobes bug tracker voor Hero is namelijk gesloten voor het grote publiek. Omdat de meeste mensen geen toegang hebben tot de nieuwste builds, heeft Adobe waarschijnlijk besloten dat patches accepteren die gebaseerd zijn op oudere code teveel werk in beslag neemt.
De developers die wel toegang hebben tot nieuwe builds, kunnen overigens wel bug reports aanmaken en dus ook patches doorsturen. Het deel van de community dat actief patches aanbracht, is vermoedelijk ook wel aangesloten bij Adobes Prerelease Program. Dus buiten de slechte PR valt het resultaat van deze keuze volgens mij wel mee.

En tot slot, Adobe heeft wel enkele opensource projecten lopen. De as3corelibs zal voor de meeste AS3 developers wel bekend zijn, maar ze werken ook actief mee aan Cairngorm en Tamarin bijvoorbeeld. De JIT compiler van dat laatste wordt dan weer door Mozilla gebruikt in SpiderMonkey (of preciezer, TraceMonkey), hun JavaScript engine.

[jochemd]

Adobes bug tracker voor Hero is namelijk gesloten voor het grote publiek.

Adobe's bugtracker is alleen gesloten voor het grote publiek omdat het grote publiek te lui is om een account aan te vragen.

Omdat de meeste mensen geen toegang hebben tot de nieuwste builds

De nieuwste builds werden uitgedeeld op DVD tijdens de MAX. En voor de mensen die niet aanwezig waren is het wederom simpelweg een kwestie van een account aanmaken en de preview releases downloaden.

De developers die wel toegang hebben tot nieuwe builds, kunnen overigens wel bug reports aanmaken en dus ook patches doorsturen.

Bugs rapporteren kan iedereen, opgestuurde opgestuurde patches worden niet in behandeling genomen. Afhankelijk van de persoon aan wie je het vraagt is het de bedoeling om dat aan het eind van de Hero cyclus of aan het eind van de cyclus daarna weer mogelijk te maken.

Bekijk nou gewoon het officiele verhaal.

[Alfredo]

Adobe's bugtracker is alleen gesloten voor het grote publiek omdat het grote publiek te lui is om een account aan te vragen.

Bij mijn weten konden gewone gebruikers, overigens met een account, de Flex SDK Hero bugs niet opvragen. Maar het is mogelijk dat ik me vergis met de bug trackers van Panini en Burrito, die wel privé zijn. Ik zie nu in ieder geval dat Hero bugs, ook zonder account, gewoon te bekijken zijn.

De nieuwste builds werden uitgedeeld op DVD tijdens de MAX. En voor de mensen die niet aanwezig waren is het wederom simpelweg een kwestie van een account aanmaken en de preview releases downloaden.

Dat noem ik niet de nieuwste builds. De Burrito revisie van Max is 287807, een build van begin oktober. Ondertussen zit men echter aan v290900+ en lopen mensen met de release van Max dus een maand achter. In software development is dat veel. Het heeft dus weinig nut om patches te schrijven voor code die meer dan een maand oud is, terwijl de main branch actief ontwikkeld wordt. De kans dat je patch niet meer relevant is, wordt dan te groot.

[jochemd]

Je verwart de Burrito build nummers (closed source IDE) met die van Flex (open source SDK).

[Alfredo]

Nee, dat doe ik niet. Jij verwees naar Burrito om aan te geven dat mensen wel nieuwe builds konden downloaden, ik ben daar gewoon op voort gegaan. De vergelijking gaat evengoed op voor Hero hoor. De Max build is 17689, welke dateert van halverwege september. De huidige build is 18407. Met andere woorden, het grote publiek zit met een release die al meer dan anderhalve maand en twee iteraties oud is. Om daar nu nog patches voor te accepteren is onbegonnen werk.

[Tsjilp]

In het originele artikel staat trouwens dat het een 'tijdelijke' maatregel is en dat ze met 1 of 2 versies weer opensource willen gaan. Al is het natuurlijk de vraag wat daar van terecht komt.
Blijft jammer. Alternatief is bij flex4 blijven hangen...

[resma]

Dat zal de Flex community leuk vinden... NOT!

Zo jaag je dus zelfs fanatieke supporters naar het vijandige kamp en zaag je zelf de poten onder je eigen stoel vandaan.

[Verwijderd]

Wat voor zin zou het hebben om (even gechargeerd) bagger code open-source te maken?

You're damned if you do, you're damned if you don't.


Dan maar een licentie aanschaffen om met die bagger code te gaan werken.

[jochemd]

Voor mensen die willen weten wat er precies gezegd is door Adobe raadt ik aan om de presentatie van Deepa te kijken.

Daarnaast was deze wijziging al op 1 oktober aangekondigd aan de mensen die daadwerkelijk meewerken aan de nieuwe versie van Flex in de Hero Open Iteration Meeting. Ik denk dat het gebrek aan reactie op blogs en twitter na die bijeenkomst een betere indicatie is van hoe de mensen die er belang bij hebben denken over 6 wekelijkse builds in plaats van nachtelijkse builds dan een artikel in The Register.

[dawuss]

Ik was er al bang voor, hun open source website was al een tijdje "wegens herstructuring" gesloten. Ben wel benieuwd wat dit betekent voor derivaten als GestureWorks for Flex, die de Flex SDK uitbreiden met custom extensies.