Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Table of Contents

Date

Attendees

NameESCo RoleOrganisationPresent / Absent
Project LeadSymphony LLCPresent
Project LeadGoldman SachsPresent
Project LeadSymphony LLCPresent
Project LeadMarkitPresent
Project LeadCredit SuissePresent
Former user (Deleted)AdvisorCitiPresent
Nicholas KolbaAdvisorOpenFinPresent
SecretarySymphony Software FoundationPresent
Gabriele ColumbroGuest speakerSymphony Software FoundationPresent

Actions items from previous meetings

Agenda

TimeItemWhoNotes
5 minConvene & roll call
10 minReview action items from previous meetings

See above

25 min2017 Foundation objectives updateGabriele ColumbroGab will present the 2017 Foundation objectives that were approved at the January 18th BoD meeting.
5 minAOB & adjourn



Meeting notes

  • Quorum is reached - we have a full house!
  • Thanks everyone for voting so promptly on 
    Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
     and  Unable to locate Jira server for this macro. It may be due to Application Link configuration.  - they both passed unanimously!
  • Action item review:
    • Project reporting:
      • Lawrence: how does it map out in practice.  If we're generally comfortable with this set of things, then we should just move ahead and solicit feedback from the project teams.  I see nothing controversial.
    • symphony-java-client CI/CD
      • Frank: I've been focused on code cleanup - removing SonarQube warnings.  There's also a test bot, and I've been working with Mau to get certificate management in place for continuous deployment against the ODP.  Once that's done I'll be calling an activation vote.
      • Nick: is this a client UI?
      • Frank: no it's an SDK for developing Java-based bots.
      • Nick: so SDK on the bot API.
      • Frank: yes.
      • Lawrence: I call it a "API language binding"
      • Mike: there's also a Python client we use internally for testing that we may be able to contribute.
      • Peter: is this related to ?
      • Mike: no - that's a Python wrapper around the bot API.  This is a test UI client that interacts with the Symphony back end.
      • Frank: I'm interested in that!
      • Mike: ok I'll see if we can get approval to contribute that.
  • 2017 Foundation objectives (slide deck distributed via email):
    • Gab: most of you should have seen the overall board deck - it's shared with the ESCo at the same time as the board.  This is an updated summary of that deck.
      • Slide 2: 2017 is the year of our graduation - we planted interesting seeds last year (> 40 projects, > 30 committers).  Thank you all for helping us overachieve certain objectives, while recognising that there were some challenges too.
      • Slide 4: there are 3 high level themes that we're going to pursue this year.
        • We certainly want to focus first & foremost on growth - by this we mean growth of the different angles the Foundation touches on, but especially growth in value the members, LLC & community derive from the Foundation.  Right now our community is highly based on members, so driving value members derive from the Foundation.  One change from the board presentation was removal of the 25% revenue growth objective.  Instead, the major focus will be on growing projects.
        • Q4 focused a lot on improved efficiency, but I want the community more involved in decision making, based on data.  For example with projects we have a lot of data to help drive decisions.  My thinking is the more we involve and delegate to the community, that will turn into value the firms and community see in engagement.
        • Last but not least brand - in H1 we're focusing on FinServ & FinTech, but in H2 we want to message around pure open source.  It's too early to go into developer engagement with mainstream open source communities, given the nature of our project portfolio especially with respect to core contributions.  My experience is we only have one shot at that, so we don't want to oversell to open source communities before we have core contributions.
        • Yearly goals - consistent execution throughout the year, but we decided to only define KPIs for H1.  This decision is two fold:
          1. allow the board to be more agile
          2. also a conversation related to engagement from Symphony and ongoing discussions around core contributions.  With the board we agreed to re-evaluate that situation by the end of H1 and take appropriate measures depending on where we land.  Last year we built a plan with external dependencies, but now we have a strong dependency on members engaging in the Foundation. So for 2017 we've minimised dependencies on LLC.
        • During the board meeting there was renewed interest in open source readiness.  Thanks especially to John Stecher & John Madsen for their help in completing the GS CCLA - I think that really brings renewed focus to the other firms to engage in the same way.
        • Finally we can attach to open source ecosystems, especially in H2.
      • Slide 5: corporate score card for 2017.  Some highlights:
        • Brand:
          • Grow in terms of both FinServ (H1) & open source (H2).
          • Lots of social media metrics.
          • The SSF Way - the way we as a community behave and etiquette we use.
        • Growth:
          • Different dimensions, though revenue growth was removed (churn remained).
          • Working Groups moving to Aaron - focus on increasing value to existing members as well as growing the project portfolio.  Frank and I made it very clear in the board meeting that we need your help with this - not only developers, but help us identify which are the highest value use cases that we can do out there.
          • We're thinking of more structured ways of gathering this information, but one of the fundamental ESCo charter items is to help drive the technical strategy of the Foundation.  My expectation is that you'll be able to help us identify how to maximise the value of the developments done in the Foundation.
        • Efficiency:
          • We'd like to work towards more comprehensive metrics - definitions of "health", and reporting to support it.
          • Lean data driven organisation is an internal goal - includes things like automation, and how we collaborate with the community.  Hubspot (CRM) is an example of this.  Improving how we reach out to developers, the community and the open source ecosystem.
          • Last but not least I want to make sure we do everything possible in our power to drive further engagement from Symphony.  Lots of board discussions on this topic, but here I'm specifically addressing the need for a "bottom up" type of engagement - making LLC engineers love working in the Foundation, and delivering value back to the LLC.  The hope is that this will foster more organic contribution from the LLC.  This is in efficiency because it's been challenging and time consuming, and so there's an opportunity for us to be more efficient and leveraging organic contribution instead of pushing and pulling.
        • Nick: question for Lawrence: where is the LLC in terms of positioning open source development?  Are you doing things internally to do more development in the open?  How's that going?  How can the Foundation help with that?
        • Lawrence: if you look at the activity information presented at the last board meeting, there was a big ramp up in Q4, and we had a huge amount of support from the Foundation team.  As we go through the process we're shaking out issues e.g. how do open operational processes work.  It's been a really good process, and we're still ramping up, but what we did in Q4 shook out a lot of the practical issues, though we're still smoothing out some of the operational engineering processes.  Now we plan to do more via public code bases and we intend to ramp that up.  Going through the experience, I'd say you can't just slam everything out in the open - things have to be figured out.  There's quite a bit of complexity in switching from an internal to an open development model, and I feel like we're now in a good position to accelerate that.
        • Nic: I can second that - much much harder to go from closed to open.
      • Slide 6: magic animation is missing, but this was intended to show the high level strategy and where we see a successful Foundation operating.  For 2016 we landed in the lower left, but for 2017 we want to get to the top right - where developers are communicating by code.  But even landing in the bottom right, while sub-optimal, is very different for me to show value to members.
      • Slides 7-14 go into more detail into how the corporate objectives for H1 map into priorities for Q1 & Q2.  Please read through those slides.
      • Slide 15: we need your active participation in succeeding with this plan - third bullet point in particular.  What can you commit, from an ESCo standpoint, to grow engagement from the membership?  Being in ESCo is a very visible position, and can bridge the gap between the business objectives of the board with the implementation of those plans.
        • Venkat: from my perspective we have a specific project we're interested in ().  We'll definitely be contributing to that.  For hackathons & developer events, we'd love to connect with someone on the mechanics.
        • Gab: Peter - can you take an action to introduce Tinne to Venkat?
        • Peter: sure - Venkat I'm also taking point on hackathons for the coming year, so I'd be keen to talk through the mechanics of those events with you.
  • AOB:
    • Proposed changes to Desktop Wrapper WG charter
      • James: I sent out an email on Friday with proposed change to DW WG charter.  Does anyone have any feedback?  This hasn't been voted on by the WG yet, but everyone is broadly supportive.  Outstanding item is discussing with Jim Adams at DB regarding desktop interoperability - that's scheduled for next week.  The possible outcome is that point 3 in the draft charter would need to be adjusted.
      • Frank: I like the first point.  Second point is good.  Third point I'll come back to you on.
      • James: yeah it seems the third point is potentially contentious.  Part of the confusion is that some of the desktop integration APIs might be moving server side (as JC discussed at an earlier WG meeting), which might mean that desktop integration and the DB proposed integration end up operating in the same space.
      • Lawrence: yes definitely a question of what the technical evolution path looks like - making sure the WGs are working with a defined technical path.  That's a consideration, and another structural consideration is figuring out with the DB / Autobahn discussion how it fits into this working group vs creating a new one.  I've heard some WG fatigue (how many WGs we have) - if we have the same people going to all the WGs then that gets difficult.  I don't have a religious perspective on it, but I think we should have a conversation about how those initiatives tie together.
      • James: makes sense.  I guess there's two points:
        1. In terms of how we reform the DW WG charter
        2. How do we organise this interoperability thing, given there's this other proposal out there.  Question is just how do we get to a conclusion on that?  I'll chat with Jim next week on that.  It doesn't seem time-critical.
      • James: with the API WG we bounced back and forth a bit on the charter, so I wanted to get this in sooner and look at things like how we influence the LLC.
      • Lawrence: two thoughts:
        • On the mechanics of getting DB involved, it'd be good to have the conversation about WG structure in the WG, so that everyone can participate around the table.  DB seems very interested in moving ahead with their contribution, but the longer discussions go on we tend to lose momentum.  I have a bit of a "strike while the iron's hot" thought here, and getting DB engaged in the WG and pressing the initiative ahead is probably the right thing to do.
        • On the text of the charter, I think there's a little question about the wording of "influence by these actions" vs "actions that result in influence".  Not a strong objection but I would reword it to the latter.
      • James: ideally what we really want is people to contribute, and that becomes their method of influencing.  But in some cases we just can't do that because it's LLC code.  But if you have preferred sentence structure I'm not wedded to this particular form.  We do have to take on influence of the LLC to do some of these things - if LLC doesn't do some of these things, nothing happens.
      • Lawrence: I'll send you some snips, but it's basically flipping the way the sentences are written to be action first, influence second.
      • James: any other feedback?  I'll be meeting Jim next week and don't want to be a bottleneck for DB's contribution.
      • Lawrence: are they on the invite for the WG?
      • James: I believe so, but they don't turn up that I recall.  Jim certainly isn't on the invite, though I'm not surprised given his position in the firm.
      • Lawrence: given the WG is meeting next week, maybe he should be invited to talk through this?
      • James: yep I'll suggest that to him.
      • Venkat: one of the things we've been talking about are new features like desktop sharing - we will be actively working on that.
      • James: yes the WG is very interested in this, and we want an open container to support this kind of contribution.

Action items

  • No labels