June 21, 2018

Open Source vs. Openly Developed Open Source

I received an interesting message the other day from a colleague writing about a software development project: “They say they adhere to open-source, but their software is not developed as an open-source project and they do not have a community of developers that contribute.” This caught my eye because I have noticed this as well — open source projects that are not developed in the open.

According to the Wikipedia definition of “open source,” this appears to defy the very definition of open source:

The open-source model includes the concept of concurrent yet different agendas and differing approaches in production, in contrast with more centralized models of development such as those typically used in commercial software companies. A main principle and practice of open-source software development is peer production by bartering and collaboration, with the end-product, source-material, “blueprints”, and documentation available at no cost to the public.

Unfortunately, I think the term “open source” as it has come to be understood through the near-religious zealotry of some advocates has clouded our terminology more than clarified it. “Open source” should mean exactly that and nothing more — the source code of the software is open, thereby allowing others to see it, understand it, and perhaps modify it. How the software itself is developed should be an additional aspect to the terminology, such as “openly developed open source.”

Such a distinction would then make it clear whether the open source software is developed with a “centralized model” or with an open and inclusive development process, where the code is in a revision control system such as Github and others can submit code changes to the trunk.

There may also be yet other aspects of “open source” as it is currently defined that should be separated from the term, to help provide more nuance and clarity. Otherwise we run the risk of assuming too much when someone says “open source”.


Roy Tennant About Roy Tennant

Roy Tennant is a Senior Program Officer for OCLC Research. He is the owner of the Web4Lib and XML4Lib electronic discussions, and the creator and editor of Current Cites, a current awareness newsletter published every month since 1990. His books include "Technology in Libraries: Essays in Honor of Anne Grodzins Lipow" (2008), "Managing the Digital Library" (2004), "XML in Libraries" (2002), "Practical HTML: A Self-Paced Tutorial" (1996), and "Crossing the Internet Threshold: An Instructional Handbook" (1993). Roy wrote a monthly column on digital libraries for Library Journal for a decade and has written numerous articles in other professional journals. In 2003, he received the American Library Association's LITA/Library Hi Tech Award for Excellence in Communication for Continuing Education. Follow him on Twitter @rtennant.


  1. I agree this is a distinction worth making, and further to this I think that projects that are not developed in the open have a higher risk of becoming abandonware. I made a similar point in this project report http://www.jisc.ac.uk/media/documents/programmes/institutionalinnovation/telstarfinalreportaug2010.pdf :

    Releasing a software product as Open Source is different to running an Open Source project, and this could mean that the community around the product is not self‐sustaining.
    Recommendation 3: JISC and HE Institutions should consider the difference between Open Source software and Open Source and Community Source software development methods, and consider how the latter approaches can be encouraged alongside the release of Open Source software products.

  2. Centralized model of development vs distributed collaborative development is something to look at, and I agree it’s a different axis — I think both can be equally ‘open source’, in both letter and spirit.

    What I worry more about are people who say their product is ‘open source’, but don’t actually distribute the code publically at all. Say, there’s no way for anyone other than a customer/member to get a copy of the source. This is something that has actually happened with software being advertised as ‘open source.

    Or, if the source is distributed as a snapshot in a zip file from time to time, but they don’t have public access repositories with the real current code in it; that may or may not violate the letter of a given open source license, but I’d say it violates the spirit.

    When I think ‘open source’, I think about, well, the source being open. The source should be public to anyone, and anyone should be able to use it and make derivative works based off it. (Yes, there are all sorts of edge cases and technicalities, but as a general rule). If that’s true, and that’s true not just technically but it’s reasonably convenient and easy to do — then I say it’s open source. If it’s not, I worry. But I think open source certainly accomodates projects with only one developer, or one co-located team of developers, as well as projects with distributed collaborative networks of developers.

  3. You could cite some of the “is Android _really_ an open source project?” discussions that happened over the past few years, as it feels like you’re covering some of the same territory.

    Where I think some of the expectations differ is that “open source” is often used as a modifier for another noun, such as “project”. If you mention an “open source project”, then I believe that that often conveys an expectation beyond simple licensing discussions (hah!), to an expectation that an open source development model is used by that project to create its software. An open source development model typically consists of some combinations of meritocracy, transparent communications and source code repositories, etc, and that’s where the Android “throw the code over a wall with an Open Source Initiative-approved license” development model came into question.

    But sure, “open source”, when used as a complete phrase to refer to some piece of software, is technically a simple matter of the source code being available under an OSI-compliant license.

  4. Yes, open source just means the source is available.

    Open source development, on the other hand, tends to incorporate a bunch of philosophies prevalent in any modern software development, including The Hands-On Imperative, Release Early and Often, Iterative Design, Many Eyes Make All Bugs Shallow, etc. Also, open code lends itself well to the Gift Economy, via the back-and-forth exchange of knowledge, and places a high value on one’s ensuing reputation in the developer community. Tools like GitHub are awesome because they make all of this easier.

    I think the difference is not well defined because open source code without open source development is generally so much less useful for everyone involved. Good code is about process, not product. None of this stops some organizations who don’t “get it” from putting a tarball on an FTP server in order to generate open source cred.

  5. Ted Lawless says:

    A good example for this discussion is that the source for all the various Amazon Kindles can be freely downloaded from Amazon’s site. These certainly weren’t developed in the open but are open source.

    “In accordance with certain free and open source software licenses, Amazon is pleased to make available to you for download an archive file of machine readable source code (“Source Code”). ”


  6. A counter to this, though, is how IndexData works. There is no source control repository that the general public can look at, only releases.

    At the same time, saying that IndexData is violating some principle of open source is absurd. They have a company that makes products, most of which they freely provide the source code for under an OSI approved license.

    But at the end of the day, they are making projects that they want to control the ultimate direction of. You are free to take the work they’ve done, fork it, and take it in a completely different direction if you want, but I think it’s reasonable to expect a company to maintain control of the project how they feel is best for the company’s interests.

    Can they do this with an open development model? Sure. It’s a matter of what the priorities and focus are, though.

    I think you could find countless examples of openly developed FLOSS projects that fall prey to the opposite problem, as well.

    I think if a project effectively responds to user needs and stays focused on releasing a quality product, it’s hard to argue with their development model.

  7. Ross, I don’t think we disagree at all. IndexData produces great open source software and no one can argue with that. But what they do is categorically different (not better or worse, but different) than openly developed open source. I’m just arguing for nuance in our terminology — especially since folks like Richard Stallman have some fairly strict definitions for their use of “open source” that I doubt allows for work like IndexData does.