For open source projects, it can be difficult to find balance between a number of factors: the free time of contributors, the desires of the communities using the project, the ability to on-ramp and mentor new contributors, and to provide necessary guidance and feedback. The Rust Project, and multiple sub-teams and working groups have found success in use of the RFC Process for making informed, high level decisions. However, the RFC process does not address the work necessary for exploratory projects before a decision is made, the work necessary to implement made decisions, or the work necessary to maintain and overhaul parts of the projects in the long run. To address these needs, I'd like to propose a general concept and approach called Shepherding, which aims to assist maintainers of these projects with this aspect of managing the project. By enumerating core goals and putting a name to concepts, but specifically NOT mandating every aspect of implementation, I hope that this technique can be applied across many teams inside and outside of the Rust Project. The "Shepherding v3.1" name comes from a blog post written by Niko Matsakis titled Shepherds 3.0, which also does an excellent job describing the motivations regarding these efforts. This post instead makes a few clarifications and additions to the 3.0 post, and aims to be a "reference manual" for the concept, defining terms and important goals, rather than discussing motivations. Discuss on Reddit Discuss on Twitter
Refining Rust's RFCs · Aaron Turon
At the heart of Rust’s open development is the RFC process. Every major change to the language, compiler, core libraries, tooling, and policy go through an RFC writeup and consensus-building process. The process served us incredibly well in clarifying our technical direction on the road to 1.0, and has continued to be highly active since then, with on average about 2 RFCs merged every week.
We need to talk about RFCs
I think the Rust RFC process needs serious reform. In this blog post, I'll explain why I think that, by covering some of the problems with the current process. Before I get all negative, I think RFCs are amazing! They've been a crucial part of Rust's open design and community-focussed
Rust is not a Company
Last year, as an occasional contributor to the Rust project, I did not think much about the organisational structure of the team behind the project. I saw a hierarchy of teams and groups, team leaders, etc. Just like any other organisation. This year, after getting more involved, becoming a library team member and eventually team lead, I spent some more time thinking about why we have this structure, what these teams are for.
Designing and Programming Malleable Software
User needs for software features and interfaces are diverse and changing, motivating the goal of making it as easy as possible for users themselves to change software, or to have it changed on their behalf in response to their developing needs. However, in my opinion, current approaches do not address this issue adequately: software engineering promotes flexible code, but in practice this does not help end-users effect change in their software. End-user and live programming systems help users customize their interfaces by accessing and modifying the underlying source code. I take a different approach, seeking to maximize the kinds of modifications that can take place through regular interactions, e.g. direct manipulation of interface elements. I call this approach malleable software. To understand contemporary needs for and barriers to modifying software, I study how it is produced, maintained, adopted, and appropriated in a network of communities working with biodiversity data. I find that the mode of software production, i.e. the technologies and economic relations that produce software, is biased towards centralized, one-size-fits-all systems. This leads me to propose a long-term, interdisciplinary research program in reforming the tools of software development to create infrastructures for plurality. These tools should help multiple communities collaborate without forcing them to consolidate around identical interfaces or data representations. Malleable software is one such infrastructure, in which interactive systems are dynamic constellations of interfaces, devices, and programs assembled at the site of use. My technological contribution is a reconstruction of the programming mechanisms used to create interactive behavior. I generalize existing control structures for interaction as entanglements, and develop a higher-order control structure, entanglers, which produces entanglements when particular pre-conditions, called co-occurrences, are met. Entanglers cause interactions to be assembled dynamically as system components come and go. I develop these mechanisms in Tangler, a prototype environment for building malleable interactive software. I demonstrate how Tangler supports malleability through a set of benchmark cases illustrating how users can modify systems by themselves or with programmer assistance. This thesis is an early step towards a paradigm for programming and designing malleable software that can keep up with human diversity.
Rust in 2021
This is my response for this year's call for blog posts. I am writing this as a language implementor, not as a language user. I also don't try to prioritize the problems. The two things I'll mention are the things that worry me most without reflecting on the overall state of the project. They are not necessary the most important things.
Rust 2019: Ownership without fear – Dirkjan Ochtman
Like last year, the Rust community team asked community members to write blog posts "proposing goals and directions for 2019"; this is mine. Like withoutboats' post and Niko Matsakis' take, this post will focus on organizational issues. As such, the "ownership" from the title refers to a leadership principle, not the technical type system concept we all know and love.
What Is Open Source Strategy? — Open Tech Strategies | Blog
There is a lot of documentation out there on how to do open source well at the project level. Historically, many projects have been started by developers, often on their own initiative, and the first non-technical questions they faced tended to be about project coordination (like "What collaboration tools shall we use?" or "What will our code review practices be?") and about community management (like "How do we decide who has commit access?" and "How do we integrate newcomers smoothly?"). Because developers hate to solve the same problems over and over, there is a wealth of detailed and varied material addressing those sorts of questions (we've even written some ourselves, but it's just a drop in the bucket of what's available). Taken together, this literature thoroughly answers the question "How do we execute the best tactics for developing open source software?"
Rust for Java Devs
I’d like to take a change for this blog and leave the more bleeding edge topics to focus on perhaps one of the most important things one can do in the Rust community: teaching new Rust …
OpenWork — Open source Claude Cowork alternative for teams
Bring your own model and provider, wire in your tools and context, and ship reusable agent setups across your org — with guardrails built in.
Rust And Game Development
Rust is excellent for performance crucial applications that run on multi-processor architectures and these two aspects are also critical for game development. Rust has already seen a bunch of interest from games developers like Chucklefish, Embark Studios, Ready at Dawn, etc. - but in order to really excel I’d love to organize some structured efforts to improve the ecosystem and I think it would be great if the 2019 roadmap will include game development.
[Proposal] WG for group/community standards and infrastructure in ATProto
TLDR: I’m proposing a working group to develop shared interoperable standards for community infrastructure within ATProto. Many teams are independently making foundational design decisions about group/community membership, governance, and infrastructure. Without coordination, a de facto standard will calcify from momentum rather than deliberate evaluation of the ranges of community needs. I provide initial questions and principles to start discussion. Many people, apps and projects in developme...
A Call to Build Models Like We Build Open-Source Software
1 Introduction 2 A brief explanation of open-source software development 3 Community-developed and continually-improved models 3.1 Incremental and cheaply-communicable updates 3.2 Merging models 3.3 Vetting community contributions 3.4 Versioning and backward compatibility 3.5 Modularity and distribution 4 An example future 5 Conclusion
Rust Governance: Scaling Empathy
There’s been a lot of talk about improving Rust’s governance model lately. As we decompress from last year’s hectic edition work, we’re slowly starting to look at all the bits of debt we accumulated …
BREAKING NEWS: oTToDev is Now the OFFICIAL Open Source Bolt.new
One year of Rust | Rust Blog
Empowering everyone to build reliable and efficient software.
