Very interesting information! Thanks!

G’night

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.

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.

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.

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

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.

Thanks for all the links to those great resources.
—
Jay

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