Marketing and web presence

Web presence is an interesting ball of wax from a social and a technological point of view. The challenges presented to SIL International in its use of the web for products is not unique to the International Non-govermental organization. So, suggestions and critiques as presented here are not new to the industry at large but rather describe where the management challenges exist around this particular product.

In one sense web-presence is marketing and marketing is public relations, and public relations is communication. What is communicated about the product, how is it being communicated, and where is it being communicated?

In this way the "open" project is not just "is the code accessable" but goes down to how transparent and how involving is the management or govenance of the project. This of course is only one component of building online community, another seperate issue is building a wide userbase and yet a third is supporing an eco-system of data using tools.

This chapter is about all three components. Open Managment as a strategy of creating community, creating an interactive web platform which facilitates expanding the userbase, and facilitating the ecosystem of data-tools and data products.

Open Managment

There are many resoruces about managing projects and even some about managing open source projects. I copy these following two articles from Ben Balter, someone who works for github and has an extensive background in using open source in govenment. In my opinion these articles highlight the distinction between open source and open managment and challeng us to get to the heart of open source in our projects. In the FELx ecosystem of managment I think we do not strive for open managment, even though the code base is open source. The management of our software projects is really important to our continued success and the continued viability of our project to the market place need. The historical perception has been that SIL International has the ability to create the market demand for its own software. This is no-longer true. SIL International has market place competetion. In the last 20 years the endangered language movement has encouraged the involvement of many kinds of individuals in the recording of minority languages. These communities have often asked for language development activities to be conducted as a response to language documentation activities. Additionally, SIL International has taken intentional steps to work with its Wycliffe Organiation partners to create and nuture locally (at the regional, sub-national level) and nationally oriented organizations for language developement and Bible translation. This means that operationally, now instead of the 127 different SIL organizations and Wycliffe organizations there are perhaps 1000 organizations globally. These market place contenders do not all apprciate or utilize tools in the same way. It also means that there is no ogranizational consensus for what problem spaces look like or should look like. The reaction of techincal visionaries to this "confusion" is the production of new tools. For instance the following each in a way do overlap with some components of the FLEx eco-system:

These tools can only become available because the FELx eco-system is not seen as worth while extending or is too difficult to enter as a programer. To some extent then we should be looking not just at the managment of FLEx but also at the managment of the FLEx induced eco-system.

Disclosed source is not the same as open source

Posted September 29, 2014: http://ben.balter.com/2014/09/29/source-disclosed-is-not-the-same-as-open-source/

It’s not uncommon for government agencies to contact GitHub, looking for advice on how best to “publish” government-funded source code for “consumption” by the open source community. While a necessary and admirable first step, efforts to “release” source code, in reality, often fall short of actually being open source.

The argument. Open source is a philosophy, a workflow, and most importantly a collaborative community, the basis of which is the opportunity to participate.

Disclosed source

Government agencies and individual developers are free to make their projects’ underlying source code available for others to review, inspect, or reuse as they wish. This can be as simple as posting a zip file to an agency-owned FTP server, responding to a FOIA request by email, or even posting the source code to a code-sharing service like GitHub. Source code release under this paradigm is traditionally referred to as source disclosed, and is the first, not the final step in “open sourcing” government-funded code.

In addition to disclosing the underlying source code, in order to conform to with what we traditionally think of as open source today, publishers must properly license their code (generally not an issue with government), and should seek to create a community around the shared challenge the project sets out to solve.

Growing communities around shared challenges

Agencies that simply publish code with no intention to foster community involvement, curate community feedback, or accept community contributions find themselves, almost without exception, engaging in an unsuccessful endeavor. Rather than abandoning the code on the open-source community’s collective doorstep, the agency should expend effort, post-release, to ensure the project’s continued success.

At the most simple level, this is a matter of communicating the project’s goals and status to potential contributors

Free like a puppy

It’s often said that open source is free as in speech, not as in beer, but I prefer to take that a step further, and note that open source is free like a puppy. You’ll get a lot out of the relationship, but you also have to put a lot in, the biggest contribution being a base level of trust.

Agencies are welcome (and encouraged) to disclose the source code that powers the day-to-day workings of our shared democracy, but they should know that that’s neither the last step, nor is that truly open source. Open source is a symbiotic relationship, a shared partnership, not a one-way, one-time, set-it-and-forget-it broadcast.

  1. You can read more community building best practices within the government community on GitHub

Open source, not just software anymore

Posted January 27, 2014: http://ben.balter.com/2014/01/27/open-collaboration/

Open source is collaborative, or at least, I thought it was. What modern hackers have been calling open source, may in fact be something else, especially when we start to use those workflows to collaborate on things beyond just computer code.

Open source as a philosophy

@benbalter The internet has noticed that you tried to define “open source”

Not an email that you receive every day. As part of an effort to lower the barrier for getting started with GitHub, we published a glossary of common GitHub jargon, which included the term “open source”. We defined it as:

Open source refers to a philosophy of collaboration whereby others (publicly, or within an organization) are encouraged to fork, modify, discuss, and contribute to an ongoing project. Open source software refers to software with source code that has been made available to others.

For me, that’s always been what open source is. It’s a collaborative model, not a set of freedoms or political philosophy, and when you describe open source to non-developers, you don’t lead off by talking about the right to fork or copyright assignment. Apparently, however, such a viewpoint is the minority.

Open source as permissionless modification

Karl Fogel on producing open source software, and whom I admire greatly, corrected, in a series of emails, that since its inception, open source had always been about the right to modify, not the right to contribute.

Open source refers to material (often software) released under terms that allow it to be freely shared, used, and modified by anyone. Open source projects often, though not always, also have a highly collaborative development process and are receptive to contributions of code, documentation, discussion, etc from anyone who shows competent interest.

That struck me as odd for a few reasons. Granted, I have a somewhat skewed viewpoint, but it exposes an important edge case. Especially in government, we see the source code for an application being made available, but with no intention of (or often mechanism for) the agency to accept community contributions, an arrangement that many today would not traditionally label a truly open source effort.

So which is it? Is open source about the right to modify or the opportunity to contribute? When you look at the state of software when the open source movement was shaping its philosophy, the world was a much more centralized place. You needed certain rights enumerated, mainly because they weren’t the default.

Open source in a less license-centric world

I’ve only known a world where open source has already won. When I think open source, I don’t think “is this thing licensed under a Open Source Initiative blessed license?” Today there are increasingly fewer debates over the freedoms one receives with software, and more over seeing it released in the first place, or once released, over exposing process.

Developers today could care less what the license is because it makes good business sense, not because of the freedoms it brings.

There are a lot of reasons for that deemphasis. For one, technology has made it easier to work together than alone, shifting the supply-side constrains from projects to contributors, and in turn, has shaped what it means to be open source. As Karl noted:

Pretty much all open source activity (whether software or otherwise) happens online… if it’s not online, it’s hard for it to be effectively open source, practically speaking.

But among the biggest reasons for this shift, I’d argue, is that unlike when the open source movement was originally taking shape, today, there is no “source” and “binary” distribution to drive a wedge of imbalance. With web-centric, high-level languages like Ruby, Node, and PHP, it’s really hard to distribute the software in such a way that you don’t have everything you need to modify it, at least not in terms of code.

Open source software

Today, the idea of open source as it is seen outside of software is much more than just rights to “source code”. What happens when there is no source versus binary? What does open source data look like? Open source content? Open source law? What happens when there is no OSI-approved license, because the thing I’m sharing simply isn’t code. In trying to distinguish open source from open source software, I argued:

Open source is more than just publishing. Seeing how the sausage is made is necessary but not sufficient. Discussions in the open, ability to fork and modify, pull requests… collaboration is a key.

Think about it in this context: I’m a government agency, and I publish a plain-text blog. Is that open source? As a government work, you have the right to use, fork, and modify the “open source” content as you see fit. Same with government data in the form of a spreadsheet. The “source” in both cases… what’s necessary to rebuild the final intrinsically valuable thing from scratch is not the compiled letters or figures that are published, but exposing the underlying process through which that final product can be recreated (not to mention being the canonical place where the content is published).

So long as the publisher doesn’t provide a mechanism to receive those improvements, or if there’s a sufficient imbalance of information between those publishing and those contributing, that thing, be it code, text, or data, is simply published. It’s not really open. In software I’d call that “disclosed source”. In government, we call that publishing a PDF or simply throwing data over the firewall, but the one thing I would not have called that is open source. But given the right license, that’s exactly what it is.

Open source behind the firewall

The way I’d been using open source differed from the traditional definition in a second distinct way: scope. For me, open source wasn’t absolute.

Open source ≠ public. A project can be open source, even if not everyone has access to the code. You can open source within your organization, within your team, with your friends, so long as the philosophy is there.

At GitHub, we like to think of GitHub.com as working like an open source project. We use GitHub to build it, anyone in the company can see the source code, open an issue, or submit a pull request. In all senses of the word it’s open source, except not everyone has access to the code.

That begs the question: What percentage of the world needs to have access to something before we can call it open source? 90%? 51%? What if I print out the source code and make it available via snail mail to anyone who asks? What if I don’t tell anyone that that’s an option? What if I send the source to ten friends, and then leave a copy on a flash drive at the south pole? The list goes on. Rights are nothing without workflow.

The case for open collaboration

There is no such thing as “government-only” or “academic-only” or “within-our-company-only” open source

I think that’s true. At least, the idea of someone calling something “government-only open source” scares me. But what do we call the millions of developers that adopt open source workflows for their closed-source software? For non-software collaboration? How do we divorce ourselves from a rights-centric viewpoint and the holy wars that go with it (I’m looking at you GPL)? What do you call something that’s developed in the open with community involvement that may or may not be software?

Dropping “software” from “open source software” isn’t enough. Open source (software) since its inception, has always been about an external supply of freedom — the promise (or threat) that I am granted sufficient rights by the project creator such that I can, at any time, fork the project and go my own way — and it should stay that way. That’s exactly what open source is, despite me using the phrase incorrectly for years now. Put another way, open source software solves for modification, not contribution.

Perhaps what we need is a new word that better describes what we’re really doing. @haacked, but for me, that implies a hub and spoke model with a highly centralized power structure, not the egalitarian and decentralized web we often think of open source to be. Perhaps what I’ve been calling “open source” about all along is not really open source, but is in fact “open collaboration”.

Open source (software) is a thing we make. Open collaboration is how we make it. While the necessary elements for true open collaboration have, at least in my opinion, not yet been fully hashed out, one thing’s for sure: as the collaborative workflow originally created for open source software becomes increasingly co-opted by contributors to other, non open source projects, we’re about to see a lot more open collaboration begin to emerge (although not necessarily open source).

For a much more in depth discussion with @kfogel.

results matching ""

    No results matching ""