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”
OTS has been lucky enough to work with the Red Cross of Chicago and Northern Illinois (CNI) for the past year and a half, thanks in large part to the civic data community at Chi Hack Night. With Jim McGowan, CNI’s Director of Planning and Situational Awareness, we developed the open source Smoke Alarm Request Portal, where you can request to have a volunteer come install a smoke alarm in your home for free.
Now we’re connecting the Smoke Alarm Request Portal to allReady, an open source platform for volunteer preparedness and coordination (part of the Humanitarian Toolbox suite of disaster preparedness and prevention tools). With help from both open source communities, the two applications will share data to simplify the process of scheduling smoke alarm installations. Continue reading “Sharing data across Red Cross projects: the Smoke Alarm Portal and allReady”
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.
OS IV&V helps expand the range of vendors you can consider hiring to do open source development, and it ensures that by the time the project reaches beta, there are at least two vendors who have technical and deployment knowledge of the code base. Continue reading “OS IV&V: Independent Verification and Validation for Open Source”
My piece “Dissecting The Myth That Open Source Software Is Not Commercial” has just been posted at the IEEE Software Blog. Comments over there, please.
Many thanks to editor Stefano Zacchiroli for editing, and for suggesting a post in the first place.
When I tell people that I work at an open source consulting company, I often get puzzled glances (or those agreeable nods that mean “I have no idea what you’re talking about”). What does “open source consulting company” mean? What does OTS do, exactly? Continue reading “What OTS Does.”