
How Google broke the OSS compact with Angular 2.0 - Garbage
http://codebetter.com/johnvpetersen/2014/10/27/how-google-broke-the-oss-compact-with-angular-2-0/
======
deedubaya
To make big changes and stay with the times, you have to burn some bridges.
Sometimes you have to burn a bunch of them.

I'll feel the same pain as everyone else when 2.0 is released, but instead of
wasting time complaining about it, I'll pick it up, embrace it, and keep my
whimpering to myself.

NG Core is kind enough to share their work with me. Sure, I've invested time
in learning it, but they don't owe me anything for that investment.

Feel free to apply down votes here to express your anguish.

------
pfooti
From where I sit, it looks a lot more like python 2/3 stuff. Angular 1.3 will
be around for a long time, there's talk about official google support for a
year or more post-2.0 release. From there, the community can keep it up. It
works fine.

Moving forward means moving forward. A 2.0 change is a lot of breaking
changes, fine. And yeah, developing it all in secret (as the blog complains)
isn't precisely the trad-FOSS way, but plenty of platforms and libraries get
developed closed until they cross a critical threshold.

Would people rather Google didn't work on this stuff at all? Seems like they
can't win.

------
CmonDev
And what is the deal with AtScript? If you are going to randomly "fork/borrow"
a language you can at least consult the original authors. Typescript is
inspired by C# not Java, so those are attributes - not annotations, and they
are in square brackets not start with an @ character. And it's called
'reflection' not 'introspection' in C#.

~~~
tracker1
Well.. annotations in VB.Net use <...> not [...] ... in the case of JS, [...]
is deeply tied to arrays in the mindset, so using @ makes sense to me.

Honestly, I'd like to see some clear examples of how to consume/check for said
annotations. Also, getting them in at least V8 in addition to traceur will go
a long way.

------
mckinnsb
I was just having a conversation with a friend of mine regarding if we should
spend more effort in learning Angular.

While I can understand making breaking changes, and sometimes very big ones, I
feel like this timing is incredibly poor, and is coming when many people are
just learning the framework. At this point in time I do not want to invest any
more time in the framework or its changes: the stable version I use will soon
be obsolete; I can't learn the "new" version or use the "new" version now; and
I don't know when the point will come when the AngularJS core team - and
Google - are happy with the decisions they have made, if the point EVER comes
( especially re: Google ).

I also feel that while they addressed many of the concerns that the community
had, the decisions they made were not strictly speaking "necessary". For
example, removing all the ng-* stuff "looks" nicer, but it is now less clear
which code is repsonsible for handling that declarative behavior. I would have
preferred a mechanism which allows you to specify other "included" directives
in a directive definition in a clear and concise manner ( without hacking on
compile or link functions ).

I think I'm going to try Ember or something else. I liked Angular for what it
showed me - that a data binding approach could really ease the pain of radical
design changes, for example - but I'm not going to be sticking with it after
this project. Time to move on.

~~~
nine_k
> _timing is incredibly poor, and is coming when many people are just learning
> the framework_

For a successful project, timing will always be "incredibly poor", for a
popular project always attracts new developers, often at an accelerating rate.

If you only plan to make serious changes when very few new developers pick
your project, it might be belated because your project is already dying.

~~~
omouse
When the docs are still in such bad shape and the number of books doesn't even
come close to other niches of our industry, it's _really_ bad timing.

They need to solidify what they have and make sure they're the stable choice.

With the latest announcements, I'm tempted to check out React and just fall
back to jQuery because the learning curve is too steep. I even run the
Learning AngularJS newsletter and I'm saying this! :(

------
whitten
I think this article has a good point re community building. When a group of
people move, it takes more effort to get them to start and stop (social
momentum). Transparency of the source of software allows the external
community to plan and train, and do other group-oriented things that a single-
developer shop can do with more agility.

------
untog
TL;DR: It's being developed in secret. Blog posts takes a lot of words to say
one thing.

~~~
mindcrime
This isn't exactly a surprising thing, coming from Google. Look at the way
Android development is handled. It's pretty much all "develop in secret, throw
some code over the wall know and then".

------
general_failure
If Angular 2.0 is architected the way it says in the docs, then it's really
scary. They obsoleted everything - something which many developer put a lot of
time and effort into. It doesn't matter if the design is better; what matters
is a nice clean migration.

Atleast for me, if this change goes through, I won't return to Angular.
Angular 3.0 might rewrite everything again for all I care. I just wouldn't
trust the angular devs anymore.

~~~
sfeng
I see it the exact opposite way. So many projects get encumbered by the
decisions made early in their development. I have a current project using
Angular 1.3, it works, and I will probably never upgrade it, and that's fine

My next project however will be able to use all of the lessons which led to
2.0. Innovation is a part of tech, either the Angular team will do it, or
someone else will.

------
ryanpardieck
I've grown kind of tired of these sorts of posts, where people assume that OSS
means handling the community exactly the way you prefer.

Does it have an OSS license? Do they adhere to it in practice? If so, then
your complaint isn't one of OSS, but rather community politics.

~~~
general_failure
There is some implicit expectation when people release a project as open
source. As a OSS author if you don't understand this expectation, your project
is going to hit massive roadblocks sooner or later.

~~~
ryanpardieck
The only expectation for me is that I can fork the project in accordance with
their chosen license. _Expecting_ anything else is a bit too entitled for me.

There are tons of different styles of project management. I don't see the
point in claiming one as the "OSS way." I think it's fair enough to criticize
someone for their management style in itself; additionally criticizing them
for breaking the "OSS contract" or "going against the spirit of OSS" is kind
of silly IMO, and a cheap way to score argument points and pageviews.

