Tip:
Highlight text to annotate it
X
[applause]
Eric Ferraiuolo: Thanks. I'm actually going to do a slightly different talk for YUIConf
this year. The last three years my talks have been about code and building apps with YUI
because I have a lot of experience doing that. This year I want to do something a little
different and talk more about YUI open source projects and the communities involved with
the open source projects, in particular the YUI community.
I'm from the YUI community. That's how I got on the team is just being involved with it,
talking at these conferences, getting to know everyone personally, and so it's kind of close
to my heart. The YUI community is a great community. It's way better than a lot of other
JavaScript communities. It has the smartest and best looking people, I think, in this
community.
[laughter]
But you know, everybody knows JavaScript here. You got to other JavaScript conferences and
that's not necessarily the case. We have a common tie here. We're all building really
awesome web applications. We all know JavaScript. The community is a really big part of YUI,
and I think it's important to talk about that.
We saw some changes announced at the conference, a new contributor model and how that flow
works, but where do we go from there? I'm going to dive into that, but then also have
time for somewhat of a more open discussion at the end and get feedback from you guys.
I'll try to set the stage for this conversation and hopefully everyone will be willing to
participate and give some feedback and their thoughts on what they would like to see with
YUI. Maybe what the good things are that we're doing, the pain points, and just how we can
keep progressing.
I wanted to step back first and talk about the groups ofů like three main groups that
open source projects tend to fall into, or at least that I've seen.
The first one is this idea that a project has open source. You can view the source and
see what it's doing, use it for free most likely. This is how YUI started. Every time
there was a release we would take a zip file of the source and throw it up onto [SourceFourge],
I believe, then. People could look at it and use it.
Android kind of does this. I saw a tweet the other day, somebody said oh, Jellybean's source
should be available soon. It's like, okay.
But then there are other projects that are done a lot differently, and you kind of progress
to this idea of open development, this idea that the source is always available, it's
not available at release time but it's always there and people can always see it, they can
see what's going on, they can understand what to anticipate coming.
If I'm an Android developer I may not know what's coming in the next version of Android,
but if I'm somebody working with the YUI library I can probably understand what's going on
because we've progressed to where our development is more open. We're describing all of the
planned things that we're planning to do, we're trying to have open conversations through
Open Hours. Our source is always up there. It's up on GitHub which makes it very accessible
for people to see what's going on, follow the project. I feel like this has a lot of
value.
This is required for a project to have a community, I feel like, to have this involved community
where they're actually contributing back. The development has to be open. They have
to know where things are going, how they can participate, and this is very important. I
think that Yahoo! supporting the YUI project and being able to do this development in the
open but still have a core team working on it really helps make sure that things are
getting done. I feel like this stage that [a] project is in, there's a lot of stuff
happening, like it's progressing, things are changing, features are added, re-factorings
are happening. It's a good state to be in.
But some projects go further than this, and this is moving to a model of open governance
where not only is the code done in the open and people are contributing, but the organization
of the project, the direction that it's going, is done in the open and done by the core members
of a community, basically other stakeholders. YUI's kind of in this weird position now where
we have a lot of big companies dependent on the library, not just Yahoo! This is where
this open governance really comes into play.
We recently saw over the last year JQuery transition to this model. They now have the
JQuery Foundation, which manages the project inů It's like, I think, Microsoft, Adobe,
[Boku], and some other smaller design shops are involved, but it's like big companies
and these smaller companies and they're all getting together to try to figure out where's
the direction of the project, what should they be focusing on, what are the priorities.
It has this different model than open development. YUI's clearly at open development. Open governance,
there's still a lot that's strictly controlled by the core team. We make decisions in meetings
that are not necessarily open.
I think that there's a nice sweet spot between there. Sometimes when projects go into this
open governance mode, they essentially are in maintenance mode. If things get to the
Apache Foundation, thenů When there's not like this core team getting paid continuously
to work on it or something like this, it may stagnate and it's just essentially in maintenance
mode. You definitely want to avoid that, or we would hope to want to avoid that.
Now bringing this back into YUI, I feel like there are a few things we can look at. We
can look at who's using YUI. One group is clearly Yahoo!. Yahoo! uses YUI everywhere.
But there's this other group, and it's essentially I'm going to bucket as Ĺeverybody else'.
What's the interesting thing about this slide?
Audience member: They are separate.
Eric: They are separate, okay.
Audience member: It's bigger.
Eric: Bigger? I think there's one hidden thing here, though. The Ĺeverybody else' bucket
chose YUI, and they probably had to fight for it within their organization. At Yahoo!
it's an engineering standard. If you want to use something different that overlaps a
lot with YUI, you're going to have to make a case for why that makes sense.
But I really don't think, Luke, like you said, that they're different. That's a good observation
but I think that something here is aligned. I think there is a lot of overlap here between
these two groups.
First talking about the part that's not overlapping, when you think about the goals for the YUI
project, I kind of see this as being the part that doesn't overlap is like the short term
goals. This is like I'm working on an app, I run into a bug, I need this bug fixed. This
bug is very specific to my application, whether I'm at Wells Fargo, NFL, on my own working
on a project. And they're really short-term goals, like I want this bug fixed so I can
do a release.
Same with Yahoo!. There's Yahoo! developers building properties at Yahoo!, and they run
into these same things. They need these bugs fixed.
But then I think that the interesting part here is this overlap. I think this is the
long term goals for YUI, and I feel like these are actually aligned. Ryan was just talking
about when he was enhancing search for SmugMug that performance was a paramount thing here.
At Yahoo! performance is also a paramount thing, and specifically some of you may know
that we have goals and work items for this quarter to work on performance of YUI. We
want to improve the performance. That's a long term goal, it's a cross cutting thing.
There's a lot of work that needs to be done.
What's interesting here is these long term goals fit really well for core team members
or core committers to work on. We feel confident that the core team members and core committers
can do this work, one, that it takes a vast understanding of the library. If we wanted
to improve attribute, that's not something we can expect necessarily just a community
contribution to do. But having a core team focused on the library, I feel like we can
dedicate time to this. These are these longer cross cutting goals.
But for the short term stuff, if you're in the JavaScript debugger and you see a statement
that says if this and you realize like, oh, this is where my bug is, if it just said or
some other expression then this would work. You look and there's no unit test for it,
and it's clearly a bug, and you're already in the debugger, you see exactly the lines
of code. We just want you to change that, fix that, and submit it back as a pull request.
We'll pull that in.
And that way the core team doesn't have to build off the context of what you're doing
and have you boiled down your example to something we can understand, or remove your proprietary
code that you don't want to put publicly somewhere so we can look at. It's just so much easier
a lot of times to just fix these problems. I think for the short term stuff that this
is where these contributions can come in, from people who are not on the core team.
But for the long term stuff, I feel like we shouldn't expect these big changes to just
happen from community members contributing it. If they do, that's awesome, and we'll
want to work with you to do this, and dedicate time to it and resources to it.
One other thing I think about here when I see these two circles. This is kind of how
the community around YUI operates. I guess it would be moreů Everybody else fills a
big role of the external community, the community we know of as YUI, and at Yahoo! there's actually
not as much participation in this community that we would like to see. There's a lot of
back channel stuff or emails or separate bug tracking things, and what I really think would
be healthy for us to do is to really look at this as one community.
There's one YUI community. It encompasses people at Yahoo! who are using YUI, it encompasses
people anywhere else who are working on YUI, and I think that this would be really healthy
because the people at Yahoo! are doing really interesting stuff ľ we've seen that ľ using
YUI, and they have so much to contribute back. So much knowledge, so much ways to help, bugs
to fix, and they don't have to wait on us. They have strict deadlines, they need to make
releases just like other people who are building products. Much stricter deadlines than what
a library or framework has to do.
Getting bugs fixed, getting that stuff in. We have rapid release cycles now. We can get
that stuff in. You do a pull request for a bug fix, that thing will get in in a month
in a stable release available to everybody. A month at the latest.
We're seeing tools that we now have which are removing these technical barriers, making
it much easier to actually contribute to YUI, to work with it, to develop with it. This
is something I would like to see, personally. I would like to see more internal Yahoo! people
contributing to this community, because they just have so much good knowledge and information
and can really help out the project. I think that everybody benefits from this.
One interesting thing we see is if you think of this pyramid, this inverted pyramid, as
resources, you have the library at the bottom, or framework. But then there are other frameworks
built on top, like we saw a talk about Mojito. These are frameworks built on top of YUI.
There are also people who at their companies, they may have a layer that they put over top,
a standardized layer that they use. Then they build products on top of that. Usually there's
a lot of people on a product team compared to the library team, and the frameworks as
well.
We don't want to be the bottleneck for this type of stuff, especially for these small
bug fixes, doc changes, any of this stuff. Everybody in here are contributors or can
contribute, and we would love to get this. I think that it'll really be healthy for the
projects to have all of these people helping contribute and helping keep the library progressing
and keeping it stable, because this could easily tilt, right? We don't want this to
fall over, we want YUI to be this very stable, rich and useful lower library level that you
can build on top of and help keep it that way.
Part of the resourcing thing is we haveů There's this core team at Yahoo!, we're working
on YUI. I'm on that team. But some other timesů I mean, we are employees of Yahoo!. Some other
times we're working on other projects, we're helping other teams or we're sitting in with
other teams and doing these things. This is actually really, really healthy. This causes
us on the core team to be using our own components, to be eating our own dog food. I think that
this is actually really important for us to do this, library developers to do this.
If something isn't necessarily getting done on time, like the core team member who may
be best suited for doing that is working on another project, hopefully in a lot of the
times when they're able to come back they're able to feed so much more into the library
and do such a better job at this new feature that they want to add, or refactoring, because
they got a lot of real world experience. This is the other thing too ľ all these people
who are building products also essentially have a lot of real world experience using
YUI and have a lot to feed back to it. That's where I think the external community, the
Yahoo! product developers, they're dog fooding YUI, right? There's just so much that they
give back to us.
If I were to try to think of some low hanging fruit that we have how we can move forward,
a few of these things we have even announced at this conference. We moved to GitHub as
the source of truth. This means that when we do our builds through our CI system, you
can see the results, you can see the test failures. This is really important for the
last line in there: opening it up to non-Yahoo! contributors. This way if, in the two we announced,
Luke and Ryan, if they were to go in and make some change and break the build, they would
know and see why and be ashamed and fix it.
[laughter]
Before dinner.
Some other things we've been talking about. We've started transitioning a little bit the
community outreach we're doing, and we now have Andrew on the team. He's dedicated to
this. He's been thinking of a lot of things too. And we have Derek who's been doing YUI
Weekly. We've been having some more ad hoc design discussion meetings on Google Hangouts.
People have been really liking that. We have Open Hours as well.
We actually have on the team two meetings that we do every Thursday. One is more of
like a Yahoo! employee meeting, and the other one is more of a YUI meeting, a YUI round
table meeting. It seems like some of these round table meetings it's something that we
can easily open up, just put on Google Hangout, and if we're talking about a topic like a
new feature we can invite the people into the hangout who are the stakeholders of that.
And then allow anybody else to watch it later if they care to watch it.
[applause]
We've been talking about this internally and it basically seems like a no brainer and something
we can easily do. We're really good at using Google Hangout.
One thing I would like to see which would be cool is with lowering the barriers to contribute
to YUI and the gallery, and me standing up here asking you guys to help with the core,
it would be awesome to see double the number of contributors. So next year when we look
at how many people have contributed to YUI, how many people have authored commits, if
that number is twice as much as it is today. I think it's something around 80ish right
now. To get over 150, I think that would be awesome.
Similar to this open meeting idea, a lot of the design decisions can be done more openly.
We've been doing that. We've been writing out design documents, putting them on our
GitHub Wiki. If you don't know that we have a wiki on GitHub, you should check it out.
It has a lot of good information. Our schedule for releases, the things we're working on,
history change rollup files so you can see everything that's changed from release to
release.
We also have design decisions up there. Some of this is in pull requests, some of this
is in documents on the wiki. And I think that going along with the open meetings, we can
make some of these larger design decisions by bringing in the people who are in the community,
who really care about this and who really want to contribute this. If we were doing
skinning stuff, we can bring in the stakeholders there who really care most about skinning,
care to help out, and may even be able to offer some resources from another company
to help collaborate with us to get these features done.
I think that some of this stuff is low hanging fruit. I think you guys probably have a lot
better ideas. We were able to easily come up with a contributor model for YUI, it just
made sense. Like we have contributors, committers, core committers and reviewers. That's kind
of how things were working anyway, we just formalized it. That makes a lot of sense.
But when we get into more of the bigger picture governance stuff, like what direction are
we going, what are our priorities, we were trying to figure that out and we realized
that this is actually a hard thing to figure out. Also, wait, we can't just figure this
out ourselves, we need to involve the people, you guys, who would be interested in this
and who would want to help out and who would maybe want to be a part of being in these
open meetings, telling us what your priorities are. That's kind of where I want to end and
open up the floor, maybe get a feel for what people think would be important that we could
do, as the core team, that would make it easier for you guys to contribute, feeling like you're
part of the community, feeling like you have some ownership over YUI and its future and
keeping it progressing for everybody.
If people have thoughts, I think we'd definitely like to hear them.
Audience member: We'll kick things off over here.
Eric: Somebody has to have a thought. Come on guys.
Jenny: They're digesting all this.
Audience member: This is your code. It's your stuff.
Audience member: Thank you. This makes perfect sense. We have been using YUI for many, many
years and we can really see the team progressing through this open governance. That's very,
very much appreciated. It's so reasonable. At the same time, I think there's no governance
system that is perfect. Everything has flaws. Even democracy, it comes with a lot of headaches
and all that. Hence the balance. I think having a core team that ultimately you can vote,
and people that care about voting for something might have super good reasons to vote one
way or another. But at some point you also have to have people say you know what, at
the end of the day you have to make some decisions in one direction or another.
So anyway, just a comment that... Proceed with caution, I would say, because it can
get wild. We don't want this to become like other libraries or communities that they go
on wildly and there's a lot of drama and a lot of opinions. Very much appreciate it,
just proceed with caution. We'll be sure to contribute the best we can. That's just a
thought I wanted to share.
Eric: Yeah, yeah, I think that seems right. The idea being between open development, open
governance where we can still get a lot of stuff done but not be caught up in bureaucracy.
We don't want to all of a sudden pile on a bunch of bureaucracy onto the whole process.
I think that makes sense.
Audience member: Hey Eric. This is really, really great stuff, and I've been super, super
excited to see what you and Dav have been talking about lately and the way YUI's been
opening up and embracing external committers and things like that. It makes me think that
one of the interesting things about this is we've always talked about the YUI team as
the core team that's employed by Yahoo! to work on YUI, but it seems like there's no
longer that distinction any more. If we open up meetings about the library, and if we open
up external commit access, and if we have the concept of contributors and committers
and reviewers, there's no longer really a concept of a YUI team. They're always going
to be people who are paid on YUI, whether it's at Yahoo! or at SmugMug or at Wells Fargo
or any of these other companies that use YUI.
That raises an interesting terminology question. Aren't we all the YUI team if there are external
contributors and maybe, someday, external reviewers? I think that would be really cool
if we can just all think of ourselves as the YUI team.
Eric: Yeah, yeah, I think that everybody should. I mean if you're contributing stuff, I would
hope that you would feel part of it. I know I felt a part of it being an external contributor,
really before we even had the stuff that we're doing now. I think that there is actuallyů
Yeah, the distinction of having people who are dedicated, are paid essentially to be
dedicated to the project is important, I feel like, for its continued advancement, but if
SmugMug wants to give you a month to pound out some YUI stuff, we'll be okay with that.
[laughter]
Yeah?
Audience member: Just some feedback on contributing, specifically with new contributors. I know
that when I first started looking at YUI and I'd find a bug and be like oh, this is a really
simple thing, I can fix it. But then there was a realů At least years ago, there was
some real barriers to entry as far as oh, I've got to learn Git, and I've got to learn
this, and I've got to write this test, and my code isn't good enough to do this. One
thing to keep in mind as you're trying to track new committers and contributors is just
really think about the ways to lower that barrier to entry and to teach someone who
maybe doesn't know this entire tool chain or doesn't understand the current coding practices
how to get to that point where they can contribute and empower them to do that.
Eric: Yeah, I wonder what would be the best way to do that. We could write up some documentation
and try to coerce Evan to write it for usů
[laughter]
ůto do that. But I wonder if having a combination of screencasts to help out, and meetings,
open meetings. But yeah, I think that makes sense. I hope that with Yogi we've definitely
lowered the barrier. I know even for us it's so much easier, it's like night and day, and
the speed is just ten times faster to build stuff.
But the one thing that we wouldn't do, necessarily, we wouldn't want to lower our quality standards
either. It is an interesting balance there, because we would want to make sure to encourage
people to contribute, but contribute at a high level. But hopefully that's not too onerous
for them to do so and takes them away from their main focus of building a product or
something.
Jenny: I'd like to add something to that. As the manager of the YUI team at Yahoo!,
one of my jobs is to ensure that the team is coding to a certain standard and that I'm
growing the maturity of the team as engineers and growing the discipline as a whole at Yahoo!,
which I think also impacts the rest of the industry through conferences like this. That's
a process that I can open up more, and whatever we're working on as a team, to kind of raise
our bar is to just communicate that so that all of the teams that you're working on can
kind of be on the same page with all of that too.
One question over here.
Audience member: Considering the ease of the gallery now, what do you envision the pathway
to something getting into core? In the past it's been kind of an ad hoc thing ľ oh, this
is written potentially by a core team member but in the gallery we're going to graduate
it. Would that be something that the community decides, orů?
Eric: How we've done it in the past is actually we would have a round table meeting to kind
of figure that out. I think that's where opening that up and allowing some of the people ľ
the person who's contributing it especially ľ to be involved in that conversation would
help determine that, and if it should be in core or not, or gallery. Also with the new
gallery stuff, it's really bringing the modules to a first class citizen. It's not necessarily
the pathway of still pushing it up to gallery and then all of a sudden core components want
to depend on these things. Okay, maybe that makes sense to pull it into core then.
But I still think that that pathway of gallery first is kind of a no brainer there, especially
with the changes and especially the coming changes to the website to really highlight
gallery modules and quality gallery modules. Dav talked about that in his talk, where if
we have a component in YUI, maybe it's an older one, and then somebody's contributing
a new one that's maintained, that has full tests, that people are depending on, then
that maybe should make sense to either just remove the thing out of YUI core if we felt
that we shouldn't have it in there anymore, or bring in the gallery one.
Yeah?
Audience member: I really welcome all of this as well. I wonder if there is a helpful role
about actively encouraging collaboration within Yahoo! and outside so that people working
on similar things and similar projects can do so together, if that makes sense? For less
experienced people, they get some kind of mentoring almost within, to learn from others
as well.
Eric: Yeah, I would definitely like to see that. Hopefully justů I'm trying to think
if there's a good way to get the internal Yahoo! people collaborating more. I mean there
are some that do and it's amazing. They really love YUI, they're really passionate, and get
things in the library or help other people out. I don't know, somehow highlighting them
as role models for other developers inside of YUI or inside of Yahoo! to do the same.
I think that the people outside of Yahoo! can also be doing this too. I don't reallyů
When it comes to helping the project, I don't really make a distinction in my head. Sometimes
I don't even know that somebody I'm talking to is actually an employee of Yahoo!, like
I don't find out until later or something.
Jenny: Question over here first. Oh, is that a follow up?
Audience member: I'll tell you one of the big things about the IRC channel is the fact
that you get that open dialog, and if you have any questions or anything like that,
people that are familiar with YUI are able to contribute back to what you're working
on. And then a lot of us core team members are actually hanging out on the IRC channel
as well to help out with problems.
Eric: Yeah, and it's even the case that the core team members are usually not answering
all of the questions. It's other people who are in the community helping out. Yeah, even
if you work internally at Yahoo! and you have a question about YUI, it's actually probably
faster to go in the IRC channel and most likely it'll be answered by somebody who's not a
core YUI member.
Jenny: Question over here.
Audience member: Thanks. I wanted to point out that one of the benefits of contributing
is they send you this awesome t-shirt, so that's really cool.
[laughter]
As a contributor it made me feel kind of more connected, so that's nice.
Yogi is definitely going to have a big impact. I can totally see how it will be a lot easier,
so thank you for that.
Eric: Thank Dav for that one.
Audience member: Yeah, yeah. Maybe two suggestions. Getting to the other commenter's point, I
don't think it can be under-stressed, or over-stressed, how nice it is to have explicit steps on how
to do things, particularly with people who are unfamiliar with Git, because there are
several different work flows for Git. Do I rebase, do I maybe do a merge squash, all
these different things. That would be really nice, whether it's a screencast or something
on the wiki or wherever.
I would maybe point out, try not to diverge too much. We have the GitHub Wiki now, and
then we also have the YUILibrary.com website. So maybe kind of guidance on what should go
where. Also maybe explicit instructions on how to add examples to either the Wiki or
YUILibrary.com if you have maybe an awesome data table example. I know that T Smith from
the channel has some things that would be really excellent additions to that.
Eric: Yeah, his examples would be great. Do you think that if we were to split where the
contributing stuff was all sort of hosted on GitHub, where the source is, where the
pull requests are, that that would be a good divide? Where then for all the using stuff,
if you were just using YUI, then all of that information's on the website? Do you think
that that would be good instead of mixing the how to contribute between both places?
Audience member: I don't know if I'm the best person to answer that, but it makes sense
to me.
Luke: I'll put an obvious link up on YUILibrary.com.
Eric: Yeah, yeah. That's a good idea. Cross link, yeah.
Jenny: Could you repeat the comment?
Audience member: Repeat the comment.
Eric: Oh, Luke said to put an explicit link on YUILibrary.com to make sure we're pointing
over to the right places to GitHub.
Jenny: For me personally, this is still something we're working out. I agree that diverging
places of documentation gets confusing. The wiki is where we house things that are works
in progress and evolving documents, and then once something gets codified it will land
on the website as documentation. For instance, right now we've got contribution standards
on the wiki, because that's something that's new and we want feedback and we want to be
editing that and have the history available on all that. Then once we kind of formalize
that, we'll throw it up as a tutorial on the website.
That's what I have in my head, so if there's any feedback on that, or guidance, advice,
suggestions on that, I would love to hear that as well.
Audience member: I really love the open source nature of YUI but one of the issues is that
it's all, it's mostly volunteer. How does the team feel about providing a paid support
model? For a company, like the one I work at, if we want to use YUI but we can't get
the developers in house and we come up with an issue in YUI that's low priority for the
rest of the community, but for us it's specific and it's high priority for us, but we don't
have the talent to implement a fix, how do you feel about paid support, that type of
model?
Eric: Yeah, I mean that's interesting. I definitely can't speak authoritatively on that.
Jenny: I can say something.
Eric: Yeah, right, you should.
[laughter]
Jenny: Yahoo! does not offer any sort of paid support model. One thing that has worked really
well in the past is that companies or teams that are looking for more direct support,
they've reached out to members of the community who do provide paid support. Connecting those
two parties is something that we could do a little bit better, a little more out in
the open, promoting companies or teams that provide those services to companies that are
looking for them.
In the past it's been either through IRC or people emailing me directly and then me kind
of making those connections, but that's something that we could do a little bit more formally.
I think as the community grows there are going to be more parties on both sides that are
looking for each other, so we can do more for that.
Audience member: To reply to that and actually to continueů Darn it. And to continue his
point, at the higher level what that does is it abstracts into a separate entity where
the money comes in to influence the decisions for the library. Right now YUI is a product
of Yahoo! and the money is internal and it's going to the core developers, and therefore
the influence by that money is through employment. The external contributors, they get to contribute
to the library, they happen to be paid by their employers to contribute to the library,
and it gets paid that way. The justification has to be from the employer to the employee
that your role in my company is to contribute to this open source library.
Now, it's been successful for Yahoo!, but when a company starts to really bank on YUI
then it does raise the question of can we, rather than pay employees of our company to
work dedicated time on YUI, can we pay this general pool of people that are specialized
in YUI to have our interests prioritized in some way? That seems to abstract out to the
idea that you've seen in other libraries of a foundation or a separate entity that then
gets financial contributions from the consumers of that library.
Do you want to talk about the foundation?
Eric: I mean, there's not a foundation, right? But you know, that's something that would
beů It's come up before, but it's a bigger thing, it's a much bigger change. That's where
I was trying to go with the idea of what types of stuff can we do to get the benefits of
that without the drawbacks. Is it possible to be somewhere balanced between it still
being something that is copyright Yahoo! Inc, but that really we would have a lot of the
same benefits that something that had a completely open governance model had, and a foundation,
without the overhead of having to not only code but then run a foundation or something.
Would there be enough money to support that? And then would there be too much bureaucracy?
There's just a lot more unknowns there, and I think that would have to be a lot further
out thing in reality, butů
I think it would be interesting to see what ends up happening with JQuery going through
this. You know, will they continue to work on JQuery mobile, JQuery UI, the main JQuery
project? What will happen there if the business interests of the parties involved in the foundation
start to diverge? I think it's still kind of a new thing for at least JavaScript libraries
and these things and the communities involved.
I think it's an interesting thing, but I think now, in reality, what can we do, I think there's
a lot of other things we could focus on to get a lot of those same benefits. Hopefully
we can do that.
Audience member: I really love Yogi, I'm really excited about that. But I was curious what
your take on what is the dividing line between the gallery and the enormous ecosystem of
small and medium and large sized libraries that lie outside the gallery? For example,
in Ryan's talk he showed an example of hey, there's this cool regex library that's just
sitting out there, and hey, I can just load it using the loader. When we're thinking about
what YUI core should be doing, what the YUI gallery should be doing and what the rest
of the universe should be doing, where do you think we should draw that line? And should
we be encouraging people to grab stuff from CloudFlare, wrap it in the loader and use
it?
Eric: Yeah. I think thatů I really like Ryan's comment on that, with the idea that the loyalty
should be to the users who we're actually trying to solve real problems for and not
necessarily to tools. I definitely try to echo that, but then I think that it's going
to also be constantly evolving where that line is. Should the YUI core continue to grow,
or should it be shrinking? Because now we have a much more fully fledged gallery.
But I think the idea of being a good neighbor with other JavaScript libraries is still important
there, and I think that the features that YUI has, specifically like around the loader
and that whole concept of modules and dependencies and being able to do that, is definitely something
that we have an advantage of over other libraries. If you would imagine trying toů If you look
at the standard Backbone stack or something, you may be loading Backbone, Underscore, JQuery,
maybe JQuery UI, or JQuery mobile, and then RequireJS, and then having to work with AMD,
modules, and put all this stuff together, and you're spending a lot of time essentially
building a stack that is very similar to YUI, at least at its core.
I think that we definitely do have the advantage of being so modular and granular to be able
to move that line around where it makes sense. I don't think we have it nailed down yet.
It'll be interesting to see what ends up happening when the gallery stuff starts to become a
lot more of a first class thing, integrated with the library at the website and documentation
levels.
So who's going to be a contributor to YUI this year? Nice.
Jenny: We have a question over here.
Audience member: You mentioned in passing about this idea of there's something that's
in core and maybe there's something in gallery that's better, maybe it should come out of
core. That's never happened so far as I can recall. Has there ever been anythingů I mean
there have been some features that have been deprecated, perhaps?
[Audience member makes inaudible comment]
Audience member: History? Oh, history went away.
[Audience member makes inaudible comment]
Audience member: Okay. So just to repeat that for the mic, history existed and then history
lite came in and it replaced history, so history in its original incarnation went away.
Eric: Yeah, history lite was a gallery module, right?
Audience member: Right, right, right. So I guess that would beů
Eric: The replacement, but not leaving the void in the core.
Audience member: Right. So in the case of resourcing challenges in maintaining the current
size of core, something's getting left in the dust. There might be some community interest
in that there's the external contributors that can help maintain that. But if it's not
getting enough love, should it be demoted from core? Or is there some other way of identifying
that? Or is the exposure on the YUI Library site in terms of when this was last updated
or when this was last changed or something like that supposed to be exposing that level
of detail?
Eric: That's probably good information to expose, like when the last time this was updated
in a release. But in terms ofů I mean, I don't think we're going to have a formula
to apply to it. I think it's going to be more just what seems to make sense. Like if people
are not using a component anymore because that type of interaction isn't used on the
web really these days then that could be something that could move around.
Jenny: Also if a code base is stable then it doesn't really need updating, but that
doesn't mean it's not useful in the core either.
Eric: Yeah, that's true.
Audience member: Yeah, that's a good point. With exposing the gallery more on the website
alongside the actual core modules, it does blur the line between the value of contributing
to the library in the gallery versus into the core. As that line continues to blur,
can you help clarify what the distinction is for choosing one target over another? Certainly
in the case of gallery you get to maintain your own repo and then push in somewhere,
but if it were possible to maintain your own repo and push into core versus galleryů How
the relationship there I guess is a little bit gray.
Eric: Yeah, I mean the contributor model also adjusts that a little bit too. But it just
depends essentially on who's going to be the owner and maintainer of that component, I
think, at that point. Yeah, the line is blurry but I think for, I don't know, a good thing.
Like it's good that it is. If people are contributing, I think if there's clearly a core component
that has a bug then that will obviously get fixed there.
And that's mainly for new features. I kind of think that having some new features coming
up through gallery will be something that happens more now. I kind of see that. If it's
some new thing that'll come into gallery first, we will want to use it in core. Imagine Promises
or something. We put it in the gallery, all of a sudden we want to start using it in the
library and it makes sense to pull in then we would. I think that discussion about pulling
it in would involve more people than just the core team at Yahoo! talking about it.
Dav Glass: Yeah, so Eric I've got something to follow up on that. One of my goals for
the gallery is to blur that line as far as humanly possible. Really, essentially what
one of our releases is is just a bundle of these modules that happen to work together
really well. If they're gallery modules, there's no real difference between a gallery module
and a core module because they all work together.
We're trying to break that line of core because a core release is something that's the low
level parts and it's the things that everything in the system relies on, so they have to be
extremely stable at all times. If we can reduce the size of that, we could actually iterate
on it faster. But by moving some things into the gallery, you get weekly CDN releases.
I mean that's 100 times faster than what we push out at release. If you find a bug in
one of your modules, you could actually put that thing into the CDN queue and bam, people
can use it the next week. If I get it down fast enough we could do daily CDN releases.
Right now it takes 50 some odd seconds to deploy it. I could write a script to do that,
that way I don't have to do it anymore.
But really, the idea of the releases themselves is they're just a bunch of modules that just
happen to shake hands really well. It doesn't matter where they live, and that's what I'm
trying to do is break that barrier down so that these things, no matter where the hell
they live, they work, they act, and they feel exactly the same way and they all interact
with each other, but giving you the control of updating your modules even faster. I think
that's more of a benefit of what we're looking for is to trim that core down so it's nice,
it's lean, it's fast, it does everything it's supposed to do, and then you just get to pick
and choose whatever you want.
One of the features that I have coming up in the next couple of weeks is actually a
customized loader build that will build loader metadata for your gallery modules. That right
there is a huge difference from the way we've done it before because gallery, you know,
you had that little problem with having to fetch one or two items or having to build
your own combo URL. But what if you could build your own metadata? What if you could
pull up a list of the YUI source tree, you could say I want these six gallery modules,
I want these four of my custom modules, and I want these three YUI modules. This thing
builds you a damn zip file of everything. It says here, this is all I ever need.
That's the same thing we would do only we're putting a stamp on it and saying this is 3
dot whatever. That's my end goal. My end goal is to be able to say I want to use these four
or five things, and this is all I actually need. If you're building a Windows 8 application
you can say I only want this and it's only going to give you the Win 8 stuff and the
two widgets that you want, that you have to include in your app. So now your app's really
tiny. You don't have to do all the dependency configuration yourself, we'll do that. That's
all the same thing, so our release, the gallery release, a bundle that you build yourself,
they're all the same. That's what I'm trying to do is bring all of those things together
so that they work, and they act, and they just interact and shake hands and go out and
have beers and party and all that other good stuff together.
Does that make sense?
Audience member: Can I follow up?
Dav: Yeah.
Audience member: Is it worth thinking about moving widgets from the core into the gallery
that are there at the moment?
Dav: I'm a big fan of that. I am a huge fan of moving widgets back into the gallery so
they can be iterated on faster and better and by more people. Because if they're pulled
over into their own module you got GitHub pull requests, you guys can collaborate all
you want together and work on them really, really fast and really, really small tight
circles, and then bam, push it up to the CDN, everybody benefits, rock on. Move on to the
next one.
Audience member: So something like Promises is core, because it's central and important
and needs to be in core quickly, but Dials are nice but notů
Dav: Exactly. That also gives the core YUI team at Yahoo! the ability to actually break
away from our sprints, because we have to dedicate sprints to what we're going to work
on. I can dedicate and say I'm going to be working on Loader this entire time, but knowing
that I can get an editor build out tomorrow, I could go over and fix 15 bugs in editor
overnight after 6 cases of Mountain Dew and all.
[laughter]
Fix all those bugs and actually have a CDN deployment for just that module tomorrow,
instead of having to wait 3 months for it to actually go through the entire QA process
and bundle everything down and put it a release on it and stamp it. I still get it out there
and people can start using it. That's really my goal, is the really fast rapid iteration
of pushing these things out there.
Eric: The other interesting thing, too, with having the smaller core is we want YUI to
run in a lot of different environments, including on the server, Node.js. Right now we have
on the website a list of modules that run natively in Node, because they essentially
just require JavaScript runtime, and the other ones that require a DOM. Seeing that the other
list is much longer, it's kind of weird to think why do I need to download this whole
huge bundle of YUI to use on Node and I'm only using a few of the classes and utilities?
Having it be a smaller core, it makes more sense to say that it's running more places
because a larger percentage of the core library runs in these environments.
Audience member: Hi. One moreů More than question, this is feedback for what Dav was
just saying. I'd like to hopefully ask that we can take it one notch higher. Everything
you're saying makes absolute perfect sense, because that's something we work with and
have to shuffle every day. I'm from Wells Fargo and we cannotů There's a couple of
things that if you can help us do better, it'll be just like heaven.
One of them is that we cannot use the CDN. Unfortunately we have to host everything in
our own CDN, and everything has to run as a cell. There's just no way for us not to
do that. The other thing is that for better or worse, we cannot just freely decide to
use GitHub. We can't. All of our sources, everything we do, the hosting, everything
has to be internal in our own data centers. If you could take it one notch higher and
say okay, everything you're saying can be done either on the Yahoo! CDN and on GitHub
as well as on any other CDN or any other source code repo, that would be beautiful.
We are actually building an internal community of frontend engineers in Wells Fargo. We're
trying to raise the bar of frontend engineering, which was horribly low.
[laughter]
Yeah. And so everything you guys are doing about the community, the gallery, this is
exactly what we're building, just internally. This is enterprise level, but it's exactly
the same thing. We have a lot of teams, a lot of verticals, a lot of lines of businesses
moving trillions of dollars and we want them to have a decent UI.
That's just my comment and feedback. Just keep where you're going, it's a beautiful
direction. Just also consider companies like ourselves, that we could not just use all
of your infrastructure. I would love to, but we can't.
Eric: What about Grifter, right?
Dav: That's what I was getting ready to say. Yesterday at my keynote I mentioned the new
tool that's going to be coming out soon called Grifter, who steals ***. Grifter actually
builds the CDN deployment for the gallery, and it will work for our YUI 3 CDN deployment.
It's the same thing, that's what I'm trying to tell you is that that tool is the thing
that's going to build the zip file that you just put wherever the hell you want. If you've
got a CDN deployment you take this zip file, you explode it, you push it up to S3, you
push it up to CloudFlare, you push it wherever the hell you want it to go, and it's exactly
what you wanted.
Audience member: Regarding the split between core and gallery, one of the challenges with
gallery is just the challenge of open source in general, that code ages. Some of the modules
on gallery, people maybe lose interest or have moved on. If we take color picker, for
a recent example that I ran across, there's a gallery-colorpicker, there's an Alloy UI
color picker, and then there are several other ones that are more just showing the palette
and then you can select. None of those fit my project's specific needs because the gallery
one, it uses the canvas so it only supports IE 9 and up. The Alloy one is just broken.
I think that it just hasn't been maintained. So eventually we landed on YUI 2 and 3 as
a solution.
But it doesn't have to be color picker, it could be whatever. I guess the challenge there
is what do you do, how do you address that? Maybe it's to allow multiple committers for
gallery modules, not have it be so owned by just one person. I don't know mechanically
how you would do that, but it's just something that I ran across.
Jenny: Well if the gallery module is in GitHub then you could issue a pull request against
the GitHub author and collaborate that way.
[Audience member makes inaudible comment]
Eric: Like a transition process?
Jenny: Well then you could fork it.
Eric: Like an ownership transition process? I mean that seems like something Dav could
get done in the morning one day.
[laughter]
Audience member: I guess a follow up on the SSL question beforeů I know Yahoo! does not
support HTTPS through the CDN, and Grifter's great and all, but for those of us who do
want a combo loader, are there any plans on updating the current official combo loader?
The PHP one seems out of date. There's a Node.js one but that requires running Node, and that's
a whole other stack that if you don't currently use we would rather not pull in.
Eric: Has the PHP one gotten a new owner? Do you know Ryan?
Dav: Well the PHP one's not technically a combo loader. It does combo-ing but it's actually
the loader logic inside of PHP. There's actually one called Minify, and I think Ryan Grove
wrote the first version of that one. Am I right?
Ryan Grove: Yeah.
Dav: Yeah. So there's one called Minify that actually works with YUI 3 very well and it's
in PHP, but that was the first one I actually used in my sites when I was running PHP, which
I don't do any more. There are several combo loaders. It's on our list, actually. It's
one of Andrew's things is to actually put together the list of all the combo loaders
in all the various languages and link to them and show them this is how you set it up for
YUI 3.
But I can tell you for SSL support, we will likely not ever open gallery to SSL because
that's just horribly, horribly, horribly, horribly wrong, because we can't trust that
code so we can't actually tell you you should serve this over SSL. Providing third party
stuff that you don't even know about over SSL's just really bad. Ryan has an excellent
blog article on that.
Being able to put up a combo loader in different languages is actually really easy. I mean
all it does is split a query string, grab some files, concatenate it, and spit it out.
I mean God, you could write that in like 20 minutes in any language possible, right? It's
not that tough, especially if you have a CDN in front of it that you can just blast the
thing off to the edge and then you're done, you never have to worry about it again.
Does that kind of answer the question?
Audience member: Sure.
Dav: All right.
[laughter]
Dav: I don't even know what it was.
Jenny: Question over here.
Audience member: Thanks. Yesterday Luke's talk about attribute and today Ryan's talk
about the whole performance thing, I think those are really helpful. I'm just wondering
that today people are all contributing code, which is obvious. I'm wondering if it's possible
that for each, whether it's a core module or a gallery module, that could be dedicated
please for people to contribute examples and to contribute performance benchmark results?
That, I think, on one hand it really becomes more informative, more depth, and on the other
hand it could push the author to go even higher bar.
Eric: One of the things we're doing is adding benchmark tests into YUI's tests so people
would be able to run those benchmarks just like we do with Yogi. I'm sure Dav will add
a Yogi test --benchmark if it's not already there and be able to run benchmarks. That's
something that we have on the roadmap that we want to be doing.
Then for examples, the way all our documentation is written is it's actually bundled inside
the module directory as Mustache files, just like Tony was showing for gallery module.
We've actually had a handful of people contributing full examples that they write out, we review
through a pull request, tweak some things, they add some more commits, and then we merge
it in. We can deploy the website at any time we want for the new examples, so even though
we may be three weeks out before the next release, we can go ahead and get an example
live that day.
That's one of the things that we changed essentially over this last year, is adding all of our
documentation being right in with the source code so that these new examples can come up.
It's actually a great way to contribute is people adding examples. It's much funner to
do that than adding tests and definitely helpful for people.
Jenny: I have a question over here.
Audience member: I just wanted to say that going back to the CDN, we can do that today
without having probablyů The Grifter is going to be showing in two weeks, but we can do
that today. Actually we are doing the combo loading from Mojito, that way we use our CDN
but we can use, for example, Amazon. You can build all your CDN where it combo loads and
basically you change the combo load URL, loading the loader and then you build this metadata.
For Mojito we are doing that ourselves, probably, and we believe you can do that automatically
for you.
For answering the Wells Fargo guy, you can do that today, just creating your own metadata
for your modules and just you have the ability to have your CDN with just the combo loaded
concatenated files. It should be pretty straightforward to do today without having to wait until Mr.
Dav publishes his Grifter thing.
Jenny: You guys should connect if you have any further questions about what he said.
I think we have time for one or two more last questions.
Audience member: I was wonderingů We were talking about contributing things that aren't
code to a big ticket or gallery module. Have we considered approaching it with the NPM
model of multiple authors that are authorized to make pushes and such for any given module?
I mean, I don't know, there was a line for the author in the metadata that Anthony showed,
but is that going to be extended upon, do you think?
Dav: 2.5.
Audience member: 2.5, right on.
Eric: I think just for simplicity it's going to start off how it is now where there's one
owner of a Git repo, but that Git repo can be anything, it doesn't have to be the whole
monolithic YUI 3 gallery anymore. That's the biggest change for that stuff, for gallery
2.0 at the Git level.
Luke: All right, let's end this thing with a ***. Naming discussion. We've got modules
that are in core right now that get pushed up to gallery, what are they called? And what
are the gallery modules called? Can we drop the gallery, or would that be a bad thing?
It's all naming.
[laughter]
Jenny: All right, we'll take a vote on that.
[laughter]
Dav: You could actually do that with the next step that I've got running, which is building
and uploading data.
Jenny: Into the mic, please.
Dav: The reason that we're stuck with the gallery- is that the way the YUI seed loads
it is, that's a pattern, so it has to look for that pattern. It goes and fetches one
single file from the CDN. I hate that, I really, really, really, really hate that. In the next
couple of weeks gallery builds are actually going to have a loader metadata file associated
with them that you can combo load and then do a use and it will do combo request for
everything that it knows about.
[cheers]
[laughter]
That's a couple of weeks out because remember I'm on vacation next week, so don't expect
***, all right?
[laughter]
But that's actually what part of Grifter's doing. There's actually a command called yogi
loader, and when you fire yogi loader it does the meta join strip that we always do to build
our loader metadata. If you noticed when you did a yogi update or a yogi create you got
a meta directory that had your data in there. Go into your gallery and say yogi loader and
it'll build you loader metadata for those modules. That's what I'm going to do when
I run a build, is I'm going to go through and run through all of those and I'm going
to generate a loader seed file that you can then require per build and you'll have all
of the metadata necessary.
The same goes for Grifter. It'll go through and it can build this thing and then it could
truncate all the crap that you don't need. Open up the loader metadata, knock all the
crap out of there that you're not going to need, dump in the new stuff and say here,
there's my custom seed, my custom build. At that point I could get rid of the gallery,
but not until then. It's going to take us several cases of Mountain Dew bribery to get
that moved up a little higher, just so you know.
Jenny: Now you know.
Thank you all for participating in this discussion. This is something we're going to continue
online and throughout the year. We have a couple of quick lunchtime announcements, did
you want to close with anything before that Eric?
Eric: No, yeah, thanks everybody for having this talk. I think it's really good to start
this and to continue it and increase the amount of interactions that we have in meetings and
various other forms.
[applause]