Open Tech Strategies can help you migrate off of Phabricator now that it has reached end-of-life. We developed Forgerie, an open source tool that aids in migration between code forges. Forgerie extracts data from your Phabricator instance and injects it into a GitLab instance. It can also help move repositories to a GitHub account.
Using Forgerie is a process. It requires setting parameters, running the tool, examining the results, tweaking the parameters, and re-running until the result meets your needs. Our team can help you with this process. We can move you to your own GitLab instance, host an instance for you, or get you migrated to GitLab.com or GitHub.
One of the insider secrets of free and open source software (FOSS) is that most of the rules a project uses on a day-to-day basis are not found in the software’s license. There are contribution guidelines, which are enforced by the project only taking contributions that meet them. There are codes of conduct, which are a condition of community participation. There are endorsements, official membership, a voice in setting the project roadmap, and all kinds of other benefits that attach to varying types of community participation. In each case, entirely external to the license, there are official rules and unwritten norms that govern how participants gain the benefits of joining the civic life of a project.
If you were to make an ecosystem map of an open source project, you might place the project in the middle of the page and then depict scale of involvement as distance from that center. The closer to the center a participant sits, the more influence the project has on them; the further from the center, the less sway the project has.
At the center is the project itself: its core developers and the people who have made commitments that affect the project’s outputs and actions. A project has a lot of visibility into how these participants act because tight, highly-connected cooperation is beneficial for everyone, and so participants are motivated to act in ways that avoid damaging that cooperation. This mechanism is so natural that most projects do not often think of it as something they could expand intentionally. But sometimes projects do exactly that: they figure out ways to deliberately widen their sphere of influence.
For example, Joomla, maintains a directory of third party extensions. It is the way most users discover Joomla extensions. For many businesses based on providing Joomla extensions, absence from that directory is akin to not existing at all. When the Joomla project decided to tighten license compliance among its extension developer community, they didn’t ask their lawyer to run around issuing threats. They simply explained that any project that wanted to appear in that directory must abide by community rules, https://docs.joomla.org/Extensions_and_GPL. Extension developers came into line.
A similar example can be seen in the Guidelines for Commercial Entities at the Arches Project. A glance over the guidelines will show the kinds of real-world problems they were developed to address. Only those who agree to the guidelines are listed in the official directory of Arches service providers.
Of course, being in some kind of project-endorsed directory is just one type of gateway. Another is participation in the project at all, that is, the ability to take part in project discussions, to vote (when there are decisions made by vote), and to have one’s contributions evaluated and accepted by the project with full attribution. Getting contributions accepted into the core project on a regular basis is important for those whose businesses depend on the project. If they can’t get their bugfixes and new features accepted upstream, then they may be forced to maintain their own divergent version (the term of art is “vendor branch”) indefinitely — a situation whose technical and organizational costs only get worse over time.
The right techniques will differ from project to project, because they must be based on the particular project’s history (as in the examples above). But the general reason these techniques work is that the non-code parts of a project are valuable in their own right. Those parts are not covered by the code’s license, but rather by the project’s norms and rules. Crucially, these parts cannot be replicated: unlike the code, you can’t make a copy of a community, or of a developer’s attention, or of an endorsement’s value. Equally crucially, none of them can be demanded by bad actors. The benefits of participation flow naturally to community members in good standing and it is equally natural to deny them to people and firms that refuse to align themselves with the community ethos. Creating structures that allow projects to control access to community benefits is a powerful way to enforce norms.
Using community participation as the mechanism for promulgating norms has its limits. Some participants stay far enough from the center of the project that they are effectively immune to community inducements. (Fortunately, projects have other mechanisms available to influence them, and we will cover some of those in a future post.) But in most cases, organizations that have a core reliance on the code will find multiple reasons to stay in good standing with the community, and this means the project has a chance to influence how those organizations behave. Spotting these leverage points takes experience as well as an understanding of project goals and positioning. Projects that want to wield influence over their ecosystem — whether for strategic or ethical ends — should actively look for ways to provide value backed by network effects, until the case for participation is overwhelming.
Note: This is an updated version of an article I first wrote in 2011. The original site went offline for a while, and although it was later restored, thanks to heroic efforts by Philip Ashlock, I felt the article needed a new home, and wanted a chance to update it anyway. This version also incorporates some suggestions from V. David Zvenyach.
Over the years we’ve watched software projects of all sizes make the transition from closed-source to open source. The lesson we consistently draw from them is this:
If you’re running a software project and you plan to make it open source eventually, then just make it open source from the beginning of development.
Open source is a broad term that encompasses many different types of projects. There is a wide range of open source approaches, and sometimes it helps to think through how your open source approach matches your goals, resources, and environment. In many places we look, we see open source used as a catch-all term to refer to every project. We don’t have a common vocabulary to discuss open source in ways that take account of important differences.
OTS prepared a field guide to open source project archetypes with Mozilla that is a first step in addressing that problem. The report catalogs a number of open source archetypes we observe around the community. OTS and Mozilla have found these archetypes to be a useful resource when crafting strategy, weighing tradeoffs, and committing support to open source endeavors. Today, we share the results of this work with the community. Continue reading “Field Guide To Open Source Project Archetypes”
Ethan Zuckerman has a piece in Wired that says building decentralization tools is a sucker’s bet. He and his coauthors, Chelsea Barabas and Neha Narula, mention the FreedomBox, which I helped lead, as an example of how difficult this stuff is. They point to a list of things that make decentralized efforts prone to failure and conclude:
Our research—a combination of technical and historical analysis, and dozens of interviews with open web advocates—indicates that there is no straightforward technical solution to the problem of platform monopolies. Moreover, it’s not clear we can solve the nuanced issues of centralization by pushing for “re-decentralization” of publishing online. The reality is that most people do not want to run their own web servers or social network nodes. They want to engage with the web through friendlier platforms, and these platforms will be constrained by the same forces that drive consolidation today.
They point to a “better strategy” of policies aimed at “data portability, interoperability, and alternatives to advertising-based funding models”.
I’m no longer with FreedomBox, and none of what they write is wrong (I was one of the open web advocates they interviewed), but I wanted to chime in because there’s more to decentralization than seeking a “straightforward technical solution” and building a better social networking app. It’s true that we haven’t realized the grand vision of Diaspora and FreedomBox. They’re right that we need enlightened policy. We need the centralized platform monopolies to behave better. Those steps, though, won’t ever give people control over the means of communication. Without that control, we’ll always be at the mercy of Facebook or whatever comes next. Continue reading “Decentralization: Worth The Wait”
GitHub hosted the “Wontfix Cabal” last week in San Francisco, and I was lucky enough to attend, thanks to a pointer from a friend. The organizers, led by Jess Frazelle, conceived the gathering as a chance for people maintaining open source projects to discuss their particular difficulties and some strategies for addressing them. About 100 maintainers took them up on it and convened in San Francisco. At the beginning of the day, we compiled dozens of sticky notes worth of problems that come up in our various projects. These ranged from tips for maintainers who had received the classic question “Is this project still maintained?” to “Ethics and Exploitation in Open Source.” In a common unconference pattern, attendees voted on those topics. The most popular topics were chosen to become discussion groups, and we split up for a morning session and an afternoon session. Continue reading “Attending the Wontfix Cabal”
Note: This is a draft of a Code of Conduct meant to help a specific open source project give guidance to its commercial participants. The project is already in production use, and is successful enough that some commercial entities have become involved, offering support, hosting services, customization, etc. However, those companies need some guidelines about how to conduct themselves, in relation to the project as a whole and in relation to each other.
The first half of the draft is aimed at commercial entities. The second half of the draft contains guidelines for the open source project itself — healthy commercial participation being a two-way street.
Once the text is finalized, we plan is to post this in generic form, as a template that other projects can use, while delivering a customized version to that project.
In the meantime, comments welcome! You can simply leave regular blog comments, but we’ve also enabled the open source Hypothes.is WordPress annotation plugin to allow sidebar annotations of selected text. To use it, just mouse-select any passage of text, as though you were going to copy it to the clipboard, and then wait for the Hypothes.is annotation action buttons to pop up right under your selected text. There should be two of them: “Annotate” and “Highlight”. Choose “Annotate”, and then, at the top of the right-hand sidebar that should now open up, create a free account at Hypothes.is, or sign in if you already have an account. (We need the authentication step to help prevent spam annotations.) Once you are signed in, you can leave a sidebar comment associated with a specific passage of text — the user interface should be pretty clear from this point on. Please note that your comments will be publicly visible by default; you can also make an annnotation that’s private to yourself, but then we wouldn’t be able to see it either of course.
When you hire a development shop to build an open source product, you want to make sure the result is truly open source. You want to guarantee that:
The end product is independently deployable by others.
There are clear instructions for how to get involved.
Commercial third parties are welcome (because that’s usually where new development energy comes from).
There are no unexpected proprietary dependencies.
The developers respond constructively to bug reports.
There are procedures in place (as there should be for any software) for receiving sensitive security vulnerability reports.
The project is poised to become a multi-participant and even multi-vendor community.
However, often first forays into open source do not meet these goals — not because of bad intentions, but because vendors who are new to open source need some help.
Open Source IV&V provides vendors that help. An independent vendor specializing in open source works alongside the development vendor, playing the role of open source community from the start of the project. The IV&V vendor works with the development vendor out in the open, just as third-party participants would. By the time the first production release is ready, the development vendor knows how to navigate an open source project, technically and culturally.