Re: Open Letters to the SMF Community
Reply #35 –
It might, if the principle contributors weren't still - by their own admission - involved with the original project. That, incidentally, is part of the perceived problem.
EDIT: I'd be quite happy to leave the bunfights behind, though I'd note this last discussion came out of a bunfight that didn't need to happen because of egos, certainly didn't need to happen here, because it should have been kept at sm.org since it was about critique of SMF not of Elk...
Re: Open Letters to the SMF Community
Reply #36 –
Arantor. You put yourself in that situation. Don't you ever blame anyone else for something you did entirely by yourself. (Leave a closed license project, decide to contribute to an open project, and then complain that people can take your signed off code and you can't take a single line of code that wasn't signed off.)
You do that, it's on you. Stop insulting my intelligence. Not only did we never take new features straight from smf 2.1 (and I have absolutely no plans to use any of your new features for it). But. Everyone that is not Wedge is in the same situation as you are regarding taking code from Wedge. You're a SMF developer with a clear intent to implement Wedge features and you have access to my codebase. I can't afford not to be protective of it. It's a time costing work (checking your SMF commits and posts) that you chose to impose to me. You're incredible!
Re: Open Letters to the SMF Community
Reply #37 –
You heard it here first, folks, Wedge ain't going under an open source licence any time soon. Because the minute it does, it opens itself up to the exact same issue.
Re: Open Letters to the SMF Community
Reply #38 –
You chose this license with me. You were quite happy with it. Then you chose to leave. And you said Wedge (half your work, shall I remind you) sucked. You really should get your act together. Either say things honestly or don't. Trolling isn't your finest feature.
PS. We always said Wedge would remain under that license until we both lost interest in it. Selective memory much?
Re: Open Letters to the SMF Community
Reply #39 –
A suggestion would be to make your repo(s) Private, then no one but whom you decide/invite would be able to see what you are doing.
Nothing in BSD requires you to have an open changelog, commits, etc. Just keep it hush and the only time the public or competition would get to view the code is when you tag it (for a release or a pre release). GitHub with that open repo was a test in many ways, if its not suiting the needs of the organization, or the complications are greater than any benefit, then there are several options for you to pursue other than a bunfight.
A private git repo or even back to SVN, would allow you to keep others away, you could still leverage code / features from other projects, it would prevent any early forking and/or rebasing, ie only SMF 2.06 could be forked until such time as you tag or provide an Alpha release. Heck you could even special license any early releases and not allow forks until a gold "bsd" release. And of course nothing says you have to remain open source for 2.1, although that may have some "complications" at this point so maybe 2.2 you close.
Anyway just some suggestions.
Re: Open Letters to the SMF Community
Reply #41 –
Thanks for your comments and I tend to agree with you on that, there was some discussion of de-stickying this, maybe even locking it at this point since it served its purpose long ago.