I know there’s this fine line between asking for development process changes to Inform 7 and not asking at all. This is truly Graham’s pet project and we’re all really just along for the ride. But…
Inform 7 has become a fairly standard platform for developing parser-based interactive fiction. It’s also lost many of its core team members. Emily just posted that she’s no longer the primary liaison to Graham where I7 is concerned. That leaves a fairly massive hole in communication between the community and changes to Inform 7. The platform has become very complex and it really needs more than a few people working at improvements. The obvious solution is to allow more people access to the platform and change the vision from singular to multifaceted. If the code were moved to Github, developers could fork it, offer pull requests, and there could be a community driven to improving the platform.
That leaves those of us that believe in open source to do one thing. Ask. I removed my votes from everything on the user voice site and made a new suggestion:
As a huge open source advocate – all of my projects, professional career and personal, are open sourced on GitHub – I firmly support this.
I don’t know all the ins and outs of the Inform 7 project behind the scenes and I didn’t, and still don’t, see Emily’s post. I’m concerned, however, if only one person on a project this large is the “primary liaison to Graham.” I’m even more concerned if Emily – particularly given her pedigree in this community – is no longer that one person.
I do fully recognize there are times to retain control of a project. There are also times to relinquish some of that control under a project that has core committers and an established pull request process. Is Inform 7 there? It’s probably worth having that discussion.
I might add that I’m speaking as someone who has used Inform 7 in a wide variety of contexts, from helping children with autism and clinical ADHD write stories, to working with established writers in so-called “conventional fiction”, to helping testers and developers explore a problem space and learn how to model situations from human-intuitive to machine-expressive. Inform 7 is an incredibly powerful system, with a very wide ecosystem, that has a wide variety of applications, which is what I’m personally attesting to here. In short, whatever it takes to see development of it continue, I am all for and will support wholeheartedly.
I’d love to see Inform go Open Source, other things being equal–but from things that Emily has said, I suspect that Inform going open source would coincide with Graham not being involved in the project anymore. Or anyway, he has Reasons for not wanting to do it (since he hasn’t done it), and I’m not sure what it would take to change his mind.
If I can threadjack for a bit–it seems like a fair amount of the angst expressed in Emily’s blog post comes from the state of the website. The website doesn’t communicate the status of extensions at all, which can make it easy for people to glom onto the outdated versions; there’s that issue with the Sierra-compatible Mas OS X Inform being available only at the App Store; and… OK, I don’t really have a third thing (the bit about the Skein and Transcript panels is something that might be solvable if anyone wants to write up documentation for them, but doesn’t have much to do with the website).
So maybe one thing that the Community could do to improve accessibility would be to start maintaining the website? This seems like it might actually take some burden off the I7 team, whereas going Open Source might be more like a commitment to start herding cats. Maybe the Interactive Fiction Technology Foundation could take it on, if the Inform folks were willing?
For what it’s worth, I am currently the volunteer who emails Emily about critical stuff. This currently means when the website is down or something like that–ordinary bugs and suggestions go in Mantis/uservoice and are dealt with through the normal channels, with all that entails.
Graham’s answer about this has been consistent: he’ll do an open-source release of I7 when he’s rewritten, cleaned up, and documented the code to his satisfaction. He hasn’t indicated that he intends to step away at that point, or ever.
I think these might be the crucial points. Honestly, without Graham chiming in, I don’t think anything we’re talking about here – or on Uservoice – is going to matter all that much since it seems like the concern is with the “normal channels” in the first place.
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?
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.
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.)
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.
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.
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.
I’d like to add that my plea was not to pressure Graham or demand anything or raise pitchforks.
I’m pleading the case that open source development offers tremendous benefits and if done properly, Graham could still maintain his vision and yet have the benefit of more eyes and hands on the nuts and bots of the code.
Good points overall. One thing I want to point out.
But showstoppers is only part of the problem. Long-lasting bugs lead to technical debt. People end up writing extensions to deal with bugs rather than just dealing with the bug. Or people write extensions that are perhaps unknowingly relying on a bug. People end up promoting habits of “workarounds” that now become so enshrined that when/if the bug is fixed, lots of things break and existing habits become harder to change. Documentation starts getting written around bugs and then the documentation drifts when/if the bug is fixed. Sometimes new design choices are made but now those are undergirded by bugs and then you have to disentangle new feature from existing bugs, and determining which is outpacing the other.
Again, take this as me being biased due to QA and Testing career. So I know I’m micro-focusing on something that might not seem as important.
That being said, even this wouldn’t necessarily have to argue for a full open source release. For example, there could be a private repo where only core committers can make bug fixes. If Inform 7 has a good test suite, regressions can be tested for with each build. One challenge would be making sure that bugs that introduce design changes go through a review process, where Graham would have to be involved. But at least then his involvement would be more focused.
So a controlled and limited open source could be a happy medium here.
Regarding design choices versus bugs, I now finally understand what’s being discussed with the Skein/Transcript/Testing issue. That is a perfect example of intransparency by feature accretion. It looks like the Mac version and the Windows version of the IDE completely diverge in terms of the implementation. Which one is considered the “right” design? We shouldn’t document the Testing approach if that’s not the way it’s going to go. I presume someone did that work for a reason. But someone equally clearly didn’t do that work on the other platforms. So … which is it?
This is also where a pull request system can be helpful. That doesn’t have to be open source, of course, but the more eyes on it, the more likely someone is to question why a completely different implementation is being put in place.
I think the good thing is we’re all looking at alternatives here, from full open source, to partial open source, to business-as-usual-but-with-additions, etc.
But reading that – “some of these developments” and “are likely to appear” does not imply this is the "right’ way, though. Or at least there are multiple “right” ways. Even further, perhaps to Matt’s point, if this was the case of the “right” approach even if only on one platform, the documentation for the Mac version wasn’t updated to reflect this change at all. So, at the very least, mixed messaging which maybe further leads to some of the what might have been reflected in Emily’s post.
That said, I agree this is orthogonal to the discussion of open sourcing Inform 7 since the IDEs are open sourced. Although it’s not clear to me what work on the IDE would possibly necessitate changes to Inform 7 and vice versa.
Well, it has surfaced some interesting discussion and I think this kind of thing is healthy. But I agree that we should all set our expectations accordingly in terms of any of us being able to influence decisions one way or the other.
I don’t think it’s pointless at all. What I think should be done next is contact him via email/phone/etc… so that this can be pinned down definitively. A lot of people really want to know what’s going on and we can’t do that if Graham decides to not be part of the conversation.
Fully expect that only a very very tiny minority can actually contact him directly. At any rate I think it’s imperative at this rate.
I used to have direct access to Graham. It’s been awhile since that was true. This is one of the reasons Emily’s blog post unnerves me. She put herself in between the community and Graham, which had huge benefits to the development of I7 and its entire platform. By removing herself, the community is left without any liaison to Graham outside of the rather formal issue and bug tracking systems. This has probably been in effect for awhile and I guess I’m just now recognizing how much of an impact this is having on I7 as a platform (I7 as a stand-alone application is fine).
The platform as a whole could use more persistent guidance. That’s the part that open source can help with the most.