Tag Archives: community

Three opportunities to connect with Google Open Source in June

One of our biggest challenges this year has been finding opportunities to stay connected with the many open source communities that we collaborate with across projects. As we continue to develop new ways of creating convenings with our different stakeholders, here are three opportunities to connect with Google Open Source later this month.

24 hours of Google Cloud Talks by DevRel

When: June 23, 2020
What: This is a free, digital series, organized by Google Developer Relations team, offering practitioners an opportunity to connect with our technical experts and deepen their awareness and knowledge of a variety of Google Cloud solutions including ML/AI, Serverless, DevOps, and many more.

Talks by Google Open Source:

June 23

OpenJS World

When: June 23-24, 2020
What: Organized by The Linux Foundation, and sponsored by Google, this annual event brings together the JavaScript and web ecosystem including Node.js, Electron, AMP and more. In 2020, we’re going virtual to learn and engage with leaders deploying innovative applications at massive scale.

Talks by Google Open Source:

June 23
June 24

Open Source Summit North America

When: June 29 – July 2, 2020
What: Organized by The Linux Foundation, and sponsored by Google, this event connects the open source ecosystem under one roof, summoning over 2,000 participants across 15 conference rooms. It’s a unique environment for cross-collaboration between developers, sysadmins, devops, architects, program and product managers and others who are driving technology forward.

Talks by Google Open Source:

June 29
June 30
If you attend any of these talks, and plan to share, you can tag @GoogleOSS on Twitter. We hope to see and connect with many of you at these virtual events!

By María Cruz, Google Open Source

Knative elects new Technical Oversight Committee members

Towards the end of 2019, Knative project initiated a series of changes to its governance to ensure sustainability in the long term. Over the last week, the project reached a new milestone by successfully wrapping up its first Technical Oversight Committee (TOC) elections, bringing more vendor diversity to the technical stewardship of Knative.

Google has grown thousands of open source projects throughout the years, and it is this collective knowledge that informed the changes proposed to Knative governance. Over the last six months, we worked together with the other members of the Knative Steering Committee, and with the project’s contributors to create a clear set of rules for technical leadership and governance, describing the many ways in which contributors could engage with the project. This process was key to developing trust with Knative’s community, the project’s most valued stakeholder. In the exercise of this vote, the community was able to test the new election process, which proved to be solid: it will be repeated annually for this project, and can serve as a model for other projects as well.

The TOC election, which had a turnout of 70% of active contributors to the project, yielded a new technical stewardship for Knative, with members representing RedHat, VMWare and Google, as follows:

Nghia Tran (Google) - new member
Markus Thömmes (Red Hat) - new member
Grant Rodgers (Google) - new member
Matt Moore (VMWare) - existing member
Evan Anderson (VMWare) - existing member

Members of Knative TOC not only have the technical stewardship of the project in their hands for the next two years, they also model the community’s values: they have strong technical skills, they contribute to the project, and they are collegial, mentoring other contributors and helping the project to grow in a sustainable and healthy way.

We celebrated this important milestone for Knative at the last community meetup. Watch the video to meet the new TOC members, and check out the contribution guidelines to join the project.

By María Cruz, Google Open Source

Apache Beam presents its mascot to the world

Four years after it graduated from The Apache Software Foundation’s incubator, Apache Beam welcomes a new addition to the family: its mascot, the Beam firefly! Apache Beam is an open source data streaming programming model that runs on the back end of some of your favorite apps. It is the technology behind many popular apps that need to process big data in real time. And the reason it has come this far is the community of developers that contribute to this open source project every week. In the last few months, we worked with Apache Beam contributors to collaboratively design a mascot for the project—a creative asset that can represent the values of the project and attract new users and contributors—to keep growing the project and expanding its reach.

In these four years, the Apache Beam project has been a busy… firefly. According to the Apache Software Foundation’s 2019 Annual Report, Beam ranks fourth in the top five most active projects by commits, and it ranks first in the top five most active [email protected] mailing list, showing a strong and transparent communication exchange within the community of developers. On top of that, 53 Meetup groups across the globe are directly or indirectly connected to sharing knowledge about Apache Beam use cases, applications and functionalities.

With this much momentum and enthusiasm for this project, it was a good opportunity to cement some of Apache Beam’s most valued characteristics, to help raise awareness of this rapidly growing project, and convert more users to contributors. “Projects with a mascot are more relatable. They signal that there is more to the project than its technical vision. It signals that there is more to the project than its code,” said project contributor Maximilian Michel. In November of last year, the community discussed adopting a mascot and as a result, 11 animal ideas emerged for a possible mascot: beaver, hedgehog, lemur, owl, salmon, trout, robot dinosaur, firefly, cuttlefish, dumbo octopus, and angler fish. After 48 contributors expressed their vote, the collective decision was a firefly. In January of this year, artist Julián Bruno set out to bring the mascot to life. There were four rounds of feedback on different iterations of the mascot, plus a final vote, where 18 people participated; Engagement increased with every new round. In the end, this process produced an original mascot, a model sheet (so that anyone may reproduce it), and two adaptations of the Beam firefly: one where it is learning, and one where it is doing what it does best… stream data! You can read more about this process on the Apache Software Foundation’s blog.

In a year that has presented a lot of challenges to bring people together, working on the mascot project with the Apache Beam community was refreshing, and felt like a medium for contributors to connect beyond code and technical questions. It is our wish that Apache Beam continues to grow as a project, and we hope to continue to support its community to: support newcomers, share what works, and collaborate with others to build great solutions.

By María Cruz, Google Open Source

Become a Developer Student Club Lead

Posted by Erica Hanson, Global Program Lead, Developer Student Clubs

Calling all student developers: If you’re someone who wants to lead, is passionate about technology, loves problem-solving, and is driven to give back to your community, then Developer Student Clubs has a home for you. Interest forms for the upcoming 2020-2021 academic year are now available. Ready to dive in? Get started at goo.gle/dsc-leads.

Want to know more? Check out these details below.

Image description: People holding up Developer Students Club sign

What are Developer Student Clubs?

Developer Student Clubs (DSC) are university based community groups for students interested in Google developer technologies. With programs that meet in person and online, students from all undergraduate and graduate programs with an interest in growing as a developer are welcome. By joining a DSC, students grow their knowledge in a peer-to-peer learning environment and build solutions for local businesses and their community.

Why should I join?

- Grow your skills as a developer with training content from Google.

- Think of your own project, then lead a team of your peers to scale it.

- Build prototypes and solutions for local problems.

- Participate in a global developer competition.

- Receive access to select Google events and conferences.

- Gain valuable experience

Is there a Developer Student Club near me?

Developer Student Clubs are now in 68+ countries with 860+ groups. Find a club near you or learn how to start your own, here.

When do I need to submit the interest form?

You may express interest through the form until May 15th, 11:59pm PST. Get started here.

Make sure to learn more about our program criteria.

Our DSC Leads are working on meaningful projects around the world. Watch this video of how one lead worked to protect her community from dangerous floods in Indonesia. Similarly, read this story of how another lead helped modernize healthcare in Uganda.

We’re looking forward to welcoming a new group of leads to Developer Student Clubs. Have a friend who you think is a good fit? Pass this article along. Wishing all developer students the best on the path towards building great products and community.

Submit interest form here.



*Developer Student Clubs are student-led independent organizations, and their presence does not indicate a relationship between Google and the students' universities.

DevFest 2019: It’s time for Latin America!

DevFest banner Posted by Mariela Altamirano, Community Manager for Latin America with Grant Timmerman, Developer Programs Engineer and Mete Atamel, Developer Advocate

DevFest season is always full of lively surprises with enchanting adventures right around the corner. Sometimes these adventures are big: attending a DevFest in the Caribbean, in the heart of the amazon jungle, or traveling more than 3,000 meters above sea level to discover the beautiful South American highlands. Other times they are small but precious: unlocking a new way of thinking that completely shifts how you code.

October marks the beginning of our DevFest 2019 season in Latin America, where all of these experiences become a reality thanks to the efforts of our communities.

What makes DevFests in LATAM different? Our community is free spirited, eager to explore the natural landscapes we call home, proud of our deep cultural diversity, and energized by our big cities. At the same time, we are connected to the tranquil spirit of our small towns. This year, we hope to reflect this way of life through our 55 official Latin America DevFests.

During the season, Latin America will open its doors to Google Developer Experts, Women Techmakers, Googlers, and other renowned speakers, to exchange ideas on Google products such as Android, TensorFlow, Flutter, Google Cloud Platform. Activities include, hackathons, codelabs and training sessions. This season, we will be joined by Googlers Grant Timmerman and Mete Atamel.

Grant is a Developer Programs Engineer at Google where he works on Cloud Functions, Cloud Run, and other serverless technologies on Google Cloud Platform. He loves open source, Node, and plays the alto saxophone in his spare time. During his time in Latin America, he'll be discussing all things serverless at DevFests and Cloud Summits in Chile, Argentina, Peru, Colombia, and Mexico.

Grant Timmerman, developer programs engineer
Mete Atamel, developer advocate

Mete is a Developer Advocate based in London. He focuses on helping developers with Google Cloud. At DevFest Sul in Floripa and other conferences and meetups throughout Brazil in October, he’ll be talking about serverless containers using Knative and Cloud Run. He first visited the region back in 2017 when he visited Sao Paulo

Afterwards, he went to Rio de Janeiro and immediately fell in love with the city, its friendly people and its positive vibe. Since then, he spoke at a number of conferences and meetups in Mexico, Colombia, Peru, Argentina, Uruguay and Brazil, and always has been impressed with the eagerness of people to learn more.

This year we will be visiting new countries such as Jamaica, Haiti, Guyana, Honduras, Venezuela and Ecuador that have created their first GDG (Google Developer Group) communities. Most of these new communities are celebrating their first DevFest! We'll also be hosting diversity and inclusion events, so keep an eye out for more details!

We thank everyone for being a part of DevFest and our community.

We hope you join us!

#DevFest

#DevFestLATAM

Find a DevFest near you at g.co/dev/fest/sa

Building great open source documentation

When developers use, choose, and contribute to open source software, effective documentation can make all the difference between a positive experience or a negative experience.

In fact, a 2017 GitHub survey that “Incomplete or Confusing Documentation” is the top complaint about open source software, TechRepublic writes “Ask a developer what her primary gripes with open source are, and documentation gets top billing, and by a wide margin.”

Technical writers across Google are addressing this issue, starting with open source projects in Google Cloud. We'll be sharing what we learn along the way and are excited to offer this brief guide as a starting point.

Open source software documentation

Providing effective documentation for open source software can build strong, inclusive communities and increase the usage of your product. The same factors that encourage collaborative development in open source projects can have the same positive results with documentation. Open source software provides unique ways to create effective documentation.

When software is open sourced, users are regarded as contributors and can access the source code and the documentation. They’re encouraged to submit additions, fix code, report bugs, and update documentation. Having more contributors can increase the rate at which software and documentation evolve.


The best way to accelerate software adoption is to describe its benefits and demonstrate how to use it. The benefits of timely, effective, and accurate content are numerous. Because documentation can save enough time and money to pay for itself, it:
  • Helps to create inclusive communities
  • Makes for a better software product
  • Promotes product adoption 
  • Reduces cost of ownership
  • Reduces the user’s learning curve
  • Makes for happy users
  • Improves the user interface
When documentation is inadequate, the opposite can occur. Incorrect, old, or missing documentation can:
  • Waste time
  • Cause errors and destroy data
  • Turn away customers
  • Increase support costs
  • Shorten a product’s life span

Why supplying effective documentation can be such a challenge

Useful documentation takes time to write and must be updated with the software. Did the installation process change? Are there better ways to configure performance? Was the user interface modified? Were new features introduced? Updates like these must be explained to new and existing customers.

It’s not enough to add words to a file and call it documentation.

How many times have you tried to use documentation that was five years out-of-date? How long did it take you to find another solution? (Not long, right?) Using old documentation can be like hiking an overgrown trail. The prospects of rogue branches, poison ivy, and getting lost suggest you are unlikely to emerge unscathed.

At first blush, writing documentation may seem optional. However, as a developer, you can literally be so close to your product that you take its features and purpose for granted. But your customers have no idea what you know, or how to apply what you know to address their business challenges. And time is money.

Remember the swimmer who got halfway across the English Channel only to say, “I’m tired,” before turning around and swimming back to shore? Ignoring the need for documentation is like that. Developing a software product gets you some of the way to your goal whereas helpful documentation fulfills your goal.

Momentum matters a lot. If you can settle into a rhythm of implementing new features, fixing bugs in the code, as well as writing and updating documentation, you can propel yourself to success.

Create an inclusive open source community

In the same GitHub survey referenced above, 95% of the respondents were men but evidence suggests that clear documentation:
  • Can contribute to inclusive communities
  • Is more highly valued by those groups who are typically under-represented
Documentation that effectively explains a project's processes, such as contributing to guides and defining codes of conduct, is valued more by groups that are underrepresented in the open source community, such as women.

Factors that can lead to ineffective documentation

Conditions like these almost always compromise the quality of documentation:
  • Belief that it’s enough for open source software to just work.
  • Notion that a specification is as good as instructional text.
  • Idea that casual unreviewed contributions are sufficient.
  • Belief that unscheduled and unspecified software updates are acceptable.
  • Minimal to no style guidelines.

Conquer your documentation challenges

Use these best practices to provide helpful and timely documentation:

1. Identify common terminology

Define and influence the usage and adoption of terminology for your open source project. Use the same terminology in the guides and in the product. Involving a writer early in product development can lead to a natural synergy between the user interface, guides, and training materials.

With clear definitions of terms and consistent usage in the documentation, you can teach your community to speak a common language. As a result, everyone in your products’ ecosystem can communicate more effectively with each other.

2. Provide contribution guidelines

Opensource.com describes exactly why contribution guidelines are so important. Consider how Kubernetes describes the types of documentation contributions your users can make and how to make them.

3. Create a documentation template

To make sure your contributors provide details in a consistent format, consider providing a document template to capture details for common topics such as:
  • Overview
  • Prerequisites
  • Procedural steps
  • What’s next

4. Document new and updated features

When a feature is added or updated, ask that it be documented. You can even provide guidelines to capture key information. Initially, some may think it cumbersome to require that  instructions be provided early in the development process. However, think of documentation to be like testing in that nobody really wants to do it but things work so much better. Sufficient testing and teaching are good for quality and momentum.

Code reviewers and maintainers of open source software have power. Code reviewers can (and should) withhold approval until documentation is sufficient.

Remember, not all changes require documentation updates. Here’s a good rule of thumb:

If an update to a project will require users to change their behavior, then documentation updates may be required.

If not, how will your customers find the new feature you worked so hard to implement? Said another way, if a change doesn't require tests, it probably doesn't require docs, either. Use your best judgement. For example, code refactoring and experimental tweaks need not be tested or documented.

As always, simplify and automate this process as much as possible. At Google, teams can enforce a presubmit check that either looks for a flag that indicates a doc update isn't necessary (presubmit checks for style issues can prevent a lot of arguments, too). We also allow owners of a file to submit changes without a review.

If your team balks at this requirement, remind them that simple project documentation is about sharing the information you have in your head so that many others can access it later without bothering you.

Documentation updates aren't typically onerous! The size of your documentation change scales with the size of your pull request (PR). If your PR contains a thousand lines of code, you may need to write a few hundred lines of documentation. If the PR contains a one-line change, you may need to change a word or two.

Finally, remember that documentation needn’t be perfect, but instead fit for use. What's most important is that key information is clearly conveyed.

5. Conduct regular freshness reviews

At least every quarter, review and update your content. Many hands make for many voices, many typos, and many inconsistencies. Don’t let content persist unchecked for years without periodically confirming it’s still useful.

In conclusion, success breeds success. By effectively documenting open source software, everybody wins.

We hope you'll put this guidance to work and help your open source project become even more successful! We'd love to hear from you if you do, or if you have questions or useful advice to share.

By Janet Davies, Google OpenDocs

Share your #DevFest18 story!

Posted by Erica Hanson, Developer Communities Program Manager

Over 80 countries are planning a DevFest this year!

Our GDG community is very excited as they aim to connect with 100,000 developers at 500 DevFests around the world to learn, share and build new things.

Most recently, GDG Nairobi hosted the largest developer festival in Kenya. On September 22nd, DevFest Nairobi engaged 1,200+ developers, from 26+ African countries, with 37% women in attendance! They had 44 sessions, 4 tracks and 11 codelabs facilitated by 5 GDEs (Google Developer Experts) among other notable speakers. The energy was so great, #DevFestNairobi was trending on Twitter that day!

GDG Tokyo held their third annual DevFest this year on September 1st, engaging with over 1,000 developers! GDG Tokyo hosted 42 sessions, 6 tracks and 35 codelabs by partnering with 14 communities specializing in technology including 3 women-led communities (DroidGirls, GTUG Girls, and XR Jyoshibu).

Share your story!

Our community is interested in hearing about what you learned at DevFest. Use #DevFestStories and #DevFest18 on social media. We would love to re-share some of your stories here on the Google Developers blog and Twitter! Check out a few great examples below.

Learn more about DevFest 2018 here and find a DevFest event near you here.

GDGs are local groups of developers interested in Google products and APIs. Each GDG group can host a variety of technical activities for developers - from just a few people getting together to watch the latest Google Developers videos, to large gatherings with demos, tech talks, or hackathons. Learn more about GDG here.

Follow us on Twitter and YouTube.

Introducing the new lead for Android Open Source Project

This week began with the announcement of Android 9 Pie and, as usual, the subsequent upstreaming of code to the Android Open Source Project (AOSP). But the release of Android 9 isn’t the only important Android news!

Tucked away in the announcement to the Android Building mailing list was this note:

“I also wanted to take a moment to introduce myself as the new Tech Lead / Manager for AOSP. My name is Jeff Bailey, and I’ve been involved in the Open Source community for more than two decades. Since I joined the Android team a few months ago, I’ve been learning how we do things and getting an understanding of how we could work better with the community. I’d love to hear from you: @JeffBaileyAOSP on Twitter or [email protected]. Be well!”

As Jeff notes in his introduction, he has a history in free and open source software (FOSS). He’s been an avid user, contributor, and maintainer since before the Open Source Definition was inked!

Jeff co-founded Savannah, where GNU software is developed and distributed, spent 15 years working on Debian, and has been an Ubuntu core developer. Further, he spent some time on the Google Open Source team and was involved in open sourcing Android back in 2008.

Open source projects, even those which originate inside of companies, are powered by the community of users and contributors that surround them. And those communities thrive when they have stewards who are steeped in the traditions of free and open source software. We’re excited for AOSP as Jeff takes the reins. He brings both technical and cultural skills to the table, and he’s been involved with the project since the beginning!

Suffice it to say, AOSP is in good hands. We welcome Jeff to his new role and, as he said in his introduction, he’d love to hear from the community: you can reach Jeff on Twitter and via email.

By Josh Simmons, Google Open Source

Join the “Build Actions for Your Community” Event Series

Posted by Ido Green, Developer Advocate

Ever wanted to learn about developing for the Google Assistant and meet other developers that are passionate about conversational UI? Well, we've got some good news!

Today, we are launching a global series of events about Actions on Google, run by Google Developers Groups (GDG) and other community groups. In these events, you'll be able to meet other developers and go together through educational content, uniquely crafted for these events by Google engineers. This includes tutorials on how to build your first Action and advanced sessions on how to use more complex features of the platform. By the end of the event you attend, you'll be able to build an Action for your community - be it your hometown, your professional network, or interest group.

And if you don't see an event near you, don't worry - you can always organize your own. We'll help!

It's going to be a great year for Actions developers. Please join us and check out the dedicated event website with all the event details and more information: developers.google.com/events/buildactions!