Navigation

Language Selection

Search

For project safety backup your people, not just your data

Submitted by Roy Schestowitz on Monday 16th of April 2018 08:31:20 AM Filed under

The FSF was founded in 1985, Perl in 1987 (happy 30th birthday, Perl!), and Linux in 1991. The term open source and the Open Source Initiative both came into being in 1998 (and turn 20 years old in 2018). Since then, free and open source software has grown to become the default choice for software development, enabling incredible innovation.

We, the greater open source community, have come of age. Millions of open source projects exist today, and each year the GitHub Octoverse reports millions of new public repositories. We rely on these projects every day, and many of us could not operate our services or our businesses without them.

So what happens when the leaders of these projects move on? How can we help ease those transitions while ensuring that the projects thrive? By teaching and encouraging succession planning.

Also:

Dear software manager, working in the open for the very first time? Challenges (

When moving from managing software projects/teams in classic corporate environments into Open Source (FOSS) projects, there are several new challenges any front line manager will need to face.

Dear software manager, working in the open for the very first time? Face the challenges (II)

Working in the open involve new challenges that requires a different mindset to be successfully faced by front line managers moving from corporate to Open Source projects. They will need to develop new habits and the most effective way to do so, in my view, is understanding since day one that your focus will need to move towards alignment instead of insisting in autonomy, according to my mental model. With that in mind, my advice is to pay special attention to those habits that will lead you to become a servant for your managees, promoting transparency by example…

Login or register to post comments
Printer-friendly version
1192 reads
PDF version

More in Tux Machines

Linux Networking Improvements To Mitigate Retpoline Overhead Ready For 4.21 Kernel

The recently talked about work to improve/restore Linux networking performance around Retpolines is queued now in net-next for the upcoming Linux 4.21 kernel cycle. This patch series for the Linux kernel's networking subsystem is about mitigating the Retpoline overhead introduced at the start of the year in order to address the Meltdown CPU security issue.

Linux 4.20--rc76

Well, that's more like it. This is a *tiny* rc7, just how I like it. Maybe it's because everybody is too busy prepping for the holidays, and maybe it's because we simply are doing well. Regardless, it's been a quiet week, and I hope the trend continues. The patch looks pretty small too, although it's skewed by a couple of bigger fixes (re-apply i915 workarounds after reset, and dm zoned bio completion fix). Other than that it's mainly all pretty small, and spread out (usual bulk of drivers, but some arch updates, filesystem fixes, core fixes, test updates..) Also: Linux 4.20-rc7 Kernel Released - Linux 4.20 Should Be Released In Time For Christmas

Android Leftovers

1080p Linux Gaming Performance - NVIDIA 415.22 vs. Mesa 19.0-devel RADV/RadeonSI

Stemming from the recent Radeon RX 590 Linux gaming benchmarks were some requests to see more 1080p gaming benchmarks, so here's that article with the low to medium tier graphics cards from the NVIDIA GeForce and AMD Radeon line-up while using the latest graphics drivers on Ubuntu 18.10. This round of benchmarking was done with the GeForce GTX 980, GTX 1060, GTX 1070, and GTX 1070 Ti using the newest 415.22 proprietary graphics driver. On the AMD side was using the patched Linux 4.20 kernel build (for RX 590 support) paired with Mesa 19.0-devel via the Padoka PPA while testing the Radeon RX 580 and RX 590.

Latest News

mv Command in Linux: 7 Essential Examples

mv command in Linux is used for moving and renaming files and directories. In this tutorial, you’ll learn some of the essential usages of the mv command.

8 tips to help non-techies move to Linux

ver the last 10 months, a handful of friends and acquaintances have pulled me back into that realm. How? With their desire to dump That Other Operating System™ and move to Linux. This has been an interesting experience, in no small part because most of the people aren't at all technical. They know how to use a computer to do what they need to do. Beyond that, they're not interested in delving deeper. That said, they were (and are) attracted to Linux for a number of reasons—probably because I constantly prattle on about it. While bringing them to the Linux side of the computing world, I learned a few things about helping non-techies move to Linux. If someone asks you to help them make the jump to Linux, these eight tips can help you. 1. Be honest about Linux. Linux is great. It's not perfect, though. It can be perplexing and sometimes frustrating for new users. It's best to prepare the person you're helping with a short pep talk. What should you talk about? Briefly explain what Linux is and how it differs from other operating systems. Explain what you can and can't do with it. Let them know some of the pain points they might encounter when using Linux daily. If you take a bit of time to ease them into Linux and open source, the switch won't be as jarring.

4 cool new projects to try in COPR for December 2018

COPR is a collection of personal repositories for software that isn’t carried in Fedora. Some software doesn’t conform to standards that allow easy packaging. Or it may not meet other Fedora standards, despite being free and open source. COPR can offer these projects outside the Fedora set of packages. Software in COPR isn’t supported by Fedora infrastructure or signed by the project. However, it can be a neat way to try new or experimental software.