Twitter github

Posts Tagged with “opensource”

Ways your company can support and sustain open source

Note: this article was original posted on https://opensource.com/article/19/4/ways-support-sustain-open-source

To make sure open source continues to thrive, we all need to find ways to sustain the communities and projects we depend on

The success of open source continues to grow; surveys show that the majority of companiesuse some form of open source, 99% of enterprises see open source as important, and almost half of developers are contributing back. It’s important to note that companies aren’t contributing to open source for purely altruistic reasons. Recent research from Harvard shows that open source-contributing companies capture up to 100% more productive value from open source than companies that do not contribute back. Another research study concluded countries adopting modern open source practices saw:

“a 0.6%–5.4% yearly increase in companies that use OSS, a 9%–18% yearly increase in the number of IT-related startups, a 6.6%–14% yearly increase in the number of individuals employed in IT related jobs, and a 5%–16% yearly decrease in software-related patents. All of these outcomes help to increase productivity and competitiveness at the national level. In aggregate, these results show that changes in government technology policy that favor OSS can have a positive impact on both global social value and domestic national competitiveness.”

In the end, there are many ways for a company or organization to sustain open source. It could be as simple as training your organization to contribute to open source projects you depend on or hiring engineers to work on open source projects. Here are eight ways your organization can contribute back to open source, based on examples in the industry.

Hire open source maintainers to work on open source

Companies with strategies to leverage open source often find the highest returns from hiring a maintainer of the projects they depend the most on. It’s no surprise if you look at the Who Writes the Linux Kernel report that the top contributors are all employed by companies like ARM, Google, Facebook, Intel, Red Hat, Samsung, and more.

Having a maintainer (full time or part time) on your staff can help your organization learn how to work within the project community and enable prioritization of upstream contributions based on understanding of what the community is focused on. Hiring the maintainers also means that the project will have people with enough time to focus on the details and the rigor that’s needed for a project to be useful; think security reviews, bug cleanup, release management, and more. A more predictable and reliable upstream project can benefit many in your organization while also improving the overall project community. As a bonus, maintainers can also become advocates for your organization and help with recruiting too!

Develop an open source award program or peer bonus fund

It is common for companies to have internal employee recognition programs that recognize individuals who go above and beyond. As an example, Red Hat has a community award program through Opensource.com. Some other companies have expanded their recognition programs to include open source contributors. For example, Google has an open source peer bonus program that recognizes external people who have made exceptional contributions to open source.

Start an open source program office

Many internet-scale companies, including Amazon, Google, Facebook, Twitter and more, have established formal open source programs (colloquially called OSPOs) within their organizations to manage open source strategy along with the consumption and contribution of open source.

If you want to increase your contributions to open source, research has shown that companies with formal open source programs are more likely to contribute back. If you want to learn from organizations with formal open source programs, I recommend you read the TODO Group Open Source Program Guides.

Launch an open source fund

Some organizations contribute fiscally to the open source projects that are important to them. For example, Comcast’s Open Source Development Grants “are intended to fund new or continued development of open source software in areas of interest to Comcast or of benefit to the Internet and broadband industries.” This isn’t just for big companies; small companies have open source funds, too. For example, CarGurus launched an open source fund and Eventbot is supporting open source with a small percentage of its company revenue. Another interesting approach is what Indeed has done by democratizing the open source funding process with its employees.

Contribute a portion of your company equity to open source

Consider donating a portion of your organization’s equity to an open source project you depend on. For example, Citus Data recently donated one percent of its equity to the PostgreSQL community. This worked out nicely; Citus Data was acquired by Microsoft recently, so the PostgreSQL community will benefit from that acquisition, too.

Support and join open source foundations

There are many open source foundations that house open source projects your organization depends on, including the Apache FoundationEclipse FoundationCloud Native Computing Foundation (home of Kubernetes), GraphQL FoundationLet’s EncryptLinux FoundationOpen Source Initiative (OSI), OpenStack FoundationNodeJS Foundation, and more.

https://twitter.com/CloudNativeFdn/status/1092544807900110848

Fund and participate in open source internships or retreats

There are many open source internship programs that you can participate in and help fund. Google Summer of Code (GSoC) is the largest, and it requires mentorship from employees who work on open source projects as part of the program. Or you can sponsor internships for underrepresented minorities in open source through Outreachy and CommunityBridge.

Another approach is to host an open source retreat at your company. For example, Stripe hosts open source retreats to contribute to open source projects it depends on.

Include open source in your corporate philanthropy initiatives

If your organization has a corporate sustainability or philanthropic arm, consider working with that team to include open source as a part of its work. For example, Bloomberg has a software philanthropy budget for projects it depends on, from Git to Eclipse to Python and more. In the future, I hope to see more corporate sustainability and philanthropy efforts—like Pledge 1%—that focus on funding critical open source infrastructure.

Conclusion

In conclusion, giving back to open source is not only the right thing to do, according to research, it’s also good for your business. To make sure open source continues to thrive and is sustainable in the long run, we all need to ensure that companies find ways to sustain the open source communities they depend on.

Troubles with the Open Source Gig Economy and Sustainability Tip Jar

There has been a lot of discussions lately on open source sustainability and honestly, it’s something I think about on a daily basis through my current role at The Linux Foundation and myself being an open source contributor and maintainer for ~20 years.

Open Source Tip Jars

There has been a trend lately to have open source communities/projects open an electronic tip jar for individuals (or organizations) to give back. While a tip jar can raise some funds, it’s truly not sustainable long term, as outside of it not being an effective way to raise funds for project development, it puts maintainers unfortunately in a gig style economy without health and retirement benefits. There are only a handful of individual maintainers are making money from donations, most tend to abandon the approach over time.

Take Patreon as an example, a popular funding platform for all sorts of things including open source projects that has been around since 2013 and has paid out $1 billion to creators since then. While that’s an astonishing figure, Patreon isn’t a sustainable business with its current private company model and level of VC funding of $105M:

“Under the company’s current business model, 90 percent of funds are paid directly to content creators. Patreon takes 5 percent, and the remaining 5 percent covers transaction fees.” Patreon CEO Jack Conte said in an interview with CNBC, that the platform will soon be facing the challenge of maintaining a profitable model as the company continues its growth.

In 2019, the company is also on track to pay out $500 million to content creators, 5% of that is $25 million and Patreon has ~300 employees, so probably not even covering their labor costs. Also, when the creators don’t have much say in the governance of the organization they depend on, especially if it’s a privately funded company, the terms can change overnight.

“So today, Patreon is overhauling its pricing. Any creator can still get a 5 percent rate, but just for a Lite version without bonus tools or different fan tiers. All of Patreon’s extra features will now be in the Pro plan, with an 8 percent rate, but with existing creators grandfathered in at 5 percent. And the new Premium enterprise plan for 12 percent (9 percent for existing creators) will offer full-service merchandise sales, multi-user team accounts and dedicated customer support. Patreon now has 3 million fans paying 100,000 creators more than half a billion dollars per year, and it will cross $1 billion in payouts in 2019 after six years in business. But Patreon was starving on its 5 percent rate, which some venture capitalists tell me is why they passed on its funding rounds totaling $105 million led by Thrive Capital and Index. Now it might make enough to keep the lights on, retain ownership and maybe even earn a profit one day.”

I guess we will see if Patreon is truly sustainable in the long run for its community and investors, it currently isn’t working out so well for most creators (“No one makes a living on Patreon”).

As a note, this also applies to smaller open source mini-patreon style fundraising efforts such as BountySource, OpenCollective, GitCoin, Fundition, Librepay and more. For example, I strongly admire OpenCollective and their transparency for a private VC funded company (on a side note, I also admire companies like Buffer who go further with transparency dashboards), from their level of funding as a startup to more. However, they are facing similar sustainability problems on a smaller scale if you look at the financials over time (their burn rate allows for 6-12 months depending on their growth), also maintainers don’t own any equity in the company. If this was a normal VC company the investors would cut their losses in my opinion.

It’s also interesting to see some nonprofit options out there like Liberapay founded in 2015 in France that is running on a break-even basis for all that I can tell. I think part of the sustainable solution for funding platforms is to build one in a way where it lives in a neutral place where creators have a say in governance and ownership. Outside of supporting projects forming their own companies, I’m interested in innovative startups like Tidelift which are experimenting with new approaches to make it easier for open source maintainers to get paid for their work by essentially by offering a subscription product and acting as a guarantor of sorts.

Note: I don’t think any of the blockchain coins will solve this problem or any problem for that matter.

Open Source Gig Economy

My biggest issue with these fundraising platforms is that even if we ever get to a point where some developers are making money, who pays for their health and retirement benefits (I know this is dependent on country but in many countries employers assist with retirement benefits). There has been a ton of press and research as of late on the gig economy, usually featuring Uber/Lyft in the news:

In the US and many countries, there are different protections for “employees” versus “independent contractors” and leads to a lot of situations where you lose protections depending on how you’re classified.

We can do better than having developers run in a hamster wheel of no benefits and protections offered via normal employment schemes. It’s not sustainable and not fair to developers.

Conclusion and Corporate Open Source Sustainability

I don’t think there is one solution for open source sustainability but I do strongly feel that VC-funded donation platforms that fuel the gig economy are not the best solutions for long term sustainability (even Patreon had to expand its business model outside just donations). There’s a part of me that feels some of this donation discussion echoes the past discussion of micropayments and publishers. This presentation from GitLab about how their business model evolved over time from the early days donations to consultancy to open core product business does a great job of showing the pitfalls of a variety of common approaches:

Also, we should revisit the premise that open source isn’t sustainable to begin with, I think many folks in the community are selling short the progress that has been made over time in supporting open source. I’d like to make the argument that we are better off today than we were in the past. In fact, some research shows that “about 50% of all open source software development has been paid work for many years now and that many small projects are fully paid for by companies.” The reality is that there are still projects that fall through the cracks like OpenSSL that were aided eventually by the Core Infrastructure Initiative, so as long as we can discover and catch those we will be in good shape.

We should remember that a big part of innovation comes from developers working at organizations adopting open source software at scale and using it in interesting ways. It’s these organizations that should be tasked to sustain open source software versus individuals, especially since they depend on open source software to survive as a business. I also think it’s high time that corporate sustainability and social responsibility initiatives include open source contribution as part of them. I’ve seen some initiatives recently that I admire from organizations:

I truly hope to continue to see the trend of companies giving back to open source through contribution (fiscally or code) as I believe it’s key to open source sustainability and one of the reasons I co-founded the TODO Group and collaborate today with an excellent set of peers teaching organizations about the benefits of open source programs and why contributing back is good for business.

In the end, there are many ways to fund and sustain open source projects, from starting companies that sell open source based products and deliver value for customers, to working at organizations and having them dedicate time to contribute to open source and many more. I highly recommend visiting the oss.fund sheet to see what funding options are out there (also look at oss.cash to see large businesses built around open source technology). On a related note, I’m personally excited about the Community Bridge platform from the Linux Foundation which I was personally involved with:

CommunityBridge will automate some of the activities the Linux Foundation performs as an organization to benefit open source sustainability, from basic funding, expense reimbursement, mentorships and to paid internships that may lead to full time jobs with benefits.

Anyways, thanks for reading and I hope you learned something new about open source and understand why I think the charity/donation approach won’t work well for long term open source sustainability.

Red Hat and IBM: Elephants Can Dance

What an M&A surprise in the tech world yesterday with IBM picking up Red Hat, the jokes on Twitter were of course on point:

To expand on Alexis Richardson’s funny joke above, the clouds wars are no joke amongst the hyper scale clouds of the world and the war continues to escalate. Microsoft recently closed its deal with GitHub at $7.5B to only have IBM buy Red Hat for $34B. I can’t wait to see what Google, Oracle and the other large cloud providers pick up in the coming months.

I’ve had the privilege to work at both IBM and Red Hat earlier in my career so I’m familiar with the culture of both companies; it’s going to be interesting to see how the acquisition plays out over time. IBM is a gigantic company known for its bureaucracy that has been around for over 100 years and has successfully reinvented itself multiple times to survive (see the Who Says Elephants Can’t Dance book by IBM former CEO Lou Gerstner for a case study on this). Red Hat is an early open source pioneer with a fantastic and unique engineering culture that has been supporting remote work before it was cool and pioneered the concept of an “open source conflict of interest” clause (which will be interesting to see if IBM adopts):

“Participation in an open source community project, whether maintained by the Company or by another commercial or non-commercial entity or organization, does not constitute a conflict of interest even where you may make a determination in the interest of the project that is adverse to the Company’s interests”

There has been some FUD going around that IBM doesn’t fund open source or participate much in open source:

This FUD is absolutely crazy and needs to stop, IBM has arguably done more for open source than any other company to get where we are today with open source being prevalent in almost every industry and vertical:

IBM spent $1B on Linux before open source (and even Linux was cool)? Hell, I spent my early career working on open source at IBM where they had one of the first Open Source Program Offices (OSPOs) and spent my time hacking on Eclipse full time, which was another open source project that IBM helped start that disrupted the whole commercial tooling industrial complex. You can read more about IBM’s commitment to open source here which I think provides a great timeline of the various open source projects they have been involved in before open source was cool.

Anyways, to my Red Hat colleagues, my advice would be to give this a chance for awhile as IBM has a lot of strengths that Red Hat could take advantage of, they are truly a global company and have a solid sales channel that is embedded all over the world.

To my IBM colleagues, don’t “bluewash” this company and almost treat this as a reverse merger, embrace the culture from Red Hat and you should honestly consider making Jim Whitehurst CEO of IBM and Chris Wright CTO of IBM. As Lou Gerstner said, “culture isn’t just one aspect of the game, it is the game” and this is one area that Red Hat can greatly help IBM as it navigates towards the cloud.

Here are also a couple other good takes on the acquisition I enjoyed:

Finally, I’m really looking forward to see what IBM and Red Hat together, they have both been kindred spirits in making bets early on open source and I hope they bring that same zeal to the cloud. It at least makes my job running the Cloud Native Computing Foundation (CNCF) more entertaining 🙂

Developer Advocate Wars / Arms Race

While I’m not a huge fan of arms races, I have a unique perspective amongst open source foundations by having involvement from all the major cloud providers so I have an interesting vantage point in seeing a trend amongst them in ramping up developer advocacy hiring over the last couple of years. Furthermore, this hiring blitz is even more evident for me given the last couple of weeks have been conference crazy in the cloud native space with CloudNativeCon/KubeCon, MSBuild, Google IO and Red Hat Summit happening.

So what is happening with developer advocacy and the hyperscale cloud providers?

Note: If you aren’t familiar with the term developer advocate, I highly recommend this presentation by Patrick Chanzenon and blog from Ashley McNamara as an introduction to the profession.

Google

Google historically has been one of the early proponents of developer advocacy/relations and has invested in it since 2006 (see this excellent presentation for a historical perspective). A cursory search on LinkedIn shows a few hundred developer advocates employed at Google covering a variety of technologies from browsers to cloud. They also recently hired some heavy hitters like Sam Ramji and even Adam Seligman of Salesforce fame to help further build out their developer relations organization which was a smart move:

Anyways, I consider Google a leader in developer relations and with folks like Kelsey Hightower on staff, they are ahead of the curve.

I expect them to continue hiring like crazy to onboard more people onto their cloud offerings given their position in the market.

Microsoft

I used to work with Jeff Sandquist at Twitter and was delighted to hear he went back to Microsoft to build a developer advocacy focused organization. MS isn’t new at this game as some of us who are old enough and did MFC programming back in the day may remember Microsoft and their Channel9 advocacy program. Microsoft has been investing heavily in developer relations by making key hires (e.g., Ashley McNamara, Bridget Kromhout) and have rebooted their investment in open source to become one of the largest open source contributors in the industry. I’m not the first person to notice this trend by far, my friends at RedMonk noticed last year also. Searching the Microsoft job site, I see them hiring a handful of developer advocates mostly focused on cloud but they already have a large established roster of folks. It’s hard to get an exact count through the inexact science of flipping through LinkedIn search results, but I’d peg it 50-100 people currently employed doing developer relations.

Amazon (AWS)

In late 2016, Amazon started to expand their open source credibility by hiring folks like Adrian Cockroft, Zaheda Borat and Arun Gupta.

Using ancedata from my own experience being at events the last few years, Amazon has been aggressively speaking at conferences popular in the open source community. They have started to open source more examples and work with the community to improve them (e.g., https://github.com/aws-samples/aws-workshop-for-kubernetes)

It’s hard to get an exact number of people employed doing developer relations at AWS but going through the inexact science of LinkedIn search results, it looks to be in the 25-50 range which seems lower than I expected, but it’s hard as developer advocate is a fluid title (some people call themselves evangelists). In terms of hiring, searching the AWS jobs site I came across a couple of handful of developer advocate focused jobs so they seem to be aggressively hiring in this space. Also on a related note, I’m forever a fan of AWS for their execution and open discussion about hiring older engineers.

IBM

IBM traditionally has a strong position with their interactions with the open source community and even built a formal open source program within the company (I was also a fan of their DeveloperWorks initiative and even wrote technical articles for them in the past). They have also showed how making early bets on open source initiatives like Linux and Eclipse can reshape markets. In terms of developer advocacy, it seems about a year ago hired Jonas Jacobi to focus on developer relations from what I’ve been able to ascertain. They recently hosted an open source developer event in San Francisco called IBM Index which signals a desire to build developer communities outside the traditional IBM enterprise events like Think.

From a cursory LinkedIn search, IBM has 100+ developer advocates working on things from AI to Cloud. In terms of hiring, I’ve only found a handful of job descriptions currently open that are focused on developer advocacy. However, there were many job descriptions that were labeled software engineering that seemed to heavily focus on developer advocacy, for example, the folks that work on something called the IBM Cloud Garage seem to be a developer relations style job.

Oracle

Oracle has a burgeoning cloud business and according to some news sources, Oracle is actively trying to hire a new executive to run developer relations. A cursory job search shows that Oracle is ramping up their hiring, I see dozens of developer advocate positions open along with some more senior director level positions. I continue to expect Oracle to invest heavily in developer relations as this is an area they aren’t known for but has become table stakes in the public cloud business in my opinion.

Alibaba (and BAT+)

Alibaba and their cloud business is growing fast worldwide even though we don’t hear much about them in North America. In my opinion, they are making smart moves in Southeast Asia, India and other markets but that’s for another article to discuss. In my quest to learn about developer advocacy at Alibaba and even the other BAT companies, it was hard pressed to find any folks individually working on this. It’s clear to me that Alibaba has developer relations folks as if you go to their Alibaba Developers site there is some great content there but it’s been difficult to find current folks employed in devrel there and what they are hiring for. I’ll chalk this up to my inability to understand how job searching works in China and maybe one of my readers can shed some light on this. My hunch is that Alibaba will aggressively start hiring developer relations people worldwide if they didn’t start already, it will be fun to watch.

Conclusion

So what did I learn while I wrote this article? Well first off, getting hard numbers of how many job openings out there is a terrible science, sites like LinkedIn, Glassdoor and Indeed make it very difficult to extract data from their platforms to analyze. Second, developer relations is a nascent field and there’s no standard job description or career ladder. In many companies you have titles that range from “developer advocate” to “developer evangelist” to even “software engineer” that have primary responsibilities as developer relations. There have even been boutique communities popup to support people in the role of developer relations, see the Evangelist Collective slack as an example. Also the hiring of developer advocates isn’t just for large cloud providers or companies… you see some of the smart modern startups like Hashicorp, Turbine Labs and others hiring folks exclusively to make it easier to onboard developers to their tooling.

Finally, my prediction is that we will see cutthroat competition amongst the hyperscale cloud providers in hiring developer relations talent, especially out of the incumbents. The rest of the industry will learn from this experience that having a strong developer relations team is table stakes for any developer focused business. I’d love to write more on this topic but I’m short on time and I’m sure my friends at Redmonk can do a better job on this topic than me 🙂

CNCF Annual Report for 2017 and Kubernetes Graduation

We recently published the first annual report for the Cloud Native Computing Foundation (CNCF) which encompassed our community’s work in 2017:

The CNCF is technically a little over two years old and it was about time we start publishing annual reports based on our progress. This is a well treaded path by other open source foundations out there like the Eclipse Foundation and Mozilla so we thank them for inspiration to be more transparent.

Another thing that we launched this week was the Cloud Native Landscape (interactive edition) and more importantly, the Cloud Native Trailmap which guides you through the journey of becoming cloud native by adopting different projects in the foundation.

Finally, it was fantastic for Kubernetes to be the first project to graduate from the CNCF.  What does this exactly mean? This is very akin to graduation in other open source foundations such as the ASF. Graduation here is really about confidence in CNCF development processes and really a stamp from the CNCF Technical Oversight Committee (TOC) on what is a sustainable, production ready and mature open source project  you can bet your business on. As projects mature in the CNCF in terms of following solid open source governance processes and become widely adopted, expect to see more projects graduating in the future.

Cloud Native and Serverless Landscape

For the last year or so, the CNCF has been exploring the intersection of cloud native and serverless through the CNCF Serverless WG:

As the first artifacts of the working group, we are happy to announce a whitepaper and landscape to bring some clarity to this early and evolving technology space. The CNCF Serverless WG is also working on a draft specification for describing event data in a common way to ease event declaration and delivery, focused on the serverless space. The goal is to eventually present this project to the CNCF TOC to formalize it as an official CNCF project:

We’re still early days, but in my opinion, serverless is one application/programming built on cloud native technology. There are some open source efforts out there for serverless but they tend to be focused on specific projects (e.g., OpenFaaS, kubeless) versus collaboration across cloud providers and startups. The CNCF is looking to enable collaboration/projects in this space that adhere to our values. What are our values? See these from our charter:

  • Fast is better than slow. The foundation enables projects to progress at high velocity to support aggressive adoption by users.
  • Open. The foundation is open and accessible, and operates independently of specific partisan interests. The foundation accepts all contributors based on the merit of their contributions, and the foundation’s technology must be available to all according to open source values. The technical community and its decisions shall be transparent.
  • Fair. The foundation will avoid undue influence, bad behavior or “pay-to-play” decision-making.
  • Strong technical identity. The foundation will achieve and maintain a high degree of its own technical identify that is shared across the projects.
  • Clear boundaries. The foundation shall establish clear goals, and in some cases, what the non-goals of the foundation are to allow projects to effectively co-exist, and to help the ecosystem understand where to focus for new innovation.
  • Scalable. Ability to support all scales of deployment, from small developer centric environments to the scale of enterprises and service providers. This implies that in some deployments some optional components may not be deployed, but the overall design and architecture should still be applicable.
  • Platform agnostic. The specifications developed will not be platform specific such that they can be implemented on a variety of architectures and operating systems.

Anyways, if you’re interested in this space, I highly recommend you attend the CNCF Serverless WG meetings which are public and currently happen on a weekly basis.

Starting an open source program office?

To make good on my new years resolutions of writing more, I recently wrote an article for opensource.com on starting an open source program for your company:

Please check it out and let me know if you have any comments. I’d really like to see us build a future where more companies have formal open source programs, that’s a key path towards making open source sustainable for everyone.

Winding Down an Open Source Project

For 2018, I’ve made a commitment to myself to simply WRITE AND SHARE more. I used to be really good at cranking out posts but I’ve been so heads down in running and building out open source foundations that I’ve neglected sharing what I’ve learned over the years. I recently wrote a post about the process of starting an open source program for your company:

Also yesterday we posted a new open source program guide in the TODO Group about what to do when you unfortunately wind down an open source project:

While some open source foundations have well defined project lifecycles with notions of an “attic” or “archive” – many companies who open source projects generally do not.

Anyways, I hope these articles are useful to you and you learn something new 🙂

Launching TODO Group Guides

In my participation with the TODO Group, we recently published a set of open source guides (under CC-BY-SA 4.0) dedicated to help companies build out open source programs:

In the last year or so, we have seen companies like AWS build out an open source program via @AWSOpen and even companies like VMWare hired their first Chief Open Source Officer.

We’ve had many organizations approach TODO Group members asking for advice on how to get started with an open source program and these guides are a reaction to that. It is our hope that these are living guides and evolve with community input over time.

Become a Founding Kubernetes Certified Service Provider

In early September, CNCF will be announcing the founding class of Kubernetes Certified Service Providers (KCSPs). If your company provides professional services to support Kubernetes deployments, please consider signing up to become part of the founding class.

The main benefits of becoming a KCSP are:

  • Placement in a new section at the top of https://kubernetes.io/partners/
  • Monthly meetings with cloud native project leaders, TOC members,
    and representatives from the CNCF Governing Board
  • Access to leads from end users looking for support

Requirements are:

  • Three or more engineers who pass the Certified Kubernetes Administrator (CKA) exam
  • Demonstrable activity in the Kubernetes community including active contribution
  • A business model to support enterprise end users, including putting engineers at a customer site

The CKA exam is about to enter early release beta testing prior to the public release in September. It is an online, proctored, performance-based test that requires solving multiple issues from a command line. It takes 3 to 4 hours to complete, and costs $300, though a discount is available for beta testers to $100.

If your company is interested in becoming a KCSP, please do the following 4 things:

  1. Ensure that your company is listed at https://kubernetes.io/partners/
    and if not (or if the listing should be updated), please do so via the link
    at the top of that page.
  2. Have 3 or more of your Kubernetes experts sign up for the beta test at:
    https://docs.google.com/forms/d/e/1FAIpQLSd9-6nL5L3SzWIddCSPoKeuX_Pdq_KHI8C4mQzcUryP-gu0dQ/viewform
    .Please have them use their company email so we can properly associate
    them. Within a week, we will send beta test dates, a discount coupon code, and instructions to register and schedule.
  3. Register your interest in becoming a KCSP at this form: https://docs.google.com/forms/d/e/1FAIpQLSfai-zlNuvP-q0fz3jw89v3v4m_wYaF7tOBmNY0WoKsZgeQUQ/viewform
  4. If you are not already on it, and want to track progress of the certification program over time, please subscribe to the Kubernetes Certification Working Group list: https://lists.cncf.io/mailman/listinfo/cncf-kubernetescertwg.

Questions or issues? Please email cncf-kcsp-support at lists.cncf.io

Thanks!