Re: Defining Open Source

Jeff Atwood has a post about the definition of open source with respect his contributions to the .NET open source ecosystem.

I’m really glad that he brought this up because it has been on my mind for a while and based on his comments I can see there is MUCH confusion. I’m not going to address the confusion between “Open Source” as defined by OSI (The Eric Raymond definitions) and “Free Software” as defined by GNU (The Richard Stallman definitions). The commenters should read up as there is much writing on the differences here.

The confusion that I realized only as recently as January at CodeMash is that there are a number of closed source project out there that release their closed source under an open source license. Before you call this nonsensical please consider their development model. The source repository is closed. There are no public developer email lists. There is no public discussion of direction and upcoming features and who is implementing new features or even who is fixing big bugs before the next release. The Project is closed. However, every 6 months or every so often the source code is released and when it is it is under an open source license.

I’ll refrain from poking holes at this and calling this an abomination of the spirit of open source. The two aforementioned big names of Free Software and Open Source have plenty of writing on why this might be bad. The reality is that these projects exist and they are what they are. The project which opened my eyes to this model is DotNetNuke. This is a closed project which releases its code under an Open Source license.

Contrast this project with any open source project such as Mono or CastleProject and look at the surrounding communities. The core developer community exists. You know who they are. You can read public email lists. You can even chat via IRC with the folks who write the software. You can file bugs and submit patches. You can, you can, you can. DotNetNuke on the other hand does have a thriving community but it is all around writing plugins. Yes, you could download the source to the latest DotNetNuke release and you could change it all you want, but if you implement awesome new feature X, there is no where to submit it. If you fix annoying bug Y, you have to email it to a black hole and hope that the patch you made against last release will merge with their current private trunk.

In my opinion it is important to make the distinction between Open Source Projects and Open Source Software. All Open Source Projects by definition are Open Source Software, but Open Source Software might be a closed project. If the trunk is closed, how open is the software really? I’d say it is not open.

Jeff made the distinction in his post and has said he will be giving to Open Source Projects and not giving to closed projects that release their source under an Open Source license. I think this is great. Jeff recognized the distinction and is voting with his contributions.

On a lighter note, I couldn’t resist the Simpsons Movie character generator. The blowfish shirt seemed the geekiest to me.

simpsons avatar

9 thoughts on “Re: Defining Open Source”

  1. Actually, DotNetNuke has a large number of different ways for the community to contribute e.g.

    For Large contributions (e.g. new modules) -http://www.dotnetnuke.com/Community/tabid/344/Default.aspx

    Getting involved in existing projects – http://www.dotnetnuke.com/tabid/824/default.aspx (note: often project team members who’ve demonstrated their commitment and contribution over a period of time go on to become core team members)

    Submitting/voting on ideas for future inclusion via the roadmap – http://www.dotnetnuke.com/Products/Development/Roadmap/tabid/616/Default.aspx

    issue tracker – http://support.dotnetnuke.com/Main.aspx (you can use the Public issuetracker to submit bugs, resolutions, enhancement request’s etc.)

    Blog posts about project and core status and discussion of upcoming features – http://www.dotnetnuke.com/tabid/825/default.aspx

    Project roadmap – http://support.dotnetnuke.com/project/RoadMap.aspx?PROJID=2

    Project changelog – http://support.dotnetnuke.com/project/ChangeLog.aspx?PROJID=2

    Project release tracking -
    http://www.dotnetnuke.com/Products/Development/ProjectReleaseTracking/tabid/997/Default.aspx

    In addition we’re looking into other ways to allow users to directly contribute, and constantly evolving the ways and means to get more of the community involved. Expect to see further change in the next few months.

    Cathal

  2. Cathal,
    Glad to hear it. Hopefully opening up “trunk” and the development process entirely will happen as well.

    Thanks for all the links to those great resources.

    Jay

  3. No, have to disagree with you there.

    Just because the current developers are being a bunch of asshats, that does not make the project not-open-source, or even non-Free.

    If you, as a user, have the ability to improve the program yourself, share those changes with others, etc…, then it’s open, and possibly Free.

    If you don’t like how the project is being run because the current maintainers are being asshats, then you can *fork* the project. You can create mailing lists and start accepting patches against the most recent released tarball, and try to create the community you want. You can say, I want features X, Y and Z here, and I’ve no idea if they’re going to be in the next release, so I’m going to try to write them myself. Does anyone want to lend a hand? You can set up a bug database, and everything else you want.

    And *that’s* the point of Free software. That’s the point of the freedom and the openness of the code – it’s so that you never *have* to rely on a particular bunch of developers. Heck, even if the current developers are OK *now*, that doesn’t mean they won’t turn into a bunch of asshats in the future. If that happens, as it did with XFree86, the fact that you have the code means you’re not reliant on the asshats to take the project in new directions. You can just take the last lot of code, announce your fork, create an open submission policy and start hacking.

    The projects you are complaining about are not “closed source projects”. They may be “closed projects” that release open source software, but the software itself, which is the most important thing, *is* open.

  4. Adam,

    I agree with you. But I don’t would make the distinction at that point between an open source project and open source software. The project isn’t open source at that point, but the projects releases are open source software.

    It is a fine line and maybe it is to fine to try to draw the distinction.

    I agree that the said open source software could be forked and developed in the open at which point it would then be an open source project.

    Yes, too fine of a line I think.

    Thanks for the feedback. Great example with XFree86. I was a reader of XFree86-devel when the split happened so I was witness to some of the closed activity that was happening. It forked in favor of openness.

    I’d also not call them asshats. It is what it is. The developers of a project are free to develop it in any way in which they see fit. It is their freedom. I just see it as less than optimal.

    Thanks again.

    Jay

  5. What is an “open source project”? The key words here are “open” and “source”, and the fact that the word “open” is next to “source” and not next to “project”. To me, the word “open” clearly applies to “source” and not “project” due to proximity.

    If you want to give a label to projects which act in a closed manner (e.g. a “closed project”) then do so, but to suggest that they are not “open source” is, I think, likely to spread more confusion than that which you are trying to clear up.

    If the source code is open, it’s open source. If a project releases source code under an open source license, it’s an open source project. If the project itself is not open or transparent, that doesn’t make the *source* non-open. It just makes the *project* non-open.

    So, call it a “[open source] closed project”, or a “[open source] cathedral project”, or something similar. But don’t put “closed” before “source”, as the source ain’t closed.

    “I’d also not call them asshats. It is what it is. The developers of a project are free to develop it in any way in which they see fit. It is their freedom.”

    Fair enough point. And I’d agree – it it any developer’s free choice to act in ways that I happen to consider asshattish, and I completely respect their freedom to do so. :-)

    Yeah, OK, I guess I didn’t actually mean to call any specific set of developers asshats. I was intending to use it to describe any particular way of administering an open-source project that someone might find annoying/objectionable. (Not necessarily limited to only having closed mailing lists/bug trackers/etc…) And to make the point that whatever it is you don’t like, if you don’t like it enough you can fork the project. Bringing in a concrete example was merely meant to strengthen my point, not to deliberately insult the old XF86 hackers.

  6. I think a better term for what you are trying to get at would be “Open Development” vs “Closed Development”. The term “Open Source” has a very well-defined meaning, which is controlled by the OSI.

    I think its perfectly fair for a project using a “Closed Development” model with a BSD license on releases to be considered Open Source. If people don’t like the development model, the license allows them to take the sources and do their own development their own preferred way. If enough people agree with them, the project is essentially taken over. That’s the point of Open Source.

  7. Thanks for the feedback.

    How about “closed trunk” and/or “closed development project” ?

    I like “closed trunk”, but its the geeky programming in me that likes this definition. “Closed development project” is more descriptive.

    In this case DNN would be a “closed development project” with “open source” release code.

    At this point I think the number of projects that follow this model are so few that the terminology doesn’t matter.

Comments are closed.