 Good morning, good evening, good afternoon. Apologies for missing last week's excitement and the week before, but somebody's got to be on vacation, so I was gonna be me. I was up in the wilds of the Canadian Rockies with all the smoke, but it was a lot of fun. I want to take a moment and just congratulate the new TSC and give my thanks to Greg and Ram for their service for the past two and a half years. Jonathan actually. And Jonathan, yes, sorry, yes, and thank them for their efforts because it's been great this far. And so congratulations to the newest members. On our agenda this morning, we have our usual event reminders. We've got the TSC chair selection process that Todd will go over. We have community health working group discussion and then we have our Debbie of Updates composer, I think, is Simon on? Yeah, hey, Chris. Hello. All right, thanks Simon. And cello. Do we have who's doing that? Aua or? We have a new maintainer, Luke Chen from where we will do the report. Awesome. Great. Thank you. And then we have no working group updates this week, but next week we have architecture working group. And we also have the hyperledger explorer update the following week. So, and then just I don't know, Tracy, when are we gonna get closure on the copyright stuff? I know that it's tough with everybody traveling. We've got a legal committee call scheduled for next week, September 5th, I believe. So that went out to all the premier member legal counsel, which is how that's. And did you get a response from Jerry? I honestly did not yet. Okay, I'll post Peter. I think he's on holiday. But that is scheduled, so it's moving forward. Yep. Okay, super duper. All right, any other items for the agenda? Hearing none, let's move on. So, Todd, take away. All right, super quick on the event stuff. Hackfest October 3rd and 4th Montreal, please get registered for that. I'm just gonna pull up registration quickly. But going on from there, looking at Q1 of next year, please let us know your availability and the doodle poll. We want to get that scheduled well in advance. Oh, so going back to Montreal, quick heads up, we already have 86 registered for that. So that's extremely healthy for about a month out. Anyone else, please get your name in there ASAP. And then the last piece on the event front is Hyperledgic Global Forum. Yesterday morning, the full schedule and keynotes were announced for that. So two days focused on business and technical tracks, as well as a wide set of keynotes, and then two days after that, more on the workshops and labs front. So please take a look at the schedule there and get registered if you're planning to head to that. It's gonna be a great event for the entire ecosystem. Any questions on those three events? All right, so quick heads up on the next part. As Chris said, the new TSC was formally elected as of Wednesday night last week. So now the 11 TSC members are voting on the chair for the next 12 months. Chris Ferris and Dan Middleton were the two nominees for that. So that election for chair will conclude on Wednesday of next week. So we'll get that announced out with the agenda and just congratulate the winner from that on Thursday. And with that, I think it brings it over to Ry, Ry Tracy, on the community health discussion. Sure. Thanks. We have we, Tracy, David Boswell, and I had been discussing how to gauge community health. And we fortuitously circulated this community health working group charter right for the very robust discussion about diversity in our working groups and hyperledger overall. We had a few comments from Dan Milden, Hart Montgomery and Mark Wagner. And we are looking for more commentary. What we want to do is to be able to measure the health with, you know, objective, objective metrics that the community agrees on and present reports moving forward on the health of of our projects and our working groups. And we would like to bring this to the TSC for the vote for formation next week. So I would really appreciate, you know, any questions or commentary. And anyone has any questions? Or Tracy, do you have anything further to add? Yeah, I mean, definitely, you know, if there's any thoughts that you have in kind of the next week, if you can review the document charter that we put out there for the community health working group, we would highly appreciate that so that we can update it in time for the hopeful vote next week. Now, I would view something like this almost as somehow morphing some of this into a checklist for deciding if something's ready to be a project, right? We would have a set of guidelines that we're looking for for health of a working group or a project. And then as we're deciding if we accept something down the road, you know, we could say, well, they're going to be able to meet these things, right? Is that part of what you're thinking with us? I mean, I think when we really put it together, we were only thinking about the project that exists in the umbrella. I'm sorry, the greenhouse today. You know, obviously, I think there's a lot of things that we could do and looking at community health that that is, you know, something that we think it might be useful for, then we can definitely put a, you know, as we figure out what those things are that we want to look at, we can think about how that would impact incoming projects as well, or even maybe these working group proposals, right? Cool, thanks. Yeah. This is a VIPIN. I have a couple of questions. One is there's already a framework around reporting the health of the projects and working groups to the TSC. So will this be yet another way to report on the health? And what about the health of the community health working group? Who is going to police the policers? So, you know, this proliferation of, I mean, it is a good thing to have a community health working group. They should be assisting others in constituting not only the working group, but also to spread the word about the working group. That would be a good thing. But to have another group that is just responsible for measuring other groups, that doesn't seem like a useful exercise. So how I read this proposal is looking at investigating what's working and what's not working and what kind of patterns might not be in there explicitly. But what kind of patterns can we identify in projects that have healthier communities that we can help encourage in projects that might not have reached that same level of success? That's definitely a good way of saying that, Dan, right? I think, you know, we can learn from one another, right? That's part of why hyperledger exists and why a number of different projects exist is to be able to share best practices and those sorts of things. And so I think you're hitting the nail right on the head, Dan, where we were at. Some things are going to be healthier, right? And it may not be the same thing, right? So different projects may be healthier in different areas and the projects can learn from one another. So, yeah, definitely something worth thinking about. But isn't, so, and again, I apologize because I missed the conversation previously. We haven't had that. Isn't this what we do with the quarter of reports is within this sort of strongly hinting at where we already have identified a set of things that we'd like people to come back and report on, such as maintainer diversity, although, again, diversity is different facets of diversity, obviously. Contributors and so forth, as well as content, you know, so all those things, I think we had robust discussion and debate in the TSC previously about what should go into the quarterly reports. And I think that the quarterly reports themselves have been an effective means of stimulating conversation amongst the TSC and with the members of the various projects on, you know, providing up with suggestions on how they can improve and so forth. Isn't that so I guess my point is I don't disagree that this kind of a dialogue isn't useful. I'm struggling a little bit with and how is that different than what we're doing with the quarterly reports and maybe then applying a little bit more formal methods to identifying things like how many contributors, diversity, you know, maintainers, all that stuff and just maintaining some sort of a dashboard. Again, I don't want to say that we shouldn't have this conversation. I'm hoping that that's, in fact, the point of the quarterly updates is to continue to see what's going on with the projects and for those that are struggling a little bit to have the wisdom of this team and others, you know, shared with those teams to help them improve. Chris, I think one way to think of this would be one step more meta than that. It's, you know, what are the kinds, it isn't intended to replace or duplicate the quarterly reports. I think intended to be a place to say to have a discussion in a more, you know, out of band from the technical steering committee kind of way of what should those health reports say, you know, what are the useful things to try to measure and if there are some deeper issues with a particular project, perhaps a place where that project or even, you know, conceptually there can be conversations about what does health mean in the context of hyperledger and the community here. And I think, you know, you'll also see more metrics work being done going down the road and this can, you know, which I think might result in software sitting in labs or maybe even a full-fledged project proposal at some point. But this can be a place where conversations about what are useful metrics to try to track and conversations like they had about the diversity topic, for example. It can be a home for that and a place to kind of focus those conversations into some sort of tangible output, you know, like we do with other working groups and we can always talk about architecture and identity and performance at the TSC call but having separate working groups for that allows a degree of focus and bundling, not to silo it off but to just give it a proper home and that's something to check in on a regular basis. So I hear too... I hear too... Do you see this as a metrics group or as a best practices group? Exactly. You know, I don't know that those two need to be separate from each other, I think. And I'm not suggesting that they have to be separate from one another but I hear two themes in the descriptions that you have. One is sort of the metrics and how do we measure and the other that I heard from Dan and Tracy earlier was well maybe what we should be doing is figure out the best ways to build community as well. Well, there is another dimension. There is a different dimension which is whether it's only defining the metrics or it's actually applying those metrics to measure and produce results like measurements on how the different projects are doing against those metrics which is the police angle that was referred to before. So I want to make sure that Vipin gets a chance because he was trying to chime in the same time that Vipin did. Yeah, I mean I think Mick said what I wanted to say which is that there is this double sort of aim. One is, so is the group going to be much more of helping people? Or is it going to be more like saying, oh, you're not doing the right things we're going to tell you that this is the right way to do stuff. And if that is the way that the whole group is going to be formed and going that direction, then I have serious objections to it because already the working groups are working hard to create content and to create value. Now to have one more group hovering over the whole thing saying, oh, you know, you guys should be doing this. So we come to the TSC with a full disclosure of the metrics. So now if you want to add more metrics then have it in the quarterly report. If the aim is to help people to increase diversity, to increase like Dan said, then I'm all for it. Yeah. So I want to echo what Mick and Vipin and Arnaud were saying because I think it's fine if we have a whole consistent way of measuring things like the number of contributors, the diversity of the contributorship, the number of maintainers, the diversity of the maintainers, again all the different facets. How many commits, how many releases, all those things that we can and I'm okay with having a group to sort of maybe harden a little bit about what we already have in our quarterly reports in that regard because the report already basically asks the various project teams to report those things. Now maybe that could be refined a little bit and maybe there can be a focus on the developing tooling and so forth that allows us to be a little bit more formal about that and maybe even create some sort of a dashboard that the TSC and others could use. I'm also fine with having discussions about how do we as a community improve our ability of outreach and acting new contributors, new people to our various projects and helping and maybe even articulating some best practices that can be shared with the various teams. What I'm really very uncomfortable with is the middle bullet of the work products which is quarterly reports on the status of all the working groups and projects because we're already doing that and I think to Vippen's point now we have sort of the checkers of the it's like I thought that was our job here in the TSC is to review those reports and provide immediate and sort of pointed and helpful hopefully constructive feedback and now we have a working group that's going to be reporting on what they think the health is. I don't like that at all. Again I'm fine with the discussion about how do we improve the reporting, how do we do a more rigorous approach for counting things and what are the ways that we can increase diversity that we can increase our contributors and so forth all for that as a separate discussion. I think we need to go back to the first statement in the introduction of the charter which is an assertion basically a question I think rightfully. It says the health and viability of projects and working groups is not well understood. Maybe I'm deluding myself. I have the feeling that I get a pretty good sense of what's going on thanks to all these reports we are forcing people to get through. Maybe we need to get back to what problem are we trying to solve? Well I think a couple things came to mind as I was looking through this. One is completely different from what we've talked about so far but I think there is an interesting mention down in the proposal that this working group would start off by not having regular phone calls because the time slots, it's hard to find a time slot that's geographically acceptable across all those different time zones. There might be some different ways of just operating here that might be interesting. The other thing that stuck out here was actually more in conversation that I think was a heart that I was discussing with and he made the observation and I think he might be on if he wants to make this himself right now that there's subject matter experts that we'll be looking at say privacy or architecture or other things. This seems like a form where we could draw in contributors from our companies who are subject matter experts in recruiting and diversity and so on so that those of us that might not have that experience or those skills aren't trying to reinvent the wheel or maybe arrive at counterproductive solutions. I sort of viewed this as building community health, building ecosystems, things like that versus an overlord. I think that could come in and help here a lot. But what Dan was talking about sounds more like best practices again which is different from metrics and reporting. I can see how the second work product was phrased in such a way as to trigger some of this response and probably because I think where it came from was this idea that some of the scripts that Tracy has written and Chris I know you've written and others might be usable in the form of a sort of dashboard that might come out if you regularly run metrics which the self-reporting from the projects the TSE doesn't have right now. But that instead of just dumping metrics that the community health working group or perhaps the hyper-legislative staff would help the projects interpret those numbers and kind of like the weatherman looking at weather data might help give a sense of that, not to replace or to run for the projects they're quarterly updates to TSE. So I think I was phrased kind of clumsily and probably could be improved to be more specific to that and not come across as a competitive thing to the quarterly reports to the TSE. So I kind of viewed this group as more of a resource to working groups and projects rather than a policeman and so the point was that if some working group was having issues or some project was having problems then this group would kind of be a collection of open source veterans who could help out. And I think that might be useful for people that may not have been around the open source community for as long or are kind of experiencing growing pains or something like that. So I think if maybe the proposed charter could reflect that a little more. I was going to come in with a point very much along those lines and I think I like that idea. So could this be shifted to be more of an intervention group? So if I think about from my own experience with Burrow we don't have the need to interpret some kind of big data metrics around contributors. I know everyone who will have contributed and I know a lot of the areas where I could do with some help to say for example have someone who has expressed an interest actually be handheld over the course of a month. So you could perhaps imagine a situation where you have a batch of quarterly reports and maybe a group like this could specifically target some interventions over the next quarter or maybe a month in the next quarter to actually apply some resources to try and fix a specific problem. And in the conversation that was happening around diversity for example one of the things that came up again was actually encourage and cajole people to stand for things or to go and do things. So I mean community harassment working group harassment is an unfortunate choice but in terms of like actually harass them into doing good you mean? So what happens for me is with people that have expressed interest I get distracted onto my day job having tried to get them started and maybe that's when they fall off. Whereas if there was a dedicated resource that we couldn't have all of the time but we could have specifically that would be a different task because I also don't like the idea of duplicating the evaluation part that the TSC does but if it was an intervention thing a task force that's different. Yeah I mean this is Silas to that point actually a lot of projects as they mature or organizations they tend to develop that particular type of a role where you actually have people that are doing a lot of what I know Tracy and I'm sure Rye and David are doing in terms of going out and saying here's how you land your first commit and so forth and that in a general way that's fine but you know sometimes it's also just helping people sort of navigate through where the issues and which one should I work on and can I add a new feature all those kind of things where sometimes people just need that extra sort of onboarding kind of support and if that you know again but that's a very different thing than coming up with just best practices you know that's actually sort of a role that people start to take on and then they spend a lot of time in either presenting that or you know serving in that function within the community as a sort of a social blueprint if you will to get people onboarded. Yeah I think sorry go ahead. Yeah I do believe that health is very important in the community and I also believe that there's already the sharing for each other working group and the most important output in the group chart is the metrics and best practice both are good things to the community but my only question is that is this outcome actually almost inside the scope of the GSE? Yeah do we need a special working group for that? I'll just say one of the things that I hoped that would come out of something like this working group is we have lots of phone calls and it's not clear they're optimally scheduled so if this working group say you know did a bunch of research and came back and said hey hey guys we tried a bunch of stuff and in our experience this phone call schedule works best for this kind of group to maximize your participants you know and then they could say like maybe you could try it if you think your working group looks like this or something like that. So that's what I was kind of hoping for. I think that's in the charter is that kind of what the people had in mind for stuff like this or? So I think I'll just add a couple things and then I know we do have kind of a meaty topic following this so I don't want to delay this too much but you know obviously there's a hypothesis that we're not very geographically diverse right that our working groups and when they're held are not conducive to people joining right I know we specifically are impacted by that. I am specifically impacted by that based on some of the times that some of our calls happen and I'm sure other people are as well right and so we want to make sure that we're opening up Hyperledger to the majority of people and then secondly you know if we think about back to Nathan's project update where he you know reported that he has some you know he wants to get more people involved but he's not quite sure how to do that you know and I think the TSE nodded to that and say yeah we need to find a better way for that but nothing's been done right we haven't necessarily made any progress on that well specifically right I think you know David and I and Rai went back and after that call and said okay well what are the sorts of things that we could you know do on the Indie project to make it more conducive to new contributors coming in and that sort of thing and probably written up some notes and provided that to Nathan and I think that's the sort of thing that we want to continue to be able to do is to help where there's things that need to be helped but do it on a much wider basis so it's not a one-off right where we're only helping one project we're truly coming up with what are the sorts of things that all of our project should be doing to make sure that we can bring in diversity and we can bring in additional contributors and that sort of thing so I think that's where our head was right is let's see if we can prove or disprove some of the hypothesis that we do have about the health of our community and what are the specific things that we can do to make sure that we're if those hypothesis prove to be true we figure out how to make a difference right make an impact in improving it so that other people can contribute. Hey I've got a quick question this is Dave, does the Linux foundation have any like YouTube videos where the topic is so you want to contribute to open source and it you know starts from the very beginning like you know how to program or you know how to translate or you just care and want to join in I don't think I've ever seen a video like that which assumes that you know nothing Yeah but I don't know that it's for Linux generally or you know the whole Linux foundation and all the collaborative projects as much as I know that for instance Kubernetes does right there you know again they've cultivated this role of sort of community advocate that gets out there and helps people on board and provides this kind of feedback and so forth I mean that's their job right it's kind of like the role that Ryan Tracy and Dave play in terms of but again that's a paid role where as I know in CUBE it's a it's a it's a volunteer you know you've got people like Sarah Novotna, Novotny rather who's you know that's her that's her primary function is to sort of be the one that gets out there and drives you know increasing diversity and drives additional contributors and Tracy did a webinar entirely on this too and that recording is there and it's been promoted and there's some other broader stuff that has been done and I know more coming down the pipe but anyways this is a group to have those kinds of conversations within like is there content to create that sort of thing And I sort of viewed this I mean I had made a comment in the email thread that I think there's a big difference between some of the working groups and some of the projects you know I think like Fabric most of your people you know the developers working on it are probably getting paid to do that job where I think some of the working groups it's much more volunteer effort and so I you know I think there's a difference and trying to figure out and understand those differences because maybe what we need to do with the working group is different than what you need to do with a big project like Fabric or Sartuth and I think this would be a way for the you know maybe working group is too strong you know it's too much organization but you know maybe some kind of committee to go off and understand those things I know the performance and scale working group I didn't feel we were making a lot of progress at one point so we went from meetings every other week to a weekly meeting and I felt things took off when we did that and I know personally if you know I have an hour meeting and I have a two hour action item that's due in two weeks I'm not going to do it till just before the next meeting and I think you know I'm sure there's a lot of nobody else is like that at all but I think that you know that doesn't get the stuff out there for discussion whereas if it's weekly then that's you know right on my list of things to do and if it's not part of my day job you know it's hard enough getting it near the top of my priority so I think understanding those differences is good maybe we don't need a working group for that but you know a way to go through and do that and help new groups when they form versus you know an overwatch on fabric is hard to I don't think we need that but you know what can we learn from those projects or other working groups that have gotten the white paper out we had hard come and talk to the PSWG about you know okay this is what you're going to need to do now so that you're going to you know you're getting ready for a tech writer and things like that and that was very valuable to us so I think there's a need for something yeah I yeah so Mark I totally agree I just I guess you know the discomfort I have I should say is with the whole reporting on the report you know on the projects and the working groups because I think and I think that's also in the TSC chat we don't necessarily want to set up some sort of an adversarial type of a situation there but I do think that you know having discussions on how do we increase diversity you know from both you know at all of the different things and how do we go about and attract new contributors and how do we address the fact that a lot of stuff is sort of paid development versus volunteer or you know contributions I'm happy to have that kind of a conversation although again I you know I tended to think that as we do the various reports those kinds of things come up and we have solid discussions here in the TSC and I wouldn't want to divert that necessarily I think we still need that and so anyway there we are I maybe if we just sort of modified the charter so that it's not so much some sort of oversight as much as it is a set you know coming up with an initial set of recommendations and then you know maybe periodically I think and now I forget who was it suggested maybe Silas you know that when issues come up then the team can convene and sort of do some deep thinking and report back to the TSC on what they call it makes sense maybe Tricey and Rye you guys have enough feedback and everybody else who wants to constructively work on that and have enough feedback and we can give some time then to the rest of the agenda topics here I'll take that as a yes I think you're on mute still Tricey so thank you and Rye and David if he's on okay next up is composer Simon hey I don't know whether everyone has had a chance to read the update I put in this morning along with the letter to the mailing list from the IBM contributor team I posted them in the TSC channel the email whilst I'll go through the update and then maybe we can discuss the email which is probably the more interesting part of it firstly apologies that this is four weeks overdue it's summer in the UK so I've been off for quite a few weeks anyway let's move on so in the past quarter we continue to see significant amounts of activity on rocket chat and stack overflow from people trying out composer using it hitting issues and asking how they can do certain things and as always the IBM team has offered two full-time people to help work with those users and get them up and running answering the questions we're also continuing to see contributions from outside IBM but these are again still really minor contributions such as doc fixes typo fixes that kind of thing I've released a new major version Composer 0.20 and this release has a small set of features since 0.19 which I discussed on the last quarterly update but the major new thing in this version is that it supports deploying to Fabric 1.2 so allowing you to use some of the latest features in Fabric it's a feedback application project using Neoman Generator one of the regular pieces of feedback we got from the community is you've got this great REST server, it's really easy to get started and up and running but I need to customize it to do X where X is add my own APIs or add my own authentication mechanism or just add my own code to it and you couldn't really do that because we just packaged up a REST server and you can really have a chance to edit it by slowing down the composer code yourself and tweaking it so the new generator generates a REST server on disk you can edit the code to your hards content we've also made some changes to transaction processor functions the first one of which is exposing a Fabric functionality where a blockchain transaction one as executed to smart contract can return data to that smart contract and this is basically a performance improvement because what we were seeing is that people would submit a transaction they weren't able to send any data back with that transaction so they had to then send another request into the smart contract to say oh could you get me the updated data so the bypass is the need for that second query you just submit one transaction and it returns the updated data that you need and the second update to transaction processor functions is being able to mark them do not commit or read only and this is to solve another common community requirement where in composer before if you wanted to query assets or participants that were stored on the blockchain you were limited to our sort of crud operations so get all or get by ID or writing queries using the composer query language which is a SQL like language for selecting data on assets being able to mark the transaction processor function as do not commit means it's basically the same thing as a query function where you can write any code you want for querying data from the blockchain network and this lets you use any of the composer and Fabric APIs to do whatever querying you like and additionally on top of that filtering of that data but on the server side rather than having to pull it all back to the client application and filter it there so again it really came about as a performance requirement but it's also useful for exposing additional functionality to users in terms of contributor diversity I've listed them all in the project update we've had various small PRs as I mentioned from several other companies I won't go through them all here and we haven't changed our list of maintainers since the last project update any questions on that? Thanks for the reporting actually I was asked this question by several people so do you know is there any protection usage to include the Hyperledger Composer so at the moment within IBM we know of one production project using Composer can you share more details? Not sure how much I can say but it's a European banking consortium doing trade settlement We know what that means Anyway I'm not sure what I can say but a couple of questions for you one is that email that you mentioned I read both the report of the status and the email the email somehow seems to imply that there is a chance that Composer it is the sunset of Composer or that you are producing investments in it IBM is and that it is going to be phased out in a sense but I do also see some green shoots there which is Selman's proposal for a model modeling language that would be platform independent which was of course the dream of the Composer in the beginning so that's the first question is why should you use Composer meaning is there anything that can be done in fabric except for let's say private data objects 1.2 stuff that cannot be done with Composer? I'll go for the second question first as I think that's easier to answer is there anything you can do in Composer that you can't do in fabric or the other way around? The other way around I mean I hope there is nothing you can do in fabric I mean in Composer that you cannot do ultimately in fabric because that's the only system you have yeah it's just code right so yeah there are things plenty of things in Composer and that is one of the reasons you will see in that email for IBM's decision. The example I quoted is private data collections. Now once we have exposed all of the underlying fabric APIs from within Composer private data collections requires additional configuration to be provided as part of deployment and currently we don't expose the APIs or command lines that allow you to provide private data collection integration which is why you can't use it with Composer today. Yeah sure I mean I did explicitly call out private data collection as not my focus. Is there anything else? There will be other things coming up so certainly in Fabric 1.3 there's work being done with Identity Mixer that will not just magically start working Composer when we start to import Fabric 1.3 that will again require changes Composer to enable it. Those are the two main ones in my head? Yeah I understand that you don't have a smooth upgrade path because of the way things are set up but in terms of the existing one like let's say 1.1 are there any things that you cannot know? For 1.1 I think we're okay. Is there direct support for the policy? I didn't think so. Is that it again? I said is there direct support for supporting all the various policy derivatives that you might have for how many endorsements to retrieve and all that stuff? If I provide the endorsement policy during deployment so that bit's fine. Although saying that I don't think we really respect the endorsement policy in terms of picking. That's kind of what okay that's the part it's nice to have a policy but then if you can't follow it then that doesn't really help you. Well we try to follow it we just send it to everyone Oh I see. And then you get a bunch back that don't matter. I hope that sort of clear is that when you features go into Fabric it's not just a matter of them magically appearing in Composer there is a significant amount of work to be done to re-expose them in Composer. I just wanted to go ahead and dip in another question. No just the first question which is a sunset of Composer. So the statement in the email sorry if that wasn't clear is that it's an IBM resource decision where my team in IBM who is tasked with the developer experience for blockchain use reducing the amount of work we put into Composer to focus on delivering updates to Fabric. That doesn't mean we're dropping off the face of the planet and leaving Composer to itself we're going to continue to update it to support the latest Fabric releases and if any high priority bugs come along then we'll pick those up and fix them but we're not going to be doing any new feature work. And that's not a forever statement at this time that's a we might be back but for the time being most of my team will be working directly on Fabric instead of Composer. Right and to make sure that we're clear it's maintaining compatibility with the existing set of capabilities that Composer has with respect to Fabric Yeah that's a good point and that is so when 1.3 comes out we will update it to run on a 1.3 Fabric but we will not update Composer to support the 1.3 features unless they are simply API updates that can be used without exposing additional configuration and then right and then to the point that I was going to be adding is that you know again as the sort of the having the responsibility of your team of addressing sort of the developer experience and so forth you know a lot of thought was also given to the fact that the existing SDKs are really very sort of granular you know sort of low level detail kind of stuff not really very well the user experience isn't the greatest let's just say you can do a lot with it you can do a hell of a lot with it but or with all of them right and go and so forth but the problem is is that they expose too much and so from a developer perspective you don't have the simplicity that you might have with something like Composer that is essentially hiding a lot of the gory details about how you under you know how do you retrieve the endorsement policy and then how do you prepare a proposal for each endorser and ship it off and compare results and all that kind of stuff right so a lot of that stuff gets hidden in Composer whereas with the SDKs you have to manage that all yourself yeah and so a lot of the focus is on proving that UX from an SDK perspective right so so that the SDK and then the ability to write chain code and so forth is significantly simplified right yeah and I cover that in the mail so as you touched on there the Fabric SDK if you want to submit a transaction to a fabric network wait for it to be committed and be notified of that that's somewhere in the region of like 50 lines of code and in Composer that's five lines of code and as Chris mentioned we hide a huge amount of interactions with the Fabric SDK in Composer and this is really wrong with Composer was never designed just to make fabric easier to use it was designed to make it easier to take your business use case and map it into a running blockchain network and that's why we have the modeling language which also provides a huge amount of confusion we've seen where someone sees a Composer application that has you know a five lines of code to connect to a network and submit a transaction and then they see the Fabric version of that and they're like how do these two actually map together are they doing the same thing is Composer just doing magic and that's another one of the reasons for our current plans. Hi Simon this is Leonard just a quick question thanks for that update I was just wondering about the modeling aspect of Composer is that will that eventually disappear based on this sense of the clause or will you provide for business use where they can actually model their blockchain environment and not have to worry too much about the you know sort of the very detailed programming aspects to capture their business requirements, their business and the smart contracts that would need to be generated will you continue to provide a model and interface for better business user experience in designing their blockchain you might say network. Okay so that's a great question so firstly Composer isn't going anywhere we're not going to delete the code website or any of that so you can continue to model your blockchain use cases using Composer. We strongly believe that modeling your blockchain networks is the way forwards we've had so much good feedback around the modeling language and how much easier it makes development and how much better it is at engaging the business people in the development of blockchain solutions and at the bottom of the mail we will see a reference to some work Dan Selman is proposing to do he is on the call where we sort of look at pulling out the modeling language from Composer as it is today Dan is using the modeling language in the work he's doing in clause we obviously use it in Composer we could take that modeling language and embed it into other blockchain platforms as well for example Interfabric, Sawtooth a library that lets you describe a blockchain business network or a modeling language that lets you do that and a library that lets you write programs that interact with that model so it's really valuable code maybe it is worth pulling that out and managing it as a separate project If I can just jump in for a second because I do think we should leave some time we're seven minutes to the end for the cello update in conversation there but just really quick I want to thank you Simon for the transparency that you're bringing to the internal IBM resource discussions and decisions and B I think this is an inflection point for the project it doesn't necessarily mean the project should be wrapped up it's kind of saying the current direction is one that gives a lot of people who have been involved with the project concerned about the direction and that's leading to perhaps a change in leadership I think the follow up question should be what does this mean for the future of Composer and that kind of conversation should really happen on the Composer developer's mailing list and now might be the time if any of you have used Composer have found value in its existence in terms of recruiting new people into the community to kind of direct your attention or other people's attention over to that list and start the conversation there what might a 2.0 of Composer look like, what might a modeling language future look like and does it make sense to have a stand alone thing like Composer or plugins for other dev tools out there IDEs you know I can say it's been extremely helpful to be able to say here's a pathway for not just the elite developers like all of you but for average developers to be able to bootstrap and start building in the context of a hackathon that demonstrates doing a blockchain thing even if that wasn't a toolkit for taking it all the way to production even though it was just kind of a taster and I think we need something like that and I think even a very radically different approach and code base could carry the mantle of a Composer 2.0 but it needs to be rejuvenated and I respect IBM's decision to make its internal kind of resource decisions that were to put its people for any company right so I wouldn't encourage us to think right now too much at the TSC level what the future of Composer should be let's direct it over there but I do want to thank Simon and obviously IBM and the rest of IBM for having put so much into Composer and giving us something that's been so strong in bringing in new developers to the community So Sunset does imply Sunrise tomorrow so you're an optimist Even the Apache Web Server project started when a bunch of student developers on the NCSA code all got hired away by Netscape and the rest of us users kind of looked at each other and said well I guess we got to take over so a completely possibility is that the users of Composer kind of have this moment of self-actualization too but I'd like to leave the door open for that and also say like the project could continue even if the approach and the code base underneath take a radical change because I think what people think of as Composer is this non-ramp and I even like the idea of making it more framework agnostic, making it higher level and not so deep in the weeds with fabric as the current approach Unlike people I know we don't have time for deeper discussion now but this ties back to the previous discussion we had about the community working group type of thing if we had some organizational thing there that could help here so when a company decides that it can't invest its resources in a project it's been sponsoring is it completely up to the community to figure it out or is there some type of organization within Hyperledger that could help figure out how it picks up the pieces and keeps going because there might be uses outside of IBM that are going to get left in the dust here if they can't pony up resources to do it on their own I think there's a complimentary flow of that too of that information that I have viewed Composer is a very successful project in terms of popularity and I read from your note Simon that that hasn't translated into contributors and so feedback assuming that we get this working group moving forward feedback into that working group about what didn't work even if we didn't figure out what would work I think would be helpful Okay so we have two minutes left and that's really not fair to Chelo. Bawa and team I'm hoping that we can defer until next week is that okay? Alright thanks Bawa and so I would like to thank everybody I think this was a healthy discussion I think that the point on having something that's wildly popular and yet you don't see a whole lot of return on having new people come and join I think that's pretty much across the board to be honest I mean there are to some of the projects there are more contributors and there's a greater diversity but it's still I think there's still quite a few especially ISVs and even major vendors that are using some of these platforms and or tools and not really contributing much back so I think there's a lot we can do in that regard and I think having a discussion on that would be valuable whether it's in the TSC or in the working group so anyway so thanks everybody and we'll see you all next week Thanks Chis. Thanks everyone have a good day. Welcome back Chris. Thanks. Welcome back. Bye