Connect with us

Commentary: For developers who want to become leaders in their chosen open source communities, the process is easier (and more difficult) than you might think.

Image: Getty Images/iStockphoto

There are at least two ways to become an open source project maintainer. The first is perhaps the most straightforward, though hardly easy: Start a project. This is the path taken by Simon Willison (Datasette), Rich Felker (musl libc), Gerald Combs (Wireshark), and others. The other is to build up credibility with an existing project over time, eventually earning the maintainer mantle. In some ways, this might be the harder path, but it’s one that Lili Cosic (kube-state-metrics/Kubernetes), Madelyn Olson (Redis), and Whitequark (Solvespace) have taken.

Most of us will never start our own project. But with a significant percentage of developers contributing to open source projects (49% of women and 64% of men, according to a DigitalOcean survey), there’s a real opportunity for developers to earn a leadership role within their preferred projects. For reasons I’ll detail below, it could be a more realistic goal than you might think.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Faster than you might think

In a series of conversations with open source project maintainers, I kept being surprised by how quickly goodwill could be earned within a project. For example, both Cosic and Olson have been full-time engineers for five or six years, and only engaged with their respective open source projects for two to three years. To go from limited/no involvement to the highest honor accorded an open source contributor in roughly two years is amazing. As Cosic said, “Some people say it’s very fast growth, but for me it’s just because I am very passionate about it.”

That passion shows up as commitment to a project, and such commitment ultimately builds influence within the community. 

For the developer who goes by the name Whitequark, her story is similar. In an interview, she said when she first encountered the Solvespace code, it was excellent at its core functions but was decidedly crufty in its code–it needed a revamp. She set to work:

I started to gradually and very carefully improve it. The fact that it was so stable and reliable was one of its two best qualities, along with the ease of use, so I did not want to make haphazard changes that would result in backwards incompatibility or losing data. (In the end, it took me something like two years to become comfortable with modifying most of its 30 kLOC codebase–purely in terms of programming, not going into any of the underlying math.) I kept a carefully updated patch set–I aspired to the same standards as the LLVM compiler patches, which I also used to co-maintain–and periodically asked Jonathan [the founder and maintainer] to review and merge them….

After a few months of this work, the maintainer decided he needed to move on, and entrusted the Solvespace maintainership to Whitequark. In her story, as well as those of Cosic and Olson, the key to becoming a trusted contributor (and, ultimately, maintainer) of an open source project emerges: Consistency.

“Consistency is the key”

Cosic called this out straightaway in our conversation: “Consistency is the key. Regardless if you contribute large pieces of code or small, it’s more about consistently contributing over a period of time. Usually…you need to contribute at least for a few months consistently. And that includes reviewing PRs and answering issues [on GitHub Issues, Stack Overflow, etc.].” Open source projects aren’t necessarily looking for would-be contributors to develop the equivalent of a cure for cancer for them–they just need people to show up and do the little things.

For Olson, she had no grand ambition to become a maintainer of Redis, the open source database to which she contributed. “There was no pathway to me becoming a maintainer,” Olson said. “I was not expecting it. I was just trying to be helpful and that ended up paying off.” 

In “trying to be helpful,” Olson didn’t try to commit major new functionality. Instead, she made it easier for others to do that work. “Almost all of my contributions are minor,” she said. “Normally I’m the one making small fixes all over the place, and then when someone really wants to commit something big, I help them get the code in better shape and then they submit it and I’m the ambassador to say, ‘Hey, Salvatore [project founder], we built this great thing.’ But I normally try to let the other person get more of the credit.” 

Such consistent, behind-the-scenes work might seem to go unappreciated, but it’s actually the precise work that most projects need. By consistently contributing “little” pull requests, developers can build their influence within a project and, perhaps, earn the distinction of being a maintainer on the project. 

If I’m making this sound overly simple, I don’t really intend that. As Drupal founder Dries Buytaert has pointed out, for example, “Open source is not a meritocracy,” because “inequality makes it difficult for underrepresented groups to have the ‘free time’ it takes to contribute to open source.” It’s a valid point. 

SEE: How to become an effective software development manager and team leader: Tips and advice from Drupal founder Dries Buytaert (TechRepublic)

Even many who are fortunate to have full-time employment aren’t necessarily encouraged by their companies to make time to contribute. For such, this is a mistake, as contributing to open source projects is a great way to influence their direction and care for customers. So for companies that depend upon open source (and that’s every company), it’s time to carve out space for your developers to make those consistent contributions over time. 

Disclosure: I work for AWS, but the views here are mine and don’t necessarily reflect those of AWS.

Also see

Source link

Continue Reading


Twist on CRISPR Gene Editing Treats Adult-Onset Muscular Dystrophy in Mice

2020 09 14 DM1 longitudnal muscle

Myotonic dystrophy type I is the most common type of adult-onset muscular dystrophy. People with the condition inherit repeated DNA segments that lead to the toxic buildup of repetitive RNA, the messenger that carries a gene’s recipe to the cell’s protein-making machinery. As a result, people born with myotonic dystrophy experience progressive muscle wasting and weakness and a wide variety of other debilitating symptoms.

CRISPR-Cas9 is a technique increasingly used in efforts to correct the genetic (DNA) defects that cause a variety of diseases. A few years ago, University of California San Diego School of Medicine researchers redirected the technique to instead modify RNA in a method they call RNA-targeting Cas9 (RCas9).

Twist on CRISPR Gene Editing Treats Adult Onset Muscular Dystrophy in

Green muscle fibers with RCas9 (the therapeutic candidate for myotonic dystrophy) have eliminated their toxic RNA (red), whereas fibers lacking RCas9 (dark) have persisting toxic RNA (red). Credit: UC San Diego

In a new study published in Nature Biomedical Engineering, the team demonstrates that one dose of RCas9 gene therapy can chew up toxic RNA and almost completely reverse symptoms in a mouse model of myotonic dystrophy.

“Many other severe neuromuscular diseases, such as Huntington’s and ALS, are also caused by similar RNA buildup,” said senior author Gene Yeo, PhD, professor of cellular and molecular medicine at UC San Diego School of Medicine. “There are no cures for these diseases.” Yeo led the study with collaborators at Locanabio, Inc. and the University of Florida.

Normally, CRISPR-Cas9 works by directing an enzyme called Cas9 to cut a specific target gene (DNA), thereby allowing researchers to inactivate or replace the gene. RCas9 works similarly, but Cas9 is guided to an RNA molecule instead of DNA.

In a 2016 study, Yeo’s team demonstrated that RCas9 worked by using it to track RNA in live cells. In a 2017 study in lab models and patient-derived cells, the researchers used RCas9 to eliminate 95 percent of the aberrant RNA linked to myotonic dystrophy type 1 and type 2, one type of ALS and Huntington’s disease.

The current study advances RCas9 therapy further, reversing myotonic dystrophy type 1 in a living organism: a mouse model of the disease.

The approach is a type of gene therapy. The team packaged RCas9 in a non-infectious virus, which is needed to deliver the RNA-chewing enzyme inside cells. They gave the mice a single dose of the therapy or a mock treatment.

RCas9 reduced aberrant RNA repeats by more than 50 percent, varying a bit depending on the tissue, and the treated myotonic dystrophy mice became essentially indistinguishable from healthy mice.

Initially, the team was worried that the RCas9 proteins, which are derived from bacteria, might cause an immune reaction in the mice and be rapidly cleared away. So they tried suppressing the mice’s immune systems briefly during treatment. As a result, they were surprised and pleased to discover that they prevented immune reaction and clearance, leaving the viral vehicle and its RCas9 cargo to persist, and get the job done. What’s more, they did not see signs of muscle damage. In contrast, they saw an increase in the activity of genes involved in new muscle formation.

“This opens up the floodgates to start testing RNA-targeting CRISPR-Cas9 as a potential approach to treat other human genetic diseases — there are at least 20 caused by buildup of repetitive RNAs,” Yeo said.

It remains to be seen if RCas9-based therapies will work in humans, or if they might cause deleterious side effects, such as eliciting an undesired immune reaction. Preclinical studies such as this one will help the team work out potential toxicities and evaluate long-term exposure.

In 2017, Yeo co-founded a company called Locanabio to accelerate the development of RNA-targeting CRISPR-Cas9 through preclinical testing and into clinical trials for the treatment of myotonic dystrophy and potentially other diseases.

Source: UC San Diego

Source link

Continue Reading


Microsoft Buys Bethesda-Owner ZeniMax for $7.5 Billion

Microsoft said on Monday it would acquire ZeniMax Media for $7.5 billion (Rs. 55,223 crores) in cash, strengthening its Xbox video game offering with the studio behind titles such as Fallout and the Doom reboot.

ZeniMax is the parent company of Bethesda Softworks, which has also developed hits including The Elder Scrolls, Wolfenstein, and Dishonored.

The deal comes more than a week after Microsoft’s failed bid for short video app TikTok’s US assets. TikTok has currently structured the deal as a partnership with Oracle and Walmart rather than an outright sale.

Microsoft said it plans to bring Bethesda’s future games into its monthly Xbox Game Pass subscription service when they launch on Xbox or PC. The game pass now has more than 15 million subscribers, Microsoft added.

Bethesda’s structure and leadership will remain in place, Microsoft said.

Gaming is on a tear due to demand from stuck-at-home users during the COVID-19 pandemic and Microsoft has put its faith in offering users many ways to play via its cloud service and consoles at different price points.

Microsoft said the ZeniMax deal will close in the second half of fiscal year 2021, and have minimal impact on adjusted operating income in fiscal years 2021 and 2022.

© Thomson Reuters 2020

Source link

Continue Reading


Open source: Why governments need to go further


Commentary: Yes, governments should open source their custom code. But more than that is needed.

Image: lucky-photographer, Getty Images/iStockphoto

For Drupal (and Acquia) founder Dries Buytaert, “the default [in government] should be ‘developed with public money, make it public code.'” That is, if a government is paying for software to be created, that software should be available under an open source license. While he acknowledged there might be exceptions (e.g., for military applications, as I’ve called out), his suggestion makes sense.

Years ago I argued that government mandates of open source made no sense. I still feel that way. Governments (and enterprises) should use whatever software best enables them to get work done. Increasingly, that software will be open source. But when good open source alternatives don’t yet exist, it makes no sense to mandate the use of suboptimal software. 

But software that governments create? There’s no compelling citizen-focused reason for closing it off. Instead, there are many reasons to open it up.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

Of the people, by the people, for the people

This topic of why countries should embrace open source is an easy argument to make. As Buytaert pointed out, if public money pays for the code to be developed, why wouldn’t that code be available to the public (except, as mentioned, in the case of sensitive military software)? 

Some countries have already gone this route. As I detailed in 2016, Bulgaria is one of them. A few years later, Bulgaria has been preparing its own national source code repository, based on Git (as required by law: “administrative authorities shall use public storage and control systems for the source code and technical documentation for development, upgrading or deployment of information systems or electronic services”). 

This is a significant step toward greater transparency. However, it’s not enough.

SEE: Open source can thrive in a recession says Drupal creator Dries Buytaert (TechRepublic)

Collaborating on common government issues

As much as I understand Bulgaria’s desire to build its own source code repository, there’s even greater need for governments to collaborate on code beyond their borders. Think about it: Governments tend to do the same things, like collecting taxes, issuing parking tickets, etc. Currently, each government builds (or buys) software to tackle these tasks. Obscene quantities of custom code are created each year by government organizations operating in silos.

Why isn’t the city of Bogota sharing software with London, which shares software with Lagos, which shares software with Pocatello (that’s in Idaho, by the way)? 

As IBM president (and former Red Hat CEO) Jim Whitehurst said way back in 2009, “The waste in IT software development is extraordinary….Ultimately, for open source to provide value to all of our customers worldwide, we need to get our customers not only as users of open source products but truly engaged in open source and taking part in the development community.” This is particularly true in government, where there isn’t even the competitive pressure (e.g., Bogota doesn’t compete with Pocatello) that might prevent large financial institutions from collaborating (though even they partner on open source).

So, yes, we need governments to open source the software they pay to have built, to Buytaert’s point. But we also need those same governments to share that code beyond their borders, thereby driving greater innovation at lower cost for their citizens. 

Disclosure: I work for AWS but the views expressed herein are mine, not those of my employer.

Also see

Source link

Continue Reading