-
Short story: first of all, I'm here because Nao invited me to join.
Long story:
Many, many years ago, I was semi-active in the SMF community and released a theme for SMF 1.0 (yes, one point zero :) ) Later, I became occupied with other open source projects and basically stopped doing stuff for SMF, but my own forum was always running with SMF - many years with 1.0.x and I never bothered upgrading to 1.1, mainly because I had no time and 1.0 was working fine. When 2.0 became apparent, I decided to port the SMF AQUA theme I'd released years before for 1.0 but quickly lost interest after seeing all the bad things happening over at the SMF community. At this time, SMF's future didn't exactly look bright, so I stopped my work on the theme - nobody really wants to invest lots of time into a project threatened by extinction :)
About a year and a half later...
About 2 weeks ago, I started to play around with the 2.0 code base, realizing that it's now BSD licensed and there is no longer the risk of a dying project. Code is out, open sourced and this will never change, so it's safe to use it as a base.
I started with some work on the curve theme which I plan to rewrite completely, aiming for modern browsers (= HTML 5, jQuery, CSS3, IE8 minimum) adding a few Ajax features and a couple of relatively minor features.
Right now, I cannot exactly say which direction it will take. For the first part, it will stay closer to the SMF code base than Wedge, simply because I fear I don't have enough time for major changes in the core. Maybe later...
I plan to concentrate mostly on the end-user experience and adding a few (small) features of which I believe should be part of the core.
For the curios: Forum is here(http://forum.miranda.or.at/) and it always runs on the current code, so it may change and break on a daily base and sometimes it may not even work at all. Since the forum is not very active (most of the old support boards for my other open source project(s) are now read only for quite some time and only there for reference), I can break it whenever I want :)
So yes, this is another project that qualifies as a SMF fork and it was only a couple of days ago, when I became aware of Wedge after Nao joined my site. We quickly figured that neither myself nor him knew about each other's project and I was a bit surprised for how long yours already exists.
-
Hi there and welcome :)
-
It is great to see that another enlightened SMF Fork is in the works. Kudos for your efforts :cool:
-
I say why not? If you've got the time on your hands and you want to do it, nothing is stopping you. In a worst case scenario, you might learn something!
-
I have heard a rumour of a third fork, but I have yet to see anything that validates the rumour, even though I went to the site in question to see if I could find mention of it.
Not going to comment on it, though, don't want to raise more hackles, so to speak.
-
JBlaze has in his git account a folder for a SMF fork...
-
Short story: first of all, I'm here because Nao invited me to join.
Long story:
Many, many years ago, I was semi-active in the SMF community and released a theme for SMF 1.0 (yes, one point zero :) ) Later, I became occupied with other open source projects and basically stopped doing stuff for SMF, but my own forum was always running with SMF - many years with 1.0.x and I never bothered upgrading to 1.1, mainly because I had no time and 1.0 was working fine. When 2.0 became apparent, I decided to port the SMF AQUA theme I'd released years before for 1.0 but quickly lost interest after seeing all the bad things happening over at the SMF community. At this time, SMF's future didn't exactly look bright, so I stopped my work on the theme - nobody really wants to invest lots of time into a project threatened by extinction :)
About a year and a half later...
About 2 weeks ago, I started to play around with the 2.0 code base, realizing that it's now BSD licensed and there is no longer the risk of a dying project. Code is out, open sourced and this will never change, so it's safe to use it as a base.
I started with some work on the curve theme which I plan to rewrite completely, aiming for modern browsers (= HTML 5, jQuery, CSS3, IE8 minimum) adding a few Ajax features and a couple of relatively minor features.
Right now, I cannot exactly say which direction it will take. For the first part, it will stay closer to the SMF code base than Wedge, simply because I fear I don't have enough time for major changes in the core. Maybe later...
I plan to concentrate mostly on the end-user experience and adding a few (small) features of which I believe should be part of the core.
For the curios: Forum is here(http://forum.miranda.or.at/) and it always runs on the current code, so it may change and break on a daily base and sometimes it may not even work at all. Since the forum is not very active (most of the old support boards for my other open source project(s) are now read only for quite some time and only there for reference), I can break it whenever I want :)
So yes, this is another project that qualifies as a SMF fork and it was only a couple of days ago, when I became aware of Wedge after Nao joined my site. We quickly figured that neither myself nor him knew about each other's project and I was a bit surprised for how long yours already exists.
I made the mistake of having your Aqua theme on my SMF 1.x forum years ago and having to leave it behind with the 2.x RC upgrades...it's still a running joke on my forum that if I really cared about the users I'd bring the Aqua theme back. So if you could make that happen someday, it would save me some grief.
-
Welcome to Wedge, Nightwish :)
Hey, following your suggestions on your forum, I became quite obsessed today with getting the best possible PageSpeed number...
So I went ahead and wrote that friggin' smiley CSS cacher!
Heck, it was harder than expected, *and* it doesn't work perfectly yet (post editor is screwed up). But pages show smileys as expected etc.
It really saves a lot. I went from 65 to 85/100 on the online tool (for my topic page), and in the Chrome extension, it jumped to 98/100!!! W-O-W. I think SEO guys are going to like me. And us. :P
-
Hi :)
Very nice looking site.
@Nao
We always love you :D wtf 98 ? ...
-
Hey, following your suggestions on your forum, I became quite obsessed today with getting the best possible PageSpeed number...
So I went ahead and wrote that friggin' smiley CSS cacher!
Heck, it was harder than expected, *and* it doesn't work perfectly yet (post editor is screwed up). But pages show smileys as expected etc.
-
Nice to see you're still active to some degree!
I made the mistake of having your Aqua theme on my SMF 1.x forum years ago and having to leave it behind with the 2.x RC upgrades...it's still a running joke on my forum that if I really cared about the users I'd bring the Aqua theme back. So if you could make that happen someday, it would save me some grief.
-
Now convert the post and topic icons into CSS sprites (or something equally efficient) and you might reach 90, but once you don't see any more red or yellow suggestions you can stop. Trying to improve on the green ones is usually not worth the hassle.
Post icons: you mean the action icons...? They're already CSS-compressed. :)
-
Topic icons: usually there's only the default icon...
-
JBlaze has in his git account a folder for a SMF fork...
@Pete> Oh, please share the juice about other forks :P
Posted: August 11th, 2011, 12:01 PM
What happens if users add them themselves? (It's in the admin panel, even if it is convoluted.)
When it comes to smileys, the cache is automatically rebuilt when changes are made to the smileys (order, additions, ...)
-
@Pete> Oh, please share the juice about other forks
When it comes to smileys, the cache is automatically rebuilt when changes are made to the smileys (order, additions, ...)
-
I meant message icons, not just smileys; both are configurable.
-
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... :)
-
I meant message icons, not just smileys; both are configurable.
-
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.
-
You can be sure that other devs will be looking to use and build on your good ideas.
-
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...
-
If you find good, reusable stuff in NightWish's fork, you'll be appropriating it, right?
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 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.
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!
-
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.
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...)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.
-
We're not talking about Git where people can commit and then a handful of overseers will apply their patches to the codebase.
And there are plenty of reports flagged as 'private' (and not only for security, if you know what I mean...)
+1 to the rest.
-
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,
And again, that is thanks to the ex-devs who asked for a BSD license change, that we can work on Wedge today. (Not surprising, finally, when you see that many of the ex-devs have precisely joined wedge.org... :^^;:)I'm a veteran, and yet I was never formally invited into the team. Please don't forget that when you consider the relationship between SMF and I. Not that I care about team membership or whatever -- no, what matters here is that we have a team that never showed me a single sign of support. After which, they ended up banning me, then removing all my rights, and finally censoring me. The team you are in, likes to play lightly with people's feelings. You should know that.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.
Posted: August 12th, 2011, 05:13 PM
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.
The rest doesn't matter. Details can be fixed later.Yup. I'd say that there are more private reports that aren't security related than that are.
-
- 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.
I can understand the commit limitations as one should be very careful in handing out these privileges, but making anonymous read-only access limited just doesn't make ANY sense to me for an open source project. A strategy never heard of before in the open source world.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.
Nah, really. It seems weird to me. I've been on a number of other open source projects and never really seen one where patches from community members were not welcome or in other words, where people didn't have access to the head branch or trunk code or whatever you name it.
If you're good enough, you can even get a patch into FreeBSD and this project is ruled by people who will reject anything that does not 100% fit their expectations and they have very high expectations and quality standards.
In most OSS projects, you can at least get a patch into review stage unless it fails the very basic checks/coding standards and looks broken at a first glance :)- 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...)
Is there anywhere a comprehensive list of bugs in the 2.0 release code base?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.
-
Really? They don't even allow anonymous checkouts?
they have very high expectations and quality standards.
Is there anywhere a comprehensive list of bugs in the 2.0 release code base?
nothing wrong with it as long as you don't tell anyone "we're an open source project".
-
I think the ex-devs were right to insist on the change to BSD. At this point in time, I think it will be a positive change for the SMF community and SMF. SMF's old license was chosen at the moment YaBB SE was becoming SMF, because of the team's concern over a real case of someone taking YaBB SE code, repackaging it without attribution, and including it in a for-pay package. It seemed like the best choice to the team at the time.
I know the move to an open SVN has been slower than the SMF dev team, SMF afficionados, or any open-source advocate, would like to see. That's a valid criticism. There is some cultural change required. It's one thing to be in favor of a BSD license. It's another to be used to working in a more open environment. And the SMF team is reluctant to store project stuff on "somebody else's server" because of issues from the YaBB SE days.
Change comes slowly.
-
It seemed like the best choice to the team at the time.
The difference is that we're still respecting the terms of the licence (unlike ttForum, which just did a copy/paste of every mention of YaBBSE name and copyrights) and we aren't just grabbing a bunch of mods and shoving them in (unlike SuperMod, we're implementing features ourselves from fresh)
You're right that change comess slowly, but how long does it take? Wedge is almost one year old, is that not enough time for example? It's like a standing joke about the old national railway here in the UK, showed reputation for punctuality wasn't the very best, so much so that they acknowledged it by changing their slogan to "We're getting there." with the intimation that they had every intention of improvement but never managed to deliver.
I'd love to see SMF adopt a stable development cycle and start on the long road back to being nearer the top of the list than the bottom, but it needs to show some signs of change, right now it looks as though development has mostly stagnated, the last commit that's referenced on Mantis is a month ago, and there isn't any indication of what 2.1 will look like. We've indicated where we're going, as has MyBB with 2.0, as well as XenForo's forthcoming 1.1, but I think SMF needs to step up and do the same.
-
+1...
-
Hopefully all the forks will add much rejuvination to all the projects.
Revolution not evolution is what it needs.
-
At the current point, even a small evolution would be a revolution from SMF ;)
-
SMF is at the point where there are bottlenecks.
To get past them needs re-writing from scratch.
-
You tell me :P
-
Yes. AHAHA!. This time around its me tell you and you fix!
KB calls Nao over*, "hey Nao theres an extra space in some random file, please delete."
LOL!
-
Eheh. Good times.
-
Those were the days.
-
Well technically I'm doing the same on your commits these days... Good thing i have commit access :niark:
-
And I did the same on SimpleDesk for others' commits. Though I think you do less on my stuff than the original SMF code...
-
You were surprisingly very keen and quick to adjust to my incredibly demanding standards, while being willing to overlook my occasional little blunders ;)
-
Your standards aren't actually that far different from mine, and there's no point in getting frustrated when people do make mistakes because people do make mistakes. :)
-
Yeah, the only detail is that it gets documented in the changelog for everyone to laugh at you...
Okay, I'm being paranoid, the changelog has something like 5 regular readers :lol:
-
I'm being paranoid, the changelog has something like 5 regular readers :lol:
-
A rough estimate based on feedback. :P
But it doesn't matter whether it is read or not. What matters to me is transparency.
-
Actually I only noticed the new revs topic a few days ago, and found it to be an interesting read - haven't read it completely yet though. Got me wondering why more projects don't do something similar really. It gives out an impression of continuing activity and let's you guys show off your ideas and the way you work together.
-
That's the spirit. :)
I couldn't live without that topic. I need it to keep a forum connection with my SVN commits, and Pete's. I would never check the SVN log otherwise, I guess... It's also important for me to correctly convey the activity behind Wedge. Sometimes I won't commit for a couple of days, and then suddenly come up with a huge commit. If you look at the commit dates, you'll quickly notice how regular I've been on the project. As the saying goes, "A commit a day keeps the troller away."
Oh, I have a feeling it'll be in my custom title in a second... :niark:
(We also maintain such a topic for the importer tool SVN, but it's a team private topic for now. Will be made public when we release the importer and if TE doesn't mind.)
-
JBlaze has in his git account a folder for a SMF fork...