More Tips for Managing a Fast-Growing Open Source Project



  • open source project

    Matt Butcher provides tips for managing open source projects based on experience with Kubernetes Helm.

    As open source technology has become more strategically important for organizations everywhere, many tech workers are choosing to or being asked to build out and oversee their own open source projects. From Google, to Netflix to Facebook, companies are also releasing their open source creations to the community. These efforts require more management than may seem apparent at first, and there is also a particular kind of “nice problem to have” that can arise. Specifically, a new open source project can suddenly take on a life of its own, growing far faster than ever imagined.

    That nice problem to have was the subject of an Open Source Summit 2017 session presented by Matt Butcher, Principal Software Development Engineer at Microsoft. We covered some of his advice for open source projects in a previous post. And, here, we discuss specific project management issues Butcher has faced.

    In his talk, Butcher cited examples from the Kubernetes Helm project, which grew to involve hundreds of contributors and thousands of active users in a span of 18 months…

    Minefields and sparring matches

    One thing Butcher and his collaborators on the Helm project learned is that managing governance and standards is an ongoing challenge. They also learned that code reviews can become “minefields of interaction,” where community members may have unexpected motives behind their messages. “I have been involved in situations where code reviews become a sparring match,” said Butcher.

    “With Helm, we developed guidelines for them. They can develop in such a way that some people will just want to weigh in and show that they’re right. In some cases it’s very important to acknowledge contributions We actually have an internal rule in our core maintainers guide that says, ‘Make sure that at least one comment that you leave on a code review, if you’re asking for changes, is a positive one. It sounds really juvenile, right? But it serves a specific purpose. It lets somebody know, ‘I acknowledge that you just made a gift of your time and your resources,” he said.

    Shifting perspective

    Butcher also noted that team dynamics can change quickly as internal focus shifts to external focus. “At some point you’re going to release your project out into the wild, and then you’ll hit your stability marker, which might be, say, your version 1.0,” he said. “At that point your perspective changes and you say, ‘Hey, instead of huddling together to work on our team dynamics, we’re all going to face outward. That can be a touchy border to be on.”

    In the case of Helm, team members reached out in unexpected ways during the early growth phase. “We did some crazy stuff when we were launching it,” Butcher said. “We actually had kind of an internal semi-formal policy that you would pair with people who came in and had big problems, which resulted in random people from the team joining meetings with people they’d never met and saying, ‘Hey, tell me about your problem and let me see if I can help.’ The whole point of this was to try and actively pull people into the community and get them engaged right away.”

    Timelines are guidelines

    Butcher stressed that project managers should “know what they’re building and be ruthless about sticking to it.” That means, in some cases, that timelines are guidelines. “You want to commit to timelines, because that’s respectful to the community,” he said. “On the flip side, you also are trying to keep your core contributors motivated. You don’t want them to feel undue pressure. In many cases the community understands that you are at the liberty of the contributors and sometimes something does come up. At times, we had to go back to the community and say, ‘we couldn’t do it because the Kubernetes team isn’t ready for us yet, so we’re going to have to wait a little while.”

    You can learn more about open source project management in The Linux Foundation’s growing collection of Open Source Guides for the Enterprise. These free online guides cover starting an open source project, improving your open source impact, participating in open source communities, and more.

    Share your knowledge and expertise at Open Source Summit North America, happening August 29-31 in Vancouver BC. Proposals are being accepted through April 29th.

    The post More Tips for Managing a Fast-Growing Open Source Project appeared first on The Linux Foundation.

    https://www.linuxfoundation.org/blog/more-tips-for-managing-a-fast-growing-open-source-project/





Tmux Commands

screen and tmux

A comparison of the features (or more-so just a table of notes for accessing some of those features) for GNU screen and BSD-licensed tmux.

The formatting here is simple enough to understand (I would hope). ^ means ctrl+, so ^x is ctrl+x. M- means meta (generally left-alt or escape)+, so M-x is left-alt+x

It should be noted that this is no where near a full feature-set of either group. This - being a cheat-sheet - is just to point out the most very basic features to get you on the road.

Trust the developers and manpage writers more than me. This document is originally from 2009 when tmux was still new - since then both of these programs have had many updates and features added (not all of which have been dutifully noted here).

Action tmux screen
start a new session tmux OR
tmux new OR
tmux new-session
screen
re-attach a detached session tmux attach OR
tmux attach-session
screen-r
re-attach an attached session (detaching it from elsewhere) tmux attach -d OR
tmux attach-session -d
screen -dr
re-attach an attached session (keeping it attached elsewhere) tmux attach OR
tmux attach-session
screen -x
detach from currently attached session ^b d OR
^b :detach
^a ^d OR
^a :detach
rename-window to newname ^b , <newname> OR
^b :rename-window <newn>
^a A <newname>
list windows ^b w ^a w
list windows in chooseable menu ^a "
go to window # ^b # ^a #
go to last-active window ^b l ^a ^a
go to next window ^b n ^a n
go to previous window ^b p ^a p
see keybindings ^b ? ^a ?
list sessions ^b s OR
tmux ls OR
tmux list-sessions
screen -ls
toggle visual bell ^a ^g
create another window ^b c ^a c
exit current shell/window ^d ^d
split window/pane horizontally ^b " ^a S
split window/pane vertically ^b % ^a |
switch to other pane ^b o ^a <tab>
kill the current pane ^b x OR (logout/^D)
collapse the current pane/split (but leave processes running) ^a X
cycle location of panes ^b ^o
swap current pane with previous ^b {
swap current pane with next ^b }
show time ^b t
show numeric values of panes ^b q
toggle zoom-state of current pane (maximize/return current pane) ^b z
break the current pane out of its window (to form new window) ^b !
re-arrange current panels within same window (different layouts) ^b [space]
Kill the current window (and all panes within) ^b killw [target-window]
  • FYI for FreeBSD the driver only supports block size chunks, therefore:

    dd if=/dev/cd0 of=/name-the.iso bs=2048

    read more
  • sort -g /var/log/nginx/access.log | awk '{print $1}' | uniq

    read more
});