Striving for greatness

The life and times of a Gentoo developer and leader

Posts Tagged ‘community

3 days left to apply for the Google Summer of Code

Students, this Friday at 1900 UTC is the deadline to apply for this year’s GSoC. It’s an awesome program that pays you to work on open-source projects for a summer (where you == a university/college student).

It’s by no means too late, but start your application today. You can find more information on Gentoo’s projects here (click on the Ideas page to get started; also see our application guidelines) and on the broader GSoC program here.

Good luck!

Written by Donnie Berkholz

March 18, 2014 at 3:27 pm

Posted in Blog

Tagged with , , ,

OSCON meetups: FLOSS lunch, RedMonk beer

It’s been a few years, but I used to have an OSCON tradition of getting a bunch of interesting people together for lunch, from a variety of free-software and open-source communities.

This year I’m suggesting we do the same, on Wednesday of OSCON week. Let me know in the comments or via email if you’re interested.

I’ll also be hosting a RedMonk beering, beginning Wednesday night around 9:30–10pm. Location TBD, watch the Twitters.

Update (2013/07/19): Beers will begin around 9:30pm Wednesday at Bailey’s Taproom (213 SW Broadway, which is downtown). The place is open till midnight and we’ll likely be there till then.

Written by Donnie Berkholz

July 17, 2013 at 4:32 pm

Posted in Blog

Tagged with , , ,

3 days left to apply for the Google Summer of Code

Students, this Friday at 1900 UTC is the deadline to apply for this year’s GSoC. It’s an awesome program that pays you to work on open-source projects for a summer (where you == a university/college student).

It’s by no means too late, but start your application today. You can find more information on Gentoo’s projects here (click on the Ideas page to get started; also see our application guidelines) and on the broader GSoC program here.

Good luck!

Written by Donnie Berkholz

April 3, 2012 at 3:26 pm

Posted in Blog

Tagged with , , ,

If you’re in Europe, go to Monki Gras

To my European readers: if you care about the impact of social technologies like Git (and GitHub) & how they’re transforming software development, or the impact of social technology on communities, and you enjoy good beer, you need to be at Monki Gras. I just posted over at my RedMonk blog about how the previous conference in the series, Monktoberfest, was the best conference of my life. And I’ve been to many.

Monki Gras is Feb. 1–2 in London. The timing’s perfect to stop by just before FOSDEM (and that’s exactly what I’m doing). Registration is dirt-cheap, speakers are universally top-notch, and you’ll also get some world-class beers in the package.

Written by Donnie Berkholz

January 18, 2012 at 12:02 am

Posted in Blog

Tagged with , ,

The state of Gentoo

I just published an article over at LWN called “The state of Gentoo.”  In it, I talk about Gentoo’s progress over the past few years as well as its current problems, how they’re affecting Gentoo’s user and developer communities, and how to begin fixing them.

I’ve gotten a lot of positive feedback from our developers on the article so I’m confident that it’s generally a fair representation of where things stand today. However, Alex Legler (a3li) kindly told me our security team does much more behind the scenes to report vulnerabilities and get updated packages stabilized, even if we don’t see the results in the form of GLSAs.

Written by Donnie Berkholz

September 17, 2011 at 9:21 am

Posted in Blog

Tagged with , , ,

A vote for me is a vote for action

I’m running for the Gentoo council this year, and I wanted to post my “platform” here: who I am, why I’m running, how I see the council, and how I see Gentoo.

For anyone newer, I’d like to first introduce myself and my history with Gentoo. Over the past 8 years, I’ve spent time doing pretty much everything in Gentoo, from maintaining ebuilds to writing documentation and leading teams and projects. I’ve been a recruiter in devrel, served as desktop manager (back when we had top-level project managers, before GLEP 39), and later chaired the council. I also started the clustering team, led X11 maintenance for about 5 years (when I designed the modular X eclass and wrote all 400+ new modular packages as we transitioned from the old XFree86), spent a term as a foundation trustee, and acted as project manager for our ever-controversial GUI installer.

One of my primary roles at the moment is running our participation in the Google Summer of Code, one of our major sources of both income and new developers. Since I took over 3 years ago, we’ve more than doubled the size of our program (we have 15 students this year!) and greatly increased the proportion of students who eventually become Gentoo devs to roughly 67%.

At this point, I’m convinced I can make the biggest difference to Gentoo in two ways: focusing on specific projects like the git transition and improved eclass testing rather than ebuild maintenance (which we have tons of people doing), and leading Gentoo to greatness as a council member, where I’m in the best position to accomplish that goal.

On my last two terms as a council member, I was extremely active in council-related issues both on mailing lists and at meetings, rather than just showing up at meetings to vote and then disappearing into the sunset. I strongly believe that through preparation and accountability, we can have a more productive council, but this requires a true commitment on the part of every member.

Creating a great community

I see this as an area where the council can set direction for all of Gentoo, both through the positive examples of its members and by taking a stand against anything we won’t stand for in our community. The council should be providing guidance to devrel and userrel on what kinds of behaviors should be encouraged and what kinds shouldn’t be tolerated.

Additionally, we should begin collecting metrics on our community so we know where we’re going. Many other projects (and even distributions) do this already, to give them clues of when things are going wrong, what things are going right, etc.

Making progress now instead of waiting years for perfection

There’s a lot of ongoing projects and GLEPs that have been dragging on for years because people want a “perfect” solution. One personal example is the git transition, where I’ve already made this mistake in spending quite a bit of time trying to get a perfect repository layout working when we could have just done a simple conversion of the whole tree and put it in one repo (the current plan, with some changes).

GLEP 55 is another one. There are some times when any decision is better than no decision.

Removing bureaucracy in favor of more agile development & meritocracy

We all know that GLEP 39 needs some changes. I think that most devs just want to Get Stuff Done without fighting with policies, waiting around forever for votes, not getting majorities without any clear direction, and so forth. I believe that our devs vote in the council because they want those people in charge and trust the council members to do what they think is right, including deciding on changes to GLEP 39 to improve how we run things.

I favor a switch to a smaller group more along the lines of the Linux kernel, with a very small leadership core and more of a hierarchy than a huge committee.

Along the same lines, I favor a switch to a more meritocratic approach such as the lead appointments we’ve been discussing recently. Gentoo isn’t a country government that needs to provide for every sick and needy person in its geography; it’s a nonprofit with specific goals it needs to accomplish and should be run as such. In general, companies, including nonprofits, don’t have checks and balances or long, drawn-out votes. What they do have is a board of trustees at the top, which can replace the leadership when it deems necessary.

Another major problem is the lack of continuity in our leadership, mainly because the whole group is re-elected en masse every year. At a minimum, even if we can’t do the above changes, we should switch to a 2-year term and have half the council up for election each year so new councils can start out quickly.

Promoting innovation from individual developers instead of expecting it to all come from the top

As I mentioned above, one of my focuses now is working on interesting standalone projects. I hope that every developer does the same; in addition, or besides whatever you do every day (maintain ebuilds, write/translate docs, etc.), consider starting a new project that has a clear end in sight and that will help Gentoo get better. It doesn’t have to be anything big; and the great thing about projects with a finite length is that you actually finish them at some point.

Getting rid of policies that were created for a single incident, because they should only exist for patterns of repeated problems

A common problem in Gentoo is feeling like a one-time problem can’t be fixed without making a big policy about it, why it can’t be done, what will happen if it’s done again, etc. If you’ve been around Gentoo for a while and start reading through our developer docs, you’ll be able to connect a specific name and instance with pretty much every line that says something like “Don’t do stupid thing X” and “Don’t do ridiculous thing Y.”

I think part of this is rooted in a fear, for lack of a better word, to take personal responsibility for an action; instead, people want a rulebook to point at and say “That’s wrong” so the rulebook is the bad guy.

But rulebooks should only be for the common cases, the patterns, the problems that keep coming up over and over. One-time problems only deserve one-time solutions.

Written by Donnie Berkholz

June 27, 2011 at 8:29 am

The DOs and DON’Ts of Google Summer of Code: Student Edition

I’d like to point any potential Google Summer of Code applicants to a post on DOs and DON’Ts for students over on the Google Open Source blog that I wrote with Lydia Pintscher and Kevin Smith. They’re fellow admins from two other long-time GSoC participants, KDE and the XMPP Standards Foundation. Here’s a quick summary of the points; you’ll have to read the original post for details:

DO DON’T
Be on your best behavior. Make a bad first impression: SMS speech, extremely poor English, rudeness/hostility, etc.
Read all the documentation, so you submit a useful application. Submit a useless application.
Be transparent about other commitments. Disappear.
Make Google Summer of Code your top priority. Hold another major commitment.
Be realistic about your skills. Over- or under-rate your abilities.
Commit and publicize your code frequently. Make last-minute (or later) code drops.
Submit code that’s ready to integrate. Finish the summer with code that’s “almost ready” but will take forever to ship.
Complete your project design before writing a line of code. Start coding before finalizing design.
Use your resources wisely. Refuse to ask for help.
Remember that you’re part of a community. Consider it a solo project, like it often is in college.

Written by Donnie Berkholz

March 27, 2011 at 10:53 pm

Posted in Blog

Tagged with , , ,

Follow

Get every new post delivered to your Inbox.

Join 36 other followers