GSoc Ideas

What is Google Summer of Code?

Spend your summer break writing code and learning about open source development while earning money! Accepted students work with a mentor and become a part of the open source community. Many become lifetime open source developers! The 2024 student application window will be open from March 18th to April 2nd 2024! But don’t wait for then to engage! Come to our Discord chat and forum to share ideas today.

Google Summer of Code is open to individuals age 18 and older in most countries who are new or beginner contributors to open source coding projects.

Read more on the GSoC site rules page and the FAQ.

Please read GSoC @ — documentation and for information ahead of using the gsoc-ideas tag.

Students looking for ideas

Start with and it’ll bring you back to the topics here after giving you a bit more introduction.

DO NOT direct message potential mentors.

Simply mention them in the body of messages to this forum, such as, “What do you think, @jkridner?”

Mentors wondering where to help

Check our our new mentoring guide at Mentor Guide — documentation

General requirements

Check out our contributor guide for general requirements at Contributor Guide — documentation

How to write a successful proposal

Check our proposal guide for the best chance of success at Proposal Guide — documentation

Considering becoming a mentor? Got a project idea?

Prospective mentors, prospective contributors will look here to make contact with you, so be sure to provide up-to-date information. Please feel free to add introduce yourself here and we will monitor and police this list. Acceptance as an official mentor with the ability to rate proposals and grade students will come via the Google system. We will only approve official mentors who have a prove track record with Beagle, but welcome all community members to provide guidance to both mentors and students to best service the community as a whole. Don’t be shy and don’t be offended when we edit.

Be sure to use the the template below for providing your project ideas. Remember these are supposed to be for software projects that service the Beagle and general open source embedded systems community, not theses, how-to guides or what I did over my summer vacation ideas.

Idea template

Please post ideas in the Google Summer of Code category with the tag gsoc-ideas.

Summarizing project name

Long summary of the project.

Goal: (concise statement that describes completion and expected outcomes)
Hardware Skills:
Software Skills:
Possible Mentors: (Discourse @nicknames of possible mentors for prospective students to contact)
Expected size of project: (90, 175 or 350 hour)
Rating: (easy, medium or hard)
Upstream Repository: (git repository and/or link to upstreaming process)

Have you considered placing the horse in front of the cart? Documentation along with clear and concise C code are vital for success. Analogous to owning a high performance sports car, yet you have no gasoline to run it…

Maybe it is time to realign the priorities and optimize what currently exists. Creating a core documentation base so those not familiar with working with the “board” can actually be productive. Spending countless hours chasing your tail because the docs are either stale or have significant voids generates negativity.

Look at PI, they have some of the best documentation and that is the only reason they have such a large market share.

Bottom line is, UNTIL your customer base can actually use the product you will not have happy customers. Happy customers turn into your best salespeople…

Maybe an evolved mission statement, a small sampling of ideas would be to focus on documentation, training, how to use powerful tools like git, remote building on an IDE that is tightly integrated with git and the the board.

Let new tech discoveries wait until you are at point where your customers can utilize what currently exists.

1 Like

That is a very astute observation. I’m not a hater of PI by any means, but they really do show how far documentation + community can propel a project. From a purely technical perspective, a RPI is almost never the best choice, but its the FIRST choice for hobbyist because they can get going so quickly.

Its also the choice in "commercial’ deployments. When you have to pay $150k a year to someone that can work with this stuff and they are spending days and weeks trying to piece together a solution the choice becomes obvious. Good docs and they are up and running, pretty obvious choice.

We’ve been putting in a lot of effort on documentation over at, but we have yet to really cross the divide to really enable community collaboration. All the docs welcome public contribution via Documentation / · GitLab.

Is there some tool we can use to provide more contextual feedback? is something I’ve used in small groups, but I wonder if there is something we can open up to the entire community to help improve the website and docsite content?

I wish I knew, most certainly would share that info.

It really needs young folks contributing to the content generation. As in, it needs to look “hip” if you want to have continuous engagement. Looking at “linux man page” format is not the most exciting thing to do.

Firmly believe it would have to be a framework that would exist solely on the beagles domain, NOT BIG TECH properties. Younger folks should be highly involved with the actual graphic content and format. This would make the content more engaging, thus stimulate innovation and more likely to get others involved.

Since digikey is one of the sponsors maybe reach out to their marking team and see what ideas they have. I don’t see their presence on this website, when you speak with them bring up the fact BB is not monetized. This is extremely important, it translates into NO DISTRACTIONS leading users to other sites. If other retailers want to get involved provide them with exposure, main thing is, the more one reseller contributes the more brand exposure. Main thing is make the commitment you will not have CPC / ad banners on the site. That means full focus on the serious players.

I’m not really sure what you are suggesting. The guys working on are reasonably young, unlike myself. I think they need really guided feedback to make the documentation better.

I think the most fundamental problems we are having are combinations of both documentation and software. We’ve had regressions with things like dynamic pinmuxing and helper tools as those features never landed completely upstream and we continue to rebase on upstream and old documentation breaks and new documentation never gets completed.

My current attack path is to update beagle-tester to test against the cape compatibility layer to provide a demonstration vehicle for the standard hardware I/O mechanisms against mainline kernels on all the boards. Building a massive mikroBUS breakout board should allow for testing of hundreds of mikroBUS add-on boards against a set of patches against mainline for pushing support into mainline.

Aside, I keep looking for lessons-learned from other projects to help with documentation, like Building a community of open-source documentation contributors - Stack Overflow.

1 Like

It must be visually appealing and presented in a visually appealing manner that invokes positive emotions.

The iconography (beagle dog) is centric to this. Do you remember the 3 hamsters driving the car?? Why did you actually remember that…

That is exactly what an OLD ENGINEER would like to hear.
Its a turn off to a youngster, see where this is going. The moment you talk technical you can see peoples eyes just glaze over and they shut down. (unless they are an old engineer).

Here is another path, you might see this in real time, I did. We are eating dinner and the entire time the news was on all my daughter and better-half would do is talk back and forth. Now when Steve Harvey came on, SILENCE, both were engaged watching TV because he is cool and exudes happy thoughts.