Wedge

I have seen animated icons - and of course there are animated smileys, which I think would be pretty awkward for spriting.

CSS encoding is just as good anyway. Because it does The equivalent of a solid archive, you can keep your palette optimizations unlike in spriting. And it's easier to deal with. And can be regenerated on the fly. Win win situation. :)

Welcome! I hope you have success in your project and we can have a friendly competition... :)

That's what I said: I'm not doing topic icons for now ;)

Hello Nightwish!

Your fork looks promissing.  It is great to see the work you are doing. Every good idea is a benefit to the entire SMF community.  I'm glad you've made your work open source, too. You can be sure that other devs will be looking to use and build on your good ideas.

Good ideas are good ideas, doesn't require having been open sourced to use them. I'm just a bit sour about my ideas being reused at the moment.

Angelina, aren't you still a SMF teamie.......? Am I right in detecting some insinuation in your post...? :whistle:

No, Pete, I don't think you're sour about potential reuse of your ideas -- just about potential reuse by SMF itself. And I share your opinion on this. But Wedge (well at least me :P) is precisely very open to sharing code. Heck, I hope I won't have to spend my entire life guarding the Holy Source Code of Wedge. Its purpose is not to make us rich. It's to show what SMF should have been like by this point if they had developers with cojones. Why do you think Nightshade is here, and has a Friend badge? Because we're friendly to the SMF universe, including its forks -- just not to the team that has vblamer45 in its ranks. Not to the team that considers Akyhne a "friend". And not to those team members who respond to his requests to censor us, like Kindred... ::)

Yes, very true, I was just trying not to lose my temper a bit.

If you find good, reusable stuff in NightWish's fork, you'll be appropriating it, right?

I mean, that's the point of open source, right? That's the reason SMF went to the BSD license -- to encourage forks, friendly competition, building on others' work, and outright appropriating code from one another.  If it fits.  With appropriate attribution, in the spirit and letter of the license.

PS. Yes, show the world what SMF should be like. If it's good, it will inspire NightWish, the SMF team, and any other budding fork-writer.

I'm not a dev, Jim, I'm a doc writer.
I'm just saying...

We'll probably ask first and very likely implement it our own way anyway, rather than lifting the code wholesale.

I have privately also confirmed that I am quite willing for Nightwish to make use of one piece of code that interest has been expressed in regarding auto saving of posts.That's not all the reason it went to the BSD licence but that's water under the bridge now.

Here's the thing that's bugging the hell out of me: it is claimed that SMF went BSD to encourage friendly competition - yet that same competition is actively censored, friendly or otherwise. As I was explaining to someone else yesterday, we were initially very friendly, until we were lied to, insulted, and generally crapped on.

I'm happy to share my ideas, and some of them I have shared publicly, but I have no desire to give anything back to SMF after everything it's given me.

I'd like to see everybody get along, of course. But I know I'm not going to get everybody to see eye-to-eye, much as I'd like to.

Yes, of course, I agree that it is courtesy to communicate. "Hey, I love this bit, and want to use it". Whether the two devs are currently feeling "friendly" or not.  Courtesy. Civility.

I assume, of course, that anyone who has put a BSD license on the code has already explicitly expressed their perfect willingness to allow anyone at all to lift a function or class wholesale, as long as they follow the letter (and spirit?) of the license agreement. That's what the open source license is for.

I'm pretty new at SMF.  So I may be making some poor assumptions. I assume "everybody" knew the BSD license meant forking was inevitable, and healthy, and that SMF itself will benefit from what the the fork teams learn, and even from reading/using bits of open source code.

Good luck for your fork!

The idea, possibly. Probably not the code. Actually, I have yet to look into his own code so I don't even know if I'd see myself using it without a serious rewrite. But that's just me -- I rewrote a healthy chunk of the SMF codebase because it was sub-par with my (and Pete's) standards.That's the point of the BSD license, yes. But that's not the reason SMF went to it. SMF went BSD because it was sort of 'blackmailed' into it by the ex-devs. It just happens to be a positive blackmail.

But now, see how the current SMF team embraces BSD and open source in general.

- The SVN repository... Where is it? Well, it's viewable... By team members and beta testers. And writable by developers only. There are only a handful of people with commit access to the SVN. We're not talking about Git where people can commit and then a handful of overseers will apply their patches to the codebase. No, we're talking about the binary process of updating the codebase or not. Because the repository is private, users simply can't provide SMF with patches. As a result, AFAIK the only public codebase of SMF is Nightwish's repository.
Way to go, BSD SMF.

- The bug tracker... Again, only beta testers and team members can post to Mantis. Everyone can read it, but that's all (and even that was impossible until a couple of years ago.) And there are plenty of reports flagged as 'private' (and not only for security, if you know what I mean...)

- Nightly releases... Only for the same usual suspects. Not that it matters anyway. From what I heard, the SMF SVN hasn't been updated in a month anyway.

So, yeah, SMF doesn't like BSD. They only went BSD because they were required to. That's not the spirit.
Here at Wedge, we don't declare we have the open source spirit in us. We don't openly release things in BSD and then ensure no one gets our patches until we're ready to release.

We do the opposite, actually. We release in closed source, keeping our source code hidden for now. But once we're out, I'll do my best to ensure the SVN is made public for everyone to read and get our latest fixes (and laugh at our new bugs, of course!)
Look at the Changelog topic ('New revs'). It has a complete list of our additions to SMF.
Not only that, but it also faithfully documents every single SMF bug we met and fixed. If anyone in the SMF team will wake up and parse the changelog thoroughly, they'll have dozens of bugs fixed for them instantly. I'm not going to contact the team and offer my fixes for them, because they removed my beta tester access and all of my rights, clearly telling me they don't want my help. Their loss. But I won't let it be said that "SMF has embraced BSD and Wedge hasn't".
Because that couldn't be further from the truth.
We only used an infamous legal loophole in BSD licenses to ensure that SMF won't take advantage of us. Not in these conditions -- with censorship around, with the wrong people in the wrong team position... We'll see what happens from there, when things get better. But right now, it's the only way Wedge can exist. As such, it also doesn't allow other forks to use its own code -- but as you can see, we're open to sharing our trade secrets with them. Just not with the SMF team.

(I don't know how many times I'll have to repeat myself...)Considering how the SMF team doesn't want any outgoing links to wedge.org, do you really think they'd link back to us? In their own *software*?That's the idea.

I am given to understand that the plan is to move it onto Git in the future, but other things (outside of development, real life things) are in the way. Not so much that the people with the power are against the idea, merely that they haven't yet made it happen. But honestly, it's not a big job to convert, the entire thing can be basically automated.Yup. I'd say that there are more private reports that aren't security related than that are.

+1 to the rest.