Should we require that open source is developed openly?

No readers like this yet.
open source button on keyboard

Opensource.com

Roy Tennant wrote an interesting post about the definition of open source, in it he says:

"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."

Of course I went out to re-read both the open source and free software definitions so I could prove him wrong...but I can’t. He is right, the definitions of both free software and open source software say nothing about being developed in the open, but as those of you who have attended one of my workshops (or read my book) know, I disagree.

KohaCon12 Conference

A true open source project should be open in every way. The source code of course, but also the development processes. It is only with true transparency that you end up with a successful, stable and secure open source product. Whenever companies talk about why they choose open source software they focus on the transparency around both the software and the development of the software and how that transparency adds to the value of the software.

An open source project with one developer or one closed group of developers will eventually fall prey to the failures of proprietary software. Eric Raymond says, "Given enough eyeballs, all bugs are shallow"—I’d add that if those many eyeballs aren’t an ever-changing, ever-growing community then eventually bugs will become indistinguishable from the rest of the code. Maybe that’s a bit dramatic—but the fact is that one of the value added benefits of open source is that the software can live on and on. If, however, the software is developed by one person or one entity and that sole contributor decides to stop contributing, chances are their software is going to die...whereas an open source product with a community behind it will live on forever and ever.

Roy also says:

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.

While I don’t think I’m a 'near-religious zealot' when it comes to open source, I am one of those people who adds community and open development to the definition of open source and I have found that it helps many people when evaluating products available to them. I always say that an open source product without an active open development community behind it has more of a chance of disappearing than one with open active development, but if the product does what you want as it stands now then go right ahead and use it (I have a few of these types of products which are no longer supported or developed on my computer in fact). Without this warning, people would choose the first open source option they find and then complain to me (or to their colleagues) that it doesn’t live up to the hype.

So, yes, Roy is 100% right in that the definition of open source in no way implies or requires open development, but in my opinion it very much is keeping with the spirit (and success) of open source to make sure that your open source project is developed in the open. 

Originally posted on What I learned today..., reposted using Creative Commons.

User profile image.
Nicole C. Baratta (Engard) is a Senior Content Strategist at Red Hat. She received her MLIS from Drexel University and her BA from Juniata College. Nicole volunteers as the Director of ChickTech Austin. Nicole is known for many different publications including her books “Library Mashups", "More Library Mashups", and "Practical Open Source Software for Libraries".

2 Comments

I'm not sure I agree, at least not regarding the early stages of projects. IN my experience, software, like any creative endeavor, does not lend itself well to "design by committee" - maybe by small teams, but not large groups.

In later stages, once initial core concepts have gelled into into an initial release, opening up the process can be valuable - design review, finding bugs extending, support, .... But, it strikes me that the early phases require concentrated focus by at most a tiny team of designers.

There's a lot of history to back this up - the most successful open source projects I know of (Apache, Sendmail, Linux) started out as small projects that were open sourced after they'd reached a basic level of maturity. The same is true in the protocol world - TCP/IP, for example, started as a collaboration between Cerf and Kahn - the RFC process, "rough consensus and running code," multiple implementations came next.

Also think that they could benefit from close source in the early stage. Or else big companies could easily use their ideas and no one would ever know about the initial developers, that had the spirit but not the money.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.