The thing I can certainly agree on is, that the SFML Team has missed many opportunities by not being active enough and not planning enough for SFML 3.
Beyond that, SFML has been doing quite well and my opinion the most important key to that was, ease of use and
stability.
You can take any example you find out there, build it and run it with the latest SFML version. Maybe you find some deprecated functions, but that's it. If SFML had small API changes every release, it would make it a lot harder to notice the changes, find the alternatives and each code example you find will be forever fixed to a specific version.
You're right that there was certainly some thoughts about potentially attracting more "companies", it was in my memory never just about this, but mostly about stability, about knowing that if I use SFML 2, I use this API.
Having been involved or just observed a lot of discussion on how to make SFML's development better, I have yet to find something that is really better than what we have right now. People wish to take shortcuts, but don't consider the costs of these shortcuts.
- "Less API discussions": This is really the core of SFML. Everyone who ever used SFML will tell you how easy the API is to understand and use, and how well it's documented. We're holding us to higher standard than most libraries out there and good API doesn't just "happen", but it's meticulously crafted through... discussions.
This also directly plays into the previous point of stability. Having a stable API makes you spend more time on discussing a good API and not just something that "I need right now" or "that fits my use case". It's a painful process and unfortunately many devs have no patience for it, leaving us with a pool of bitter devs because their idea, wasn't immediately implemented, more on this later.
- "Merge things quicker": This is a point many simply stop at "if things get merged quicker, the development is faster" and don't consider any consequences this has.
I agree that master doesn't have to be super stable, that master can contain bugs, but I don't agree in the idea that if we merge untested or not fully implemented features and bugfixes down into master, that we will be able to develop quicker. When your code ends up just one big pile of spaghetti from various half-finished features and bugfixes that made things just worse, it becomes an maintainable mess.
Cool, your feature got merged already, but who is going to go in and merge all the mess that it created? Many devs have provided or demanded something only to immediately vanish afterwards.
Having bugs and features clearly separated in branches, it allows us to work on them, review them, break them and test them independently from each other and if a developer doesn't have time right now to continue, a branch can be stalled and doesn't need immediate attention due to it breaking stuff on master.
- "More planning, more roadmaps": As my opening statement said, I do agree that more should have been done earlier. At the same time, I don't really see much activity in that regards. I've started a
SFML Development sub-form with
many topics to discuss. The participation is been quite thin and I haven't gotten any requests for discussing a new/next topic, nor has anyone else of the SFML Team felt the need to start a new discussion.
Besides that we have the
GitHub milestone showing what is more or less planned for the current release. We also have a
GitHub project that shows some more of the current status of tasks.
My response to an outcry of "there's no focus", I've
created a thread on what our current focus should be. I've even made it available on IRC, Twitter and Reddit, but the influx of participation is still missing.
Planning and roadmaps only help and work, if there are actually people willing to participate and move things forward and not just sit on their own topic, complaining why it's not being taken care of.
I'm sure there are some more ideas people have mentioned, but I currently can't think of anything more.
This brings me to the topic of participation.
Again I need to preface that the SFML Team is a bad example of participation and engagement overall. I do know that, but since there's no money involved, there's no way to make people move, right at the time when you want them to move.
However, there are also some archtype of people I see and who don't help the community in the long run.
- "I demand feature X": Luckily this has toned down quite a bit, but you'll see them every now and then. Someone runs into a problem with their game/application and since it would so nicely fit them, if SFML did the work and implemented what they wanted, why don't we demand this feature.
Often quite agressive in tone, with no real use case beyond "I could use it", they post on the forum. We start asking questions, ask about use cases, ask about considerations, ask about why this would fit SFML, why it couldn't be done differently.
But since the user just wants the feature, without actually doing any work or answering questions, they take the questions as attack, they get angry and if they are young, they'll go on some other forum or chat and tell them, how bad the SFML Team is and how they can't even add a simple feature and that's the end of the story.
Long story short: If you make a feature request, we expect you to invest some time as well. If you're not willing to do so, the feature request will just die, as there's a lot of other things to do with higher priority.
- "Here's a feature, plz merge": Providing implementations is already a good step, but it's really just the first step. If you wanted to implement that feature anyways and just thought to share it with upstream, then that's fine and we really appreciate it, but your expectation then can't be, that it will just be merged without any considerations or discussions. And discussions mean, you as a contributor will be involved too.
If you don't engage in discussions or check for current status when there's no obvious progress, you shouldn't be surprised when something doesn't "just happens" to get picked up and given the final touches. If our backlog was empty and that was the only thing in it, then sure, that certainly would be strange, but there's always more to do, than we have the people to do it.
- "I can't believe X hasn't been implemented yet!": Do we like that there are issues or feature requests that are multiple years old? Of course not! But sometimes it feels people are just disillusion, thinking that we have nothing else going on, than to work on SFML and fix everything.
But more importantly, by just stating your astonishment or even being sarcastic about it, doesn't help fix the problem. We're not different from you, beyond that we decided once up on time to really invest a bunch of time into SFML. Get down from your high horse and get your hands dirty by starting discussions, by suggesting implementations, by doing implementations, by testing existing implementations, by fixing existing implementations, and so and so forth.
Don't expect the SFML Team to do all the work for and don't think your snarky comments will motivate us to work on something, it in fact is more demotivational.
- "My PR isn't moving forward!": This can have many origins and it's often our fault for not moving forward on something in time. But at the same time, I also see many PRs of people, who vanish after a while, only to come back and complain about it angrily.
Sometimes it happens that a PR might just slip off everyone's mind and nobody went through the backlog in a while to check. Just make yourself heard, ask for feedback, potentially provide more information or some example code. Don't be annoying though, asking for an update every day or even crazier multiple times a day, won't get you anywhere and might get your PR locked for further comments to stop the spam.
If your PR ends up in the review and testing state, it doesn't mean, only the SFML Team can do this. If you review the code of some other PR, you're comments will help find issues and it will often makes things get merged quicker. Again, misuse of this, by simply approving every single PR, will just destroy your reputation and not help anyone.
Also testing your own PR is a good idea. Write a minimal example, make it available to everyone. If you're on Linux, maybe try a different window manager or maybe a different distro. Ask someone you know has the same issue or is excited about the same feature to help test the code.
Testing is one of the reasons many PRs stall for a long time. If nobody can tell me that the code actually does what it's supposed to do, I can't just merge it and hop for the best.
Anyways, I think my post has grown way to big and I've repeated things many times in the post itself and from previous similar discussions.
Summary
Just making the API "anything goes", doesn't guarantee more contributions, it doesn't just solve the current issues and opens new challenges in such a way, that I don't see the benefit beyond "it looks good on paper".
What I like to see is a more engaged community, which discusses important topics, writes code, reviews code and tests code. Not just their own code, but everyone's code.
What I take away for myself is:
- Take less about what can't be done and more about what needs to be done first to get things done.
- Start planning more intensely what needs to happen to get from here to SFML 3.
- Be more active and less reactive.
PS: For everyone who has missed it, the
unstable branch has already work done towards SFML 3 and C++1y support.
