Twitter github

Posts Tagged with “opensource”

Developer Advocate Wars / Arms Race

While I’m not a huge fan of an unique 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!

2018 Eclipse Simultaneous Release Name: Photon

Hey Eclipse friends, as part of my duties on the Eclipse Planning Council, we have worked with the Eclipse Foundation EMO and wider community to finalize the Oxygen+1 simultaneous release name (see bug 510201 for details): Photon

Thanks to everyone who voted in the community!

Open Container Initiative in 2017

Last year I had the opportunity to help build out/run the Open Container Initiative (OCI) and I wanted to take some time to reflect back on what the OCI community accomplished in 2016 and how far we’ve come in a short time since we were founded a little over a year ago.

The community has been busy! The project saw 3000+ commits from 128 different authors across 36 different organizations. With the addition of the Image Format specification project, we expanded our initial scope from just the runtime specification. Our membership grew to nearly 50 members and we also added new developer tools projects —runtime-tools and image-tools— which serve as repositories for conformance testing tools and have been instrumental in gearing up for the upcoming v1.0 release.

We’ve also recently created a new project within OCI called go-digest (which was donated and migrated from docker/go-digest). This provides a strong hash-identity implementation in Go and services as a common digest package to be used across the container ecosystem.

In terms of early adoption, we have seen Docker support the OCI technology in its container runtime (libcontainer) and contribute it to the OCI project (as runc). Additionally, Docker has committed to adopting OCI technology in its latest containerd announcement. The Cloud Foundry community has been an early consumer of OCI by embedding runc via Garden as the cornerstone of its container runtime technology. The Kubernetes project is incubating a new Container Runtime Interface (CRI) that adopts OCI components via implementations like CRI-O and rklet. The rkt community is adopting OCI technology already and is planning to leverage the reference OCI container runtime runc in 2017. The Apache Mesos community is currently building out support for the OCI image specification.

Speaking of the v1.0 release, we are getting close to launch! The milestone release of the OCI Runtime and Image Format Specifications version 1.0 will hopefully be available this first quarter of 2017 or shortly the following quarter, drawing the industry that much closer to standardization and true portability. To that end, we’ll be launching an official OCI Certification program once the v1.0 release is out. With OCI certification, folks can be confident that their OCI-certified solutions meet a high set of criteria that deliver agile, interoperable solutions.

We’ll be looking into the possibility of adding more projects in the coming year, and we hope to showcase even more demonstrations of the specs in action under different scenarios. We’ll be onsite at several industry events, so please be on the lookout and check out events page for details.

There is still much work to be done!  The success of our community depends on a wide array of contributions from all across the industry; the door is always open, so please come join us in shaping the future of container technology! In particular, if you’re interested in contributing to the technology, we recommend joining the OCI developer community which is open to everyone. If you’re building products on OCI technology, we recommend joining as a member and participating in the upcoming certification program.

Note: This was cross-posted to the OCI community blog.

Improved GitHub Code Review Tools

The default GitHub code review experience has always been lacking for me, especially when it comes to code review enforcement. I definitely admit to my bias of being a Gerrit code review fan but at least GitHub is moving in the right direction with recent code review improvements earlier this year.

On the bright side, GitHub has a fairly open API and there’s been a great ecosystem of tools that have popped up that help deal with some of the shortcomings in my opinion. Even more so after GitHub opened up the commit status API, it’s definitely enabled some interesting workflows.

PullApprove

One interesting code review workflow involves enforcing that changes must be reviewed by certain team members (which is a fairly common code review practice). In my opinion, the best tool that I’ve come across that handle this scenario is PullApprove. All you need is a simple metadata file that formalizes your requirements, and you’re good to go, here’s an example of what we use in the OCI project:

approve_by_comment: true
approve_regex: '^(Approved|lgtm|LGTM|:shipit:|:star:|:\+1:|:ship:)'
reject_regex: ^Rejected
reset_on_push: true
signed_off_by:
required: true
reviewers:
teams:
- image-spec-maintainers
name: default
required: 2

The important pieces here are the approve/reject regexes which dictate what terms will be used to approve and reject changes:

As a bonus, the “signed_off_by” setting can be used to enforce DCO which is to make sure your commits are properly signed off for DCO purposes.

LGTM

I also want to give an honorable mention to LGTM which is a simple pull request approval system that is open source but not as configurable as PullApprove IMHO.

Reviewable.io

For any large scale and high velocity projects on GitHub, managing what you need to review can be a daunting task. I’ve personally found Reviewable.io as an interesting tool that helps address the problem of managing the context of what you looked last and what’s on your queue.

Anyways, hope this helps and happy code reviewing! If you’re interested in more integrated GitHub code review tools, I highly recommend checking out the GitHub integration directory.