Right. What I’m trying to do is figure out something that we might be able to accomplish without trying to put pressure on Graham to speed up or change the development of core Inform, because I think the team has made it pretty clear that Graham works in the way he works, and is aware of the bugs in the database, and that repeating ourselves louder about those bugs isn’t going to accomplish anything. This isn’t meant as a criticism of Graham or of those of us who would like more attention to be paid to the issues, but it’s one of those things where he has whatever demands on his time that he has, Emily certain has demands on her time and as she has said is spending time on a lot of IF community support that isn’t I7, and while we would all like to pitch in and help, it would be very demanding on Graham’s time to put things in a situation where we can. As zarf said, he wants to get the code rewritten, cleaned up, and documented–and that’s a ton of work.
(Aside: Some bugs seem to have workarounds or fixes that we can figure out ourselves, particularly in the open parts of Inform like the Standard Rules or I6 templates. Here’s one. We could make a repository for those, or an extension or series of extensions that fixes them, and if it were posted in a prominent place on the site it could be helpful. And then there are some bugs in the open part of Inform, like this, where we haven’t figured out a workaround, because the parser is really hard to figure out and/or the people with the wherewithal to fix it haven’t put a high priority on it. Which I think points to some of the difficulties in going open source–it’d take a lot of work to get the code into a state where lots of people could just up and solve a bug like this.)
What I read from Emily’s post was quite literally the classic frustration at a perceived lack of engagement and transparency. I see this all the time in my professional career. When there is a perceived lack of engagement, some people worry the project is “dead” or in “maintenance mode” and will be “abandoned”, regardless of whether there is a healthy user base. They perceive the so-called “Detroit Effect” – the gradual attrition of overall value due to the parts slowly becoming out of sync or simply not working.
Reinforcing that point, what I read there was a litany of issues, many of which are talking more about aspects of Inform 7 rather than Inform 7 itself. While I personally would still like it to be open source at some point, I don’t know if that would mitigate the issues being referenced in Emily’s post. Even the Skein thing mentioned: isn’t that more of an IDE function?
Yes, and the IDE is on github. Part of the issue is that the documentation has gotten out of sync with the IDE here (it still talks about the Skein and Transcript panels), plus it’s not clear exactly how the functionality for releasing along with a solution should work with the new IDE. This is one of the more irritating problems for people–but it seems to me that much of it could be solved simply by adequately documenting the new Testing panel, as long as there were someone with the authorization and time to do it. So there’s at least something that we could help with here if we volunteered to take it on, and the team let us.
Putting on my quality assurance and tester persona, which is the bulk of my career, I would say the one thing that stood out to me was the statement about bugs. So I took a look at Mantis. Clearly there are a lot of bugs out there. Whether it’s just Graham or a team, there’s clearly not a lot of visible movement on them. (Which doesn’t mean no movement; just not visible movement.) But even so: that’s still a lot of bugs for just one release. That kind of backlog is bound to cause pretty bad regression issues not to mention more bugs. And, to at least one point in Emily’s post, may lead to further issues with extensions that don’t keep up with changes that need to be made.
So an open source Inform 7 would potentially (not definitely) allow bugs to be worked on more frequently, which tends to lead to a more stable code base and can ease concerns that the project will simply stop being worked on.
I’m not a pro here, but it seems to me that most of the currently bugs in core Inform aren’t really show-stoppers. (Except for the ParseTree bug which as I understand it is causing a lot of trouble for foreign-language Inform–that’s important, of course–and the Flexible Survival people sometimes run into trouble with their massive project busting the compiler, but last I checked they had a special patched version that let them keep working.) The opacity of how they’re being handled is a problem, but again I think some of this frustration could be resolved without burdening the core team by having people post some bug-fix extensions somewhere on the main site. Which, again, would require us getting the keys to the main site. But not that much more than that.
And a lot a lot of the frustration I see here on the forum and elsewhere has to do with the difficulty of finding proper versions of extensions, and figuring out which ones are up to date. (I don’t think I know whether Disambiguation Control is up to date, and that’s one I helped update myself!) That really seems like something that could be solved on the website without further troubling the core Inform people. And if there could be an extension team (again, seems natural for the IFTF to supervise) that could do things like help keep track of what’s maintained instead of relying on individual extension authors to come back out of the woodwork every time there’s a new version, that would be even better. There was a thread on here for checking extension compatibility with 6L I think, but if some group had a clear institutionalized role to do this I think it’d help keep that going.
I feel a bit brass-faced saying this, because it’s essentially “Why don’t you all take on this work?”–I can’t really volunteer for this myself (I know nothing about websites, and while I probably would pitch in on some extension maintenance I don’t feel like I can take on any more of an institutional role over and above what I’m doing with this forum). But, well, it’d be nice to do.
I like this idea. I wonder if Graham would be open to letting other people help with the website? Should we make a uservoice suggestion for it?
bg, thanks! To be clear, I don’t know what Graham thinks at all, and I’m not really clear as to who’s doing what on the team. And part of the issue is that if we just put something on uservoice it’s not clear how fast it would get handled. One thing I think is that before anyone asks for the keys to the website there ought to be a team in place that’s prepared to take the responsibility, and maybe has some plans for what to do with it. Which would require those people to put in some work on spec, I’m afraid. But I guess someone would have to take the first step.