== intro slide Plugging into the Corporate Backplane Hacking Sponsorship for Open Source Projects Karsten Wade, Community Architect, @quaid Red Hat, Office of the CTO Open Source and Standards, @redhatopen == Intro Just to lay some ground here, I'll introduce myself. I'd like to leave some time for discussions, if that's what you want. Do you? Do any of you have experiences to share? Please stop me along the way for questions or comments. == slideset Agenda Let's talk about how you can create sustainably sponsorship for open source projects. My perspective is of someone from inside of an organization, working on projects, and recognizing the risk to the organization and projects when support & sponsorship are not given the same level of budget consideration as other essentials. You may be like me if you are within the org you want to hack sponsorship for. If you are on the outside, you need to find someone like me ... What you will be doing is has some similarities to surveying -- you will be working in land only pioneers and trackers have been through, going from waypoint to waypoint, documenting with witnesses at every step of the way. == slideset Overview Sustainable sponsorship of open source has many faces, but from an organizational perspective it is about choosing to spend resources and has several ways to consider it: * Humans working on things - for example, writing code, running events. Sustainability here means job roles are created and filled that have writing code and running events as part of the role. * Other operational costs - for example, paying for public cloud services to provide automated testing for an open source project, purchasing a sponsorship package for an open source event such as SCALE. Sustainability here means getting these as fixed items in budgets by creating understanding that it is closer to 'electricity' than 'sparkly water drinks' in the budget. * Physical things - servers in data centers, equipment for running events, etc. Sustainability here means getting hardware/equipment connected to teams with specified community/contribution roles, and get it into the lifecycle process for your org. In all of this be aware that the cyclical nature of your orgs budget process allows you to use the justification/requirements to review what you really need on a regular basis. Times will come when you replace technology, such as going from hardware in data centers (CapEx) to hardware in the cloud (OpEx) in support of a project. If you never reviewed, you might keep on doing the same thing without knowing if it's the current right thing. Part of your role in this is being like the gears on a bike, translating from the faster moving open source projects to the speed of your organization. Once you've built those gear-bridges, you need to make sure they stay in place. This might mean you personally maintain the bridge over the years. Even better is to turn "maintenace of the bridge" into a job duty or role that is always filled in your organization. == slide Examples & stories 1. Provide infrastructure for projects -- Community infra with IT 2. Go all-in one a project -- CentOS 3. Get things into job roles -- Software Engineer, Release Management, Package or Image Maintainer, etc. Ex: Community Architect 4. == slideset Model 1. Start with one aspect of supporting projects that you can put your hands around - what is the problem, how does supporting projects help? 2. Find people who care and/or are doing something about supporting the projects. Examples - Developers working on code - Generalists promoting events or releases, meetups, etc. - Someone writing how-to blog posts - A QE team maintaining a build service that could be in the community - A technologist running services and ops for the community on a few rented VMs (aka public cloud) People are already spending time and money to support projects, but it may a disconnected experience and feel to them like a drop in the bucket. But a few such drops might make a larger difference. All of these activities are at risk of disappearing in a reorg, because a key person leaves the team or company, etc. This group is your 'initial stakeholders'. This means they have a stake in the success or failure of your efforts. They are going to help you get some things done, they are going to help you find other stakeholders, they are going to be the champion of this idea within their group, and they are going to help find the linchpin situations to get the budget & job roles written into the budgets long-term. You are going to need to consult them, keep them informed, and (help) keep them organized as you proceed. 3. Pull together what is being done already by your stakeholders to create sustainability; find the top two or three blockers that might be resolved with a more solid relationship with the upstream community. These should be strategic to your org in some way(s). You need a stakeholder in the affected domain that could would benefit from the more solid relationship. Enlist the stakeholders' teams to pitch in for whatever is needed. The idiom here is "put some skin in the game". (This is truly the definition of stakeholder.) 4. Find some efficiencies in these 'few drops' so you can show cost savings, benefits to the projects & teams, demonstrate the model, create gravity, and generate more internal stories that people can see themselves in. Starting small and focused also helps with iterative success. The idiom here is, "Don't boil the ocean to make a cup of tea." 5. Find a rhythm for internal communication and marketing efforts. - Tell people about what you are doing, what you've done, what is coming next, what is the vision, how they can be involved. - As you have capacity, invite & accept more stakeholders. 6. Once you have stakeholders with resources they can commit (people, money), get them to document how this is done for their group. Take the time to understand how your organization does budgeting. and figure out how to use that process to ensure sustainability. The key is to get the budget allocation & job roles to be included in planning for the long term. A future direction change may reallocate the resources, and that process should be informed by the original research and decision to allocate. The anti-pattern here is that you convince people to make a change now but it is forgotten about the next cycle or otherwise treated as a one-off. "We sponsored that event, we've done our part for life" v. "It's that time of the year to sponsor our top-tiet events."