Brilliant. 
Thanks.
This thread should probably be stickied too. Once it moves off the front page there’s nothing to help new users, or anyone who hasn’t followed this conversation, avoid the same problem.
Speaking of volunteer work, not counting the programming interface, Inform 7 is written mostly in Inform 6, right?
…so anyone can contribute to an unofficial I7 update.
If my I7 Bugfixes entension ever get as large as five bugs, I’m going to release it to the community, and if I ever get around to completely overhauling the grammar system, then I think that would count as a small revolution for I7 upon release.
…but I’m far from the first to release an extension. Often the same problem is adressed by several authors. What Grahams updates do, is to make an official default to base things off of.
…so in a way, I7 is partly a sort of linux-like open source. If you really want things to be fixed, then instead of waiting another year, consider doing it yourself. The standard rules leave a lot to be desired, so if you’re telling me that you’re satisfied with your version of them, consider showing us your release.
I see some pros and cons to this: On one hand the community could end up splitting Inform into multiple I7 engines all claiming to be “Inform 8”, but on the other hand, if you allow Graham to blatantly copy your work for his I7, this could help Graham see what the community wants, and how it wants it done, cutting down on his development time.
“See what the community wants” should also go hand-in-hand with a more rapid release cycle where you can get immediate feedback on implementation. Inform is far from anything like that. I honestly question how much the developers of Inform really know about effective development practice. If it’s just this Graham guy – who I think I’ve seen engage with the community maybe twice – then that’s even more of a bottleneck.
I’ll be honest: I’m not convinced active development is taking place. I don’t doubt work is being done of some sort but I was told “look at the bug tracker” to see status, which makes sense. A visible bug tracking system does give you visibility into where a project is at. What I see is very little movement on resolved issues and lots of issues continually being added. When I brought that up once, someone told me: “Oh, don’t go by that. Graham often doesn’t update the bug tracker until the release goes out.”
Um. Ooookay.
Anyway, with bugs constantly going in then what that does is add to development time – assuming you try to fix them – which then leads to more regression testing over a code base that has now had multi-year development cycles applied to it. If you are also doing new feature development at that same time, you have painted yourself into a corner. It’s the absolute worst way to do development.
I don’t know. Maybe a ton of work is being done. But I believe what I can see, not what I hear about every year or so.
Bukayeva, your post would make more sense to me if this were a commercial project.
But it isn’t. Inform - in all its variants - has been a labor of love.
If Graham and his team are making any money off it, I’m not aware of it. After all, you can download I7 for free, you can develop in it for free, you can upload your extensions for free, and the development team doesn’t even ask for a profit cut, if you can figure out how to make a profit. There aren’t even ads on the site.
If Inform 7 were seriously broken, your post would make more sense to me as well. I’m working in a non-I7 system right now that’s in maintenance mode, and I’m struggling through some pretty frustrating bugs because I don’t have under-the-hood access and the owner is preoccupied with other things. Under those circumstances, I’m tempted to complain.
But considering everything, Inform 7 is shockingly unbuggy. I’ve been working in I7 since 2006, and I’ve come across a grand total of five bugs. One has been fixed, and of the other four, three were such weird edge cases that a commercial development teams would probably waive them. (What kind of weirdo changes the I7 font into Sibelius musical notation?)
The fact is, if Inform 7 were never updated again, then I7 would still be the premiere development system for parser-based interactive fiction, until someone creates something that is as great an improvement over I7 as I7 is over I6. And if you can design a system like that, then I’m seriously impressed, because I don’t even know what it would look like.
Andreas is right on the money here. If you’re bothered by a specific bug - you have access to I6 under the hood, just like anyone else. You can fix it yourself, or find a workaround. You could even contribute to the community by releasing your fix as an extension. That would be pretty awesome.
And if you’re bothered by specific bugs, and you don’t feel capable of fixing them, then you could bring your list to the I6/I7 folder. People in this community are great about helping each other - I don’t think I’ve ever seen an ask go unanswered there.
But complaining about the slow development speed is declasse, because Graham doesn’t owe the community anything.
Actually, rapid development cycles make even more sense when you do not have a commercial project.
None of that has any bearing on my point. I don’t deny all that. I’m talking about the nature of development cycles.
That may be your opinion. I may even be inclined to agree since I do think what Inform is attempting is very cool. Still has nothing to do with my points, though.
Sure. But what about the core features we’ve heard are changing? Why bother developing an extension that may rely on features that are going away or are being heavily modified? We have no insight in the actual implementation. We already have reason to believe that some extensions are going to be incorporated into the next release, such as custom messaging. So if I want to do stuff with that, why would I spend a lot of time dealing with that extension when it may be going away?
That’s the point, really.
When the development process and the feature cycle are opaque, it can be difficult to know if you are designing in line with how the project itself is developing. You can use the UserVoice forum to get some ideas of where the thinking is going, but none of that says where it actually is. And given that the communication over these multi-year cycles is pretty much non-existent, it makes it daunting to attempt heavy changes without feedback as to whether things are in line or not.
And, yes, I know Graham or whomever else does not “owe” us anything. I don’t know why people always say that as if it somehow makes an argument. What I’m talking about is simply my views on the development process as I see it. I don’t really care if someone else agrees, just as I’m sure they don’t care whether or not the development process is a problem for me.
The reason I feel this way at all is because I do think Inform is a very cool project and it’s a pity to see it hampered by what I consider to be a very inefficient development process. You keep talking about how good it is. Fine. I’m talking about how much better it potentially could be if the development process were opened up a bit more and the release cycle tied more to feature development with iterative feedback from the user base. I could be wrong: maybe that wouldn’t help Inform at all. On the other hand, it could make a huge difference. Problem is: it seems we’ll never know because no one wants to discuss the development process of Inform. And if someone is the least bit critical, you get the apologists telling you that you are not owed anything and should just be grateful.
I don’t think we’re going to convince each other of our respective views here, which is fine. 