“Freedom Summer of Code”

Freedom Summer of Code is a summer-of-code-style distributed collaboration for technology projects benefiting radical/progressive movements. Exciting idea.


(en) Riseup Labs is excited to announce the Freedom Summer of Code! We aim to advance critical movement technology projects and tools that benefit a wide-variety of radical social justice organizations and movements.


Modeled after the successful Google Summer of Code, the Freedom Summer of Code adds a radical social justice twist. We will be working with select tech activist organizations to generate interesting ideas as well as help people develop several projects over the next three months.

The [Freedom Summer of Code -> https://we.riseup.net/fsoc] aims to advance critical movement technology projects and tools that benefit a wide-variety of radical social justice organizations and movements; inspire developers to become more interested in directly participating in social-justice tech organizations; contributes back, for the benefit of all, to the free software world which sustains us while simultaneously honoring individual’s labor; increases the social ownership and democratic control over information, ideas, technology, and the means of communication; empowers organizations and individuals to use technology in struggles for liberation. We are developing software that is geared specifically to the needs of network organizing and democratic collaboration, providing new services that greatl enhance your security and privacy.

Consider this is a call-out!

To get started, think about how you would like to participate. Regardless of your technical skills, we need your help and have numerous ways to plug into FSoC:

* We want your proposals, dream big! Submit any and all politically important technology project proposals for and by the radical tech community! Individuals, or organizations, can submit ideas for what they would like to see done during FSoC. We will collect these proposals and put them online for potential programmers to check out.

* Interested organizations should sign up: we want your organization to join FSoC, to not just submit project ideas, but also be an organizational contact person who can act as a facilitator if your project/organization is chosen.

* Do you want to participate? Come apply to the program, submit an individual project proposal, and when the time comes, you can pick projects that you are interested in working on.

* We also need facilitators, you are encouraged to apply to help individual participants through the process.

To learn about what kinds of things we are looking for, how to submit a proposal, to sign up as participating organization/facilitator or to apply as a participant in the first FSoC, come visit the [Freedom Summer of Code site -> https://we.riseup.net/fsoc].


Can licensing make an API useless?

As I discussed in a previous essay, it’s the collaborative power of the internet that makes the open source phenomenon possible. The ability to collaborate cross-institution and develop a ‘community support’ model is what can make this round of library-developed software much more successful than the ‘home grown’ library software of the 1980s.

So how does this apply to APIs? Well, library customers are finally demanding APIs, and some vendors are starting to deliver. But the point of an API is that a third party will write client code against it. If that client code is only used by one institution, as I discussed, it’s inherently a more risky endeavor than if you have client code that’s part of a cross-institutional collaborative project. For all but the smallest projects involving API client code, I think it is unlikely to be a wise managed risk to write in-house software that is only going to be used or seen by your local institution.

The problem is if a vendor’s licenses, contracts, or other legal agreements require you to do this, by preventing you from sharing the code you write against the API with other customers.

On the Code4Lib listserv, Yitzchak Schaffer writes

here’s the lowdown from SerSol:

“The terms of the NDA do not allow for client signatories to share of any information related to the proprietary nature of our API’s with other clients. However, if you would like to share them with us we can make them available to other API clients upon request. I think down the road we may be able to come up with creative ways to do this – perhaps an API user’s group, but for now we cannot allow sharing of this kind of information outside of your institution.”

To me, this seriously limits the value of their APIs. So limiting, that I am tempted to call them useless for all but the simplest tasks. For any significant development effort, it’s probably unwise for an institution to undertake a development effort under these terms. That’s assuming that an individual institution even has the capacity tod o this–the power of internet collaboration is that it increases our collective capacity by making that capacity collective. Both that increased capacity and managed risk through a shared support scenario requires active collaboration between different institutions—even SerSol’s offer to perhaps make a finished product available to other clients “upon request” is not sufficient, active and ongoing collaboration between partners is required.

If I’m involved in any software evaluation processes where we evaluate SerSol’s products, I am going to be sure to voice this opinion and it’s justification. If any existing SerSol API customers are equally disturbed by this, I’d encourage you to voice that concern to SerSol. Perhaps they will see the error of their ways of customers (and especially potential not yet signed customers) complain.

Ross Singer notes that this is especially ironic when SerSol claims their APIs are “standards based” (http://www.serialssolutions.com/ss_360_link_features.html). What proprietary information could they possibly be trying to protect (from their own customers!).

Open source, support status, and risk management

Deciding whether to go with a particular open source product is an exercise in risk management. To be sure, let’s be clear—deciding whether to go with a particular proprietary product is also an an exercise in risk management. (And really, most organizational management decisions probably are, but what do I know, I’ve never been a manager and don’t have an mba).

Evaluating the risk level of an open source product is kind of new terrain for some in the library world. It is comforting to remember that there are some aspects of evaluation that really aren’t much different for open source software than for any other software — for instance, looking at whether the product has the features you need, and how well it works.

There are other aspects that need to be approached differently for open source. In this essay, I’m going to look at just one of them, that is cause for particular concern among some people — open source support models, how you get support for an open source product, what you are risking in terms of support with an open source product. All open source products/projects are not equal here. In trying to explain to others how to approach risk management related to support options in a particular open source product, I’ve found it useful to talk about three situations or statuses an open source project may have with regard to support. Continue reading “Open source, support status, and risk management”

More on open source

Another post I made to horizon-l. I am trying to be a rational (rather than propaganda-spewing) voice of pro-FLOSS. Feel free to let me know if you think I’ve mis-stepped in any direction.

Another member posted:

and it may be that your library administration
would never consider open sourcing your ILS....

To which I replied:

It is important to remember that Evergreen and Koha both have vendors who will provide commercial support. Realizing that an ILS with an open source license can also come with a support contract, I can’t think of any good reason for administrators to rule out open source ILSs as a class. That’s the real meaning of how open source and commercial can be “both/and”. Evergreen and Koha are both commercial software AND licensed under an open source license. .

Is there anything I’m missing about a rational reason to dismiss open source as a class, to specifically reject software that’s licensed under an open source license, preferring software that is not?

Now, just because there may not be any reason to reject open source as a class, that doesn’t mean that any particular existing open source licensed ILS is right for you. The way you evaluate it is the same way you’ve always evaluated software, some particularly pertinent criteria in this case include:

1) Total cost of ownership, naturally. Your support contract for the open source licensed ILS being evaluated, plus hardware, plus if the software doens’t yet have all the features you need/want, the cost to pay a vendor (or hire staff) to add them. Compared to total cost of ownership of your other (proprietary) options.

2) As with any product, strength and staying power of the vendor. While both Koha and Evergreen have vendors providing commercial support, you want to ask yourself the question, how financially and otherwise organizationally healthy are they? How likely are they to stay around for the long term? As you would with any vendor. (And the market has of course seen that there’s no guarantee of continued viability of vendors of proprietary software either).

There will be negatives and positives with any particular solution you evaluate, which have to be balanced against one another and against the other options. For open source or proprietary. Open source by it’s very nature comes with some more _potential_ positives—if the currently existing vendor _does_ go under or decide to stop supporting the product: a) You can still keep using the software as long as you want without permission from anyone (that’s the nature of open source) b) Another vendor(s) can spring into existence to support and/or further develop the same product, without any permission from anyone, with full access to the source code (if not neccesarily the institutional expertise). Another unique possibility, if the open source ILS market continues to develop, is that there could

Many of these unique benefits to open source are just _potential_ in the ILS market at the moment, there are no guarantees—if you don’t want to consider these potential benefits yet, you don’t have to: You can evaluate open source ILS options head-to-head with proprietary options, without giving any weight to the potential unique benefits of open source. I think Koha and/or Evergreen are quite possible to still come out looking good in such a comparison.

But when you undertake the difficult calculus of evaluating what software is best for you among a collection of non-perfect options, I don’t see any reason to exclude open source licensed options from consideration altogether.


Open Source Isn’t Free, but that’s not a problem

Or: There’s no such thing as a free lunch, but some meals are still better than others, even on a budget.

The horizon-l list has rather incredibly turned into “open source ILS for newbies” lately.

Someone posted [paraphrased, it’s a closed list] “I know open source isn’t free, despite what everyone says. We don’t have much in-house technical expertise, and we’re worried that the open source ILSs don’t have the feature we need from a mature ILS yet. What can we do?”

I replied: Continue reading “Open Source Isn’t Free, but that’s not a problem”