It is a showcase in why you release iteratively and get feedback often. We’ve already seen bugs found by people literally in the first day – in some cases, first hours – that could have been caught by either (1) testing or (2) allowing users to hit it, thus doing your testing for you. We’ve seen suggestions already that were accepted into User Voice that would have probably altered bits of design and allowed for more rapid feedback on those ideas. And it took no time at all for people to find those new ideas. Imagine if you involved them earlier? Had more forum discussions about feature implementation?
A Public Library, which is a very cool idea, wasn’t as immediately ready across the board as it absolutely should have been, example: the Windows build. (It was three years after all.) A French extension that was mentioned as being available, isn’t. Small thing, yes. But apparently it does exist and is ready. So putting up an extension should take five minutes. Some people are still waiting. End of the world? Of course not, but it showcases (to me) an extension (no pun intended!) of the underlying problems.
Existing extensions that could have been tested (after all, it was threeyears) are only now being tested for the first time with the new system and found to contain problems. Expected, given the changes to Inform – but still – why not build that process into the release cycle? You had years! (Can’t stress that enough.) If more help was needed for this, or if original extension authors weren’t available – ask the community! Provide beta builds of the new release, ask for help on testing. (As a side effect, you may have found some of these bugs that people found on day one that apparently slipped through all that testing and gotten some of that useful user voice feedback.)
Inform is an awesome system, but I really wish it would get a more up-to-date developer crew. (Or at least have a few developers on team that have the skills and knowledge to inform others on how effective development can be when you change your approach.)
Yes, I’m being critical. But any good development team should welcome and desire such feedback. (Of course, I would say that, wouldn’t I?)
My first rule of using new software: don’t use it until it’s been out for several weeks at the very least.
Bugs always tend to get past the most thorough testing and in most cases the first few weeks with new software are a constant struggle with error messages and things going wrong. I also find that a lot of the new features are ones I don’t really need and probably won’t take advantage of in any of my works in progress so for me there’s no rush to upgrade. The old version suits me fine.
I wouldn’t mind having a more open development process with a public code repository, and so on.
There are advantages to the current model, though, especially for extension authors. You only have to make them up-to-date once every three years, rather than constantly keeping up with an open development process.
So, some people have worked their asses off for years to deliver (for free) something on your front door and you complain about how they decided to ring the bell?
Anyway: Windows and OsX go public with bugs. I guess Inform can, too.
I’ll repeat what I said earlier: Pointing out that I7 uses an old-style development process hasn’t led to much change in the past. (People have been making the contention for a while. See “It’s a Cathedral, Not a Bazaar” in the '07 possible future developments document.) And it sometimes elicits reactions like this from other users, even when the criticism is fair. I think a more effective argument is to demonstrate that there are people who want to help with all that hard work (and are willing to do so in ways that don’t interfere with the main team’s ability to steer the project, e.g., by submitting bug fixes for approval rather than making them directly), and that these people are frustrated and unable to contribute because of the process barriers.
I agree. I would prefer to see people respond to the substance of bukayeva’s criticism rather than indulge in ad hominem attacks of the “stop whining” variety (though in years past I may have indulged in one or two of the latter myself).
I have an immense amount of respect for what Graham has accomplished with I7, but very little respect for the manner in which he has gone about accomplishing it. His process is needlessly opaque, and it has caused needless difficulties for many users. The fact that he has a large user base that would be eager to help seems not to be of any interest to him.
I tend not to make anti-religious observations in this forum, because the topic doesn’t come up, but just this once, maybe. I have no use for cathedrals, period. If all the cathedrals, mosques, temples, and synagogues in the world fell to ruin through lack of attendance, I would throw a week-long party to celebrate. So given that Inform’s development process is a cathedral, not a bazaar, I would say that’s the essence of the problem.
Well, let me disagree with this. Consider the impressive attention to moddability that went into the I7 language design, the extensions site (and now the extensions library), the launch of UserVoice, the launch of Mantis, the advent of Preform—all of these things point to an interest in involving users. And there are reasons to use a more closed development process (e.g., that it allows the developers to iterate without dependent code chasing a moving target, as Victor says, or that feedback can be solicited from hand-picked sources without the risk of it drowning in a general bustle). If I7 development is mostly closed, it’s because these advantages are seen to outweigh the disadvantages, not, I think, because of disinterest in outside input.
Which again leads to my contention: The best arguments that can be made for I7 development going open are those that increase open development’s relative advantages. A demonstrable number of people willing to chip in in ways that the main dev team finds useful, for instance.
I’m sorry Jim, but I didn’t post any “stop whining” reply. My point is that some people should have earned more respect that the one allowed by repeating " * three years * " over and over. I believe there are better ways to post a complaint.
But maybe, as usual, it’s my being Italian that makes me misunderstand tone and language. Or the fact that these days I’m forced into a school where too many students think they know more than me in the subject I teach. Maybe it’s just an open nerve.
Sorry for stealing more space in this lovely thread, anyway.
I don’t want to put words in Jim’s mouth, but I get the sense Jim speaks in context of the recurring arguments about I7, its development process, the “cathedral/bazaar” divide, et al. It may be less about what you said and more about nipping it in the bud.
Anyway, I think the cathedral/bazaar metaphor a bit unfortunate or at least imprecise. A cathedral isn’t under constant development and expansion after all, and wouldn’t easily be retooled into a bazaar upon release of its blueprints. Flippant maybe, but I’m not trying to be obtusely literal-minded; it’s that I genuinely think what we now have – in no small part due to the development model – is a set of very solid foundations that could support both edifices equally well.
Or maybe it’s a very apt metaphor after all: perhaps one could build a particularly impressive bazaar on foundations meant to support a cathedral.
I’ll happily withdraw the “stop whining” comment. Really, all I meant was exactly what Eleas said – that I’d be more interested in reading a discussion of the development process, as opposed to a “be grateful that it’s free, and Graham can do it however he likes” comment.
I know little enough about software development, either professional or freeware, and of course Graham has involved the community in various ways – with the Mantis bug tracker, for example. But as I’m sure I’ve mentioned before, I’m also an occasional participant in the Csound community, and the development process there is just about diametrically opposite the I7 process. There are several update releases every year, for example. The source code is freely available on github, and many people download and compile it themselves.
Perhaps one salient difference is that the Csound maintainers are working in electronic music departments at universities. That’s their career. I’m not sure what Graham does for a living, but I doubt it’s directly related to interactive fiction.
I am not aware of any genuine offers of help being refused. The original post notably does not contain any suggestion of willingness to help: it is instead a description of an opinion of how other people should change how they spend their free time. Oddly enough, that’s never seemed a very compelling argument.
I’m not a software developer, but I can tell you that a few years back I quite sincerely offered to help expand the built-in documentation, which at the time (I haven’t looked at the new version in detail yet) seemed to gloss over some of the issues that authors might reasonably be expected to run into.
There was no reply.
Or perhaps (by now my memory of the incident is vague) Emily refused my offer. That may have been how it went down.
Oh, and just in case this should seem to have been a random offer, not worth serious consideration, I am (cough-cough) a professional writer with many years of experience explaining technical subjects to interested but not technically minded readers.
My recollection of this event is that you sent us a list of comments on the existing documentation, which we went through and responded to in detail, incorporating the fixes that seemed appropriate.
Admittedly this is some time ago now, and I don’t have the email in front of me, but that’s what I recall going down.
[ETA: that said, I suspect that a rewrite of Writing with Inform is something that Graham would prefer to reserve to himself; but whether it is or not, I am not the one who makes those calls. There are loads of things that would be welcome from volunteers, many of which are so labelled on the Uservoice forum with a vw tag for “volunteer wanted”. Alternatively, if people want to do something not listed there, they are welcome to write.]
I have to say here, as I said on the other thread, that I find WwI very inspiring; even though I never actually get anything done, reading it makes me WANT to build, to create, to write, and even if it never goes anywhere, there’s always a little test project created after/while reading it.
I was under the impression that the handbook, the “I7 for programmers”, et al, were the best way to do it - alternative manuals for those who’d like them, retaining the original documentation.
There are inherent trade-offs going from a privately run development process to an open one and there is evidence that neither is perfect. I would argue that there would be even more rancor with an open one given my experience with the IF community (we are very much…like a herd of cats).
Also, if you look very closely at the Mantis bug tracker, you will see quite a few people not Graham responsible for various items. This tells me that Graham has in fact invited trusted folks to help him where it is needed. And as has been noted VW stands for volunteer wanted.
I also doubt that anyone capable of helping and interested in helping isn’t already doing so. And by helping, I mean respecting and following Graham’s lead.
I build software for a living. What Graham and a few cohorts have done in the last twenty plus years is extraordinary. I’m pretty sure I’d like Graham to continue to work as comfortably as he wishes on IF-related tools. The reward is certainly worth our patience.
This is the seasonal Inform 7 panto, folks: Graham Nelson does Inform a certain way. People (usually) politely point out they wish he’d do it another way. Graham continues to do what he’s doing. People seem to take offense that they are somehow not being heard (“how rude of him to not accept my unsolicited advice!!”). It is pointed out that there are channels to be heard, but thank you, no, Graham is going to manage Inform in the way he does. People complain that it would be done a better way if [x] and every software company they’ve ever worked for in the whole gosh-blang universe does it this way and look how much money they make. Graham Nelson continues to work how he does.
When I say “people” I single absolutely nobody out. I couldn’t even for the life of me remember anyone’s name on the left who has posted here. Except Emily Short because…well she’s Emily Short.
Good gravy people … we all write Interactive Fiction which is about parsing meaning. if you read between the lines, the response to this every time seems: “No, Graham Nelson chooses to work with a small group, and not expand the development of Inform to the more common frequent-release public beta model, no matter how much more quickly and how much better you consider that route would be.”
I’m sure If he changes his mind, we’ll be the first to know.
I don’t know the man, but I infer that he is one of those impossibly polite people who hate to say no and prefer to keep steady on with the work and not waste time on forums explaining himself.
I’m so glad there are hordes of ridiculously intelligent people who eagerly take up the consumer portion of the release afterward and work on fixing things and helping others and writing extensions and discovering new things about Inform so that the ~3 years between releases doesn’t feel like that long.
I think Emily, DavidC, HanonO, James and others have provided very thoughtful commentary on this thread, but I feel compelled to add my own $0.02. I have spent 20+ years of my career in software development and I have tremendous respect for the work that Graham and others have done in creating Inform. It is a very complex multi-platform compiler with a superb set of IDEs, fantastic libraries and excellent documentation. And it is remarkably stable and reliable.
I can also say that the most successful products I’ve worked with have all had a lead programmer who has shaped not only the product but also the process by which the software has been delivered. (In open source this is sometimes affectionately called the “benevolent dictator for life” or BDFL). While I would love to see a slightly faster 1-1.5 year release cycle, Graham has created a system which clearly has scaled beyond the work of a sole developer and leverages a high caliber team of developers. Moreover, he has created an open architecture that enables a broader set of programmers to create extensions that add greatly to the value of Inform. Graham has enabled people to participate by reporting bugs, suggest features and there’s a reasonably transparent system supporting this. And there’s been a tremendous “ecosystem” that has grown organically around Inform (and other languages and IF in general) providing things like Glulxe, dozens of interpreters, an IFDB repository, many IF Comps, books like Aaron Reed’s and Roger Firth’s before that and so on. I’m not sure how much of this would exist if it weren’t for 20 years of hard work on Graham’s part that helped get the ball rolling. And it’s worth pointing out, that Graham hasn’t asked for a gosh darn dime from any of us.
The other thing I know about successful software products is that they require tremendous focus from the lead developer. That focus often requires shutting out the rest of the world so that he or she can do what’s necessary to write code.
There probably are a few things that could be slightly better. But on balance, I’d have to say this one helluva successful software project. And its success is part and parcel with the development process that Graham has used.
Flippant maybe, but I’m not trying to be obtusely literal-minded; it’s that I genuinely think what we now have – in no small part due to the development model – is a set of very solid foundations that could support both edifices equally well.