Bootstrapping an Open-Source Program Office at Blue Cross NC
Download as PPTX, PDF0 likes49 views
The document discusses establishing an open-source program office (OSPO) at Blue Cross NC to improve healthcare solutions while managing risks linked to open-source software. It outlines the necessary groundwork, stakeholder engagement, and success factors, emphasizing education and communication to address misconceptions about open-source licensing. The focus is on creating processes to facilitate the adoption of open-source solutions and to ensure ongoing support and improvement within the organization.
Bootstrapping an Open-Source Program Office at Blue Cross NC
- 1. Bootstrapping an Open-Source Program Office Paul McLaughlin Blue Cross NC Manager of Solution Architecture
- 2. Where’s the sweet spot for Open Source? • More than you have now? Less? • Consume? • Mission critical areas? • Individual work areas? • Contribute? • Full-blown solutions? • Components? • Inner-Sourcing efforts?
- 3. We think we might be doing a good job • We’re lowering the underlying costs of health care • Value based health care • “We won’t stop until health care is better for all!” ® Marks of the Blue Cross and Blue Shield Association
- 4. We think we might be doing a good job ... ® Marks of the Blue Cross and Blue Shield Association
- 5. Institutionally risk-averse Individually risk-naïve Our environment is like this … Which means … Regulated industry Data breaches = Hell! System stability & customer perceptions We hate Hell. Tech-forward but it’s a mix. Enterprise-level OS need support contracts Missed opportunities? Lack of awareness about personal workstations Wait – You mean plug-ins count? Truly odd process obstacles Some good ideas DOA Mid-sized company / IT team almost 1000
- 6. OSPO would give us a nucleation point for driving improvements • Advise & educate • Remove roadblocks / add safeguards • Realign processes • Facilitate adoption of Open-Source solutions • Facilitate contributions to Open-Source solutions
- 7. Whose job is it to address this? And what background would you need? • Acquainted with OS basics • Ability to draw people in • Change management skills Architecture Security Software Asset Mgt Development/ Delivery Contracting
- 8. Wouldn’t it stink if we couldn’t get traction? Groundwork Phase • Initial research • Who formed the core and why • Charter / sponsor
- 9. Do you need sponsorship in your org? • Promote engagement by a wide variety of functions in the enterprise • We got a double sponsor: • Director of Enterprise Architecture • Director of Category Mgt* • with support from our CTO * Contracting and vendor mgt Functions we needed to involve • Architecture • Enterprise Security • Contracting / Legal • Software Asset Mgt • Development • Delivery Pipeline • Production Support
- 10. Gaps & opportunities: Pass #1 What • Quick! Provide baseline education • Realign processes and success criteria • License management • Enterprise Security risk assessment • Product support model • Automatic source code license/vulnerability How • Recurring meetings with shared meeting notes • Communicate, Communicate, Communicate!
- 11. How not to be in a teen horror movie Beware the Copyleft! Don’t feed it after midnight!
- 12. Who knew blind spots could matter? • Plug-ins • Source code packages • Free? Strings attached?
- 13. We needed to clear up some myths 1.Open-Source and Free Software are not the same thing. 2.If it’s free, it must be legal. (BTW, also applies to freeware/shareware) 3.If it’s from a reputable site, and I check the license, it’s probably safe. 4.If we have a license/contract with System X, we can use everything on their marketplace. 5.If I test it, I can incorporate OS into production solutions. 6.If I buy the license, I can use it on my company machine. CAN’T TELL YET TRUE MYTH MYTH MYTH MYTH
- 14. “Do be a savvy user … Don’t be careless” The initial education emphasized using OS solutions, just don’t be dumb • We have some processes. Please engage them and help us improve them! • Do check licenses. Get expert help. • Don’t use material that’s licensed to you personally on company systems. • Do your homework when incorporating an Open-Source solution in a production environment. • Do keep Open-Source solutions in mind. • Don’t freak out! • Do expect process improvements and streamlining soon.
- 15. Process realignment What • License management • “We’ll just send a purchase order to the vendor …” • Enterprise Security risk assessment • “We can’t assess the viability of the vendor …” • Product support model • “We’ll just toss it into production, and it’ll be fine …” • Automatic source code license/vulnerability • Delivery pipeline • Software Asset Management How • Champions for core areas • Listen – both ways • Incremental adjustments • Communicate!
- 16. Success factors • Culture that generally wants to collaborate … • … and that generally wants to provide more value to our customers. • Developed a shared understanding of what was at stake. • Group effort. More “we need your help” and less “let me tell you how to do it.” • Over-communicate.
- 17. Where next? • On-going education. • Set up recurring license and vulnerability reviews. • Figure out processes to monitor end-user environment. • Refine the way we assess risk for OS? • “The risk of not having this OS product is greater than the risk of having it …”
- 18. Discussion • Tell me: What did we miss? • What do you see that is most relevant for your shop? Key ideas • Gain buy-in. Charter. • Develop shared ownership. • Over-communicate to build trust and momentum. Paul G McLaughlin paulgmclaughlin Thank You!
- 19. Thank You! …
Editor's Notes
- #3: Let me get a quick sense of what your interests are here in the room. Increase your OS maturity in some way (hand) anyone need to pull back? Consuming OS? … Hands … Mission critical? … Individual? Contributing? … Full-blown solutions … Components … Inner-Sourcing I should clarify that our shop is up to consuming OS and not contributing to it at this time (ref Paula Paul). A friend of mine got all excited when he heard about this talk because he thought I’d be describing a project we were running. So: I’m going to cover how we got past some obstacles to consuming OS, but if you really had your heart set on contributing, then I won’t be offended if you decide you’d like to be elsewhere.
- #4: Before I describe any obstacles we’re handling, let me tell you we enjoy some great assets. We think we have a meaningful mission, and we’re making progress on it. BTW, if we ever start contributing to OS, it’ll be part of that battle cry, “We won’t stop until health care is better for all!”
- #5: We’ve worked hard at creating a collaborative environment. I’m surprised sometimes at how often people are surprised at how this really and truly plays out. Forrester 2022 EA Award. And a few months ago our architecture practice took home top honors for the Forrester’s 2022 EA Award, beating out several big national names. That was largely driven by how effectively we drive value that’s connected to our customers’ needs.
- #6: But for all that, we have our baggage, too. Stories: Missed project deadlines and unhappy customers …. Because we couldn’t figure out how to adopt an OS 64-bit middleware connector Dev’r plugins were a blind spot. Turns out 3 plugins needed to be replaced or updated for security vulnerabilities We had no reason to believe things would just accidentally improve.
- #7: So here I am thinking someone ought to tame this little problem. I was concerned that my own architecture colleagues were getting stumped as they tried to bring in some good solutions. (BTW, I came to realize that this was a valid obstacle in some cases, not just misplaced resistance.) I knew there was this thing called an OSPO that people used to drive this. Read the list briefly. Also, anything with “Program Office” in the name might be perceived as important until proven otherwise ;-)
- #8: But who could I talk into starting up an OSPO? Who even had the background let alone the needed time? And how much time would it take anyway? Can any single role really lead? In the end, I decided I was the logical person was in Architecture. In our case anyway. And you can guess that meant I needed to step up.
- #9: Step 1 - Research: What is an OSPO anyway? Step 2 – Gather accomplices. Shared vision informally with people I knew we’d need to succeed. Developed some initial problem statements and objectives. And then – Step 3 – we went looking for someone to sponsor us … (next slide)
- #10: In the end, we did indeed line up sponsorship. I don’t know what kind of organization you come from, but this gave us extra credibility instead of just relying on my own reputation. Transition: Where should we start?
- #11: Education = Address biggest exposure. (Credit to colleagues for bringing that into focus.)
- #12: In our case, the biggest risk was with IT professionals that had good intentions and also local admin rights on their laptops. We needed to dispel some myths and raise a healthy respect for ways you can get it wrong. These were a couple examples that hit close to home for us.
- #14: Open-Source and Free Software are not the same thing: TRUTH. Software isn’t OS unless it’s given an OS license. Likewise, OS Software might have strings attached. If it’s free, it must be legal: MYTH. Licenses might prohibit commercial use, and definitions of commercial use can vary. Licenses might also open us up to commitments we didn’t mean to make. If it’s from a reputable site, and I check the license, it’s probably safe: CAN’T TELL YET. You’re not done yet!! Be sure to follow through on review processes before adopting the software. Acknowledge that several folks have a business need to have local admin rights on their workstations, but that’s not a blank check to install things. Whether you need admin rights or not, do check the license terms and raise questions when needed. Also, pay attention to potential security no-nos like storing our data on 3rd-party servers. Very safe site: Example of Apache.org and their process. Apache Hadoop and Apache Kafka. Not a safe site: Sourceforge.net (blocked!) Troubling side story that Justin Stroda provided to us: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 If we have a license with System X, we can use everything on that system’s marketplace: MYTH. Actually, just because we have a license to System X doesn’t mean we have a license to everything you might find on its marketplace. As with anything else, check the terms, pricing, etc. THIS ALSO GOES FOR PLUG-INS AND EXTENSIONS! If I test it, I can incorporate OS into production solutions. MYTH. We also want to be sure about support going forward. What happens if something breaks? Who owns the internal support? Is the OS community likely to be responsive? If I buy the license, I can use it on my company machine. MYTH. Blue Cross needs to own the license. We can get into all kinds of trouble otherwise. Ex: There’s an integrated development environment called Intellij IDEA https://www.jetbrains.com/idea/. You might have a personal license for your personal machine that you own yourself, but that doesn’t mean you be doing us any favors installing it on the work machine without Blue Cross going through the proper controls. MYTH #7. The best thing to do is to avoid OS altogether: MYTH. Just because we told you some scary stories, don’t be afraid to take a walk at night. Many times, OS solutions provide great solutions that we can adopt (1) quickly, (2) with tolerable risk … as long as we do our homework. Myth 7a: Open source is less secure than proprietary software Myth 7b: Open source is harder to maintain Myth 7c: There is less support for Open-Source software Myth 7d: Open source is not enterprise-grade
- #15: Two main messages here Recognize the value of some safety net processes Don’t freak out
- #16: Probably the larger effort during our first pass. We had some weird obstacles to sort out. In general, people were willing. We just had to think of a way to accomplish the underlying needs. Purchase order: That one was just ignorance that could be educated. Viability assessment: Enterprise Security agreed their original yardstick would disqualify everything except stuff that came with a paid support agreement. That might be the right standard for mission critical solutions, but not necessarily on target for some less intensive cases. We worked out that you could look at the nature of the OS project owner and the community and accomplish the same goals. Product support model: That was one the architects needed to understand. They might know this was a winner, but there needed to be someone on call in case something burped along the way. How should that really work? Source code / Pipeline Subscription service that alerts us to weird license issues or vulnerabilities. Software Asset Mgt: Needed to account for more kinds of assets than they were used to. Remember, for example, that we had had a blind spot toward plug-ins.
- #17: Spare time – Gentle progress Collaboration Shared ownership Communication!!! Resistance: We know there was resistance to overcome, but I really haven’t emphasized that. Can you see how these approaches co-opted that resistance energy and turned it into contributors? ------------------------ Everyone on the OSPO was contributing “in their spare time,” more or less. Except for the initial education, we generally made progress at a stroll. We quickly got to where we could expedite something specific if the need ever arose. Here are some of the things we had going for us. Collaboration and commitment (comment) Shared ownership Communication! Seriously, keep it succinct but also frequent.
- #18: BTW, we don’t happen to have any OS projects in mind that I know of, but another next step might be an Inner-Sourcing practice. Maybe that’ll be Pass #3. ----------------------------- On-going education: We’ve realized recently people need a refresher. Hey, it’s been 2 years. Reviews: We can onboard something at this point, but we don’t have a good practice of revalidating it periodically. We need to know if they suddenly change their license or if a vulnerability pops up, for example. Monitoring: We have controlled environments on most laptops, but many folks have admin rights, and we still don’t know how to check for several gotchas. I’m hoping education at least helps people do right, but we’ll have good people who still break something. Risk assessments: Recent discussion. Wouldn’t it be interesting if we could consider extra candidates for mission-critical solutions?
- #19: Here’s my LinkedIn info in case you’d like to connect with me further on this. Meanwhile, tell me … What did we miss? (rev panel discussion) What do you see that is most relevant for your own shop?