This release also makes it one thing obvious to me: while in development, Fnk will always target the latest version of Flash that’s publicly available, without worrying about user penetration or anything of the sort. Old versions of Fnk will still be available as always, so this shouldn’t be a problem.

Also, Fnk development is close to resuming, now that I finally have a computer at home with everything installed. I can’t wait to play with those features. As a personal playground of Flash capabilities and the code that’s used for them, not being bound to artificial limitations like that is quite liberating.

The reason for that decision were twofold. First, I had to decide what kind of license to attach to it – either a more permissive open-source license (like MIT) or a more orthodox license (like GPL). While I had not made any kind of decision on that matter, I’m leaning towards GPL, with maybe LGPL for library versions of the Fnk player – this would be the first project I release under those licenses, and the decision is not that easy.

The second reason, and probably most important one, is that I’m simply not a very good open source author. It’s not that I’m completely ignorant of what it is or how it works – I have created open source two projects (MC Tween and Tweener) that have been quite successful, and I had no problem in releasing some other stuff I created as open source code.

The problem, instead, is that I don’t know how to actually run an open source project with more than one people; it’s fairly easy for me to release and update my own stuff, but when it becomes bigger, and people start making requests, or contributing code, or sending suggestions or bugfixes, I’m just out of my league and I don’t know how to deal with the centralization of control and how to manage people under those circumstances. To put it another way, I’m just a bad open source project leader. Even my knowledge of the available tools (CVS/SVN, issue/goal tracking) at administrative level is pretty rudimentary and tend to be restricted to what contributors know.

While I’m not holding my breath over anything, there’s a chance that more people will want to contribute to Fnk, either with bug reporting and suggesting, or with new code for bug fixing or new features. Under that scenario, my fears are that I would not know how to properly deal with them – specially with how to make the project gears spin well enough for the project to work with more than one author contributing to it with no delays. The project has never been about making Fnk’s code public (although it does have its problems currently), but what to do with feedback I could from it.

Because of this, I’ve been researching a bit and reading about how to properly run open source projects before I can make Fnk’s source public. Specially, I have been reading Karl Fogel’s freely available book, “Producing Open Source Software“, found thanks to this page. And I have to say, it’s been pretty enlightening. Not only does the guy write pretty well, but the book talks about all aspects of free and open source software, including providing historic and contextual information about what’s discussed.

This is what this post is about. If you’re unsure about what open source software is about, or about how you can make a successful open source project, go check the book out. It is rather long, but you can skip some parts you already know and go straight to the topics you are curious about. I’m mostly focused on the technical management issues, and it’s been pretty good so far.

• Misc editing: link types, panel additions, proper connection editing and value validation
• Standalone version optimization and features (native OS UI, proper local file reading)
• Misc graphic features
• Misc sound features
• Misc video features
• Embed player
• Web capabilities (server-side saving/loading/sharing)
• Sub-patch creating and editing
• Loadable SWF/SWC player
• Proper stream support (remote loading)
• File embedding
• XML features
• Multi-user editing

It’s a lot of stuff to be done (and this doesn’t count more basic changes, like fixing bugs and adding more basic nodes). So instead of doing random different changes, I’ve decided to tackle each specific group at a time.

Right now, while this wouldn’t usually be the #1 priority, I’m fixing the standalone version features – making sure it’s properly integrate to the user’s operating system and working as expected, like using the native OS menu, opening .fnk files, reading image and sound files without a lot of internal circlejerking, and things like that. I believe this is needed to have a more mature application to work with before dealing with some of the inner features.

Other change groups will follow – there’s still a lot in Fnk that can be considered quite flaky. When the time comes, I’ll post here about it.

Fnk presentation: talking about web applications, showing Photoshop Express
(Photo by Elise Roese)

As the final assignment for the academic side of the project, I’ve just given a short presentation about Fnk at my college for an audience that included selected teachers as well as a few special colleagues.

That final evaluation was the last step on this 4-year long road, and albeit very beta and with a series of important drawbacks, it did fairly well grade-wise; I can happily say I’m over with college. Maybe not very happily since there’s a lot I’ll miss about the place and the people I got to meet there, but I guess it’s part of the game.

Actual Fnk development will resume shortly.

Fnk - Printed thesis

That doesn’t mean I’m done with the college assignments, though. I will still have to present it to a board of teachers somewhere around the coming days, to give a better explanation of the project as a whole and to defend some of its goals and methodology.

It doesn’t mean my work in Fnk is over, either. While I think it’s a good start, there’s plenty of features I still want to add to it, and my to-do list right now is bigger than ever. Its development will be a bit slower from now on, however – I have to do actual work, after all, as I was enjoying a kind of a sabbatical period to work exclusively on it for the past two months and I can’t keep that up forever.

Regardless, I think it has a bright future. In the meantime, thanks for everybody who sent suggestions and helped me test the software.

I guess some clarification is needed. One of the biggest features in the original Fnk project thesis is that it is meant to run from the web – it is supposed to be easy to access, requiring no installations (save for a browser and Flash player, of course) or any kind of administration privileges. This is part of its positioning as a mid-level prototyping, experimentation and learning tool; other similar platforms require an installation or some administrator-level access at some time. This self-imposed requirement may sound irrelevant for most people, but in an academic environment, an application that requires administrator access is a big issue; students have to go through all kinds of bureaucratic hops to get them installed on a lab computer. Plus, you’re not always using the same computer – actually, almost never. In that kind of environment, being able to run something from the web is a godsend.

Still, being based on a browser brings significant limitations to the Fnk environment. Most important, you don’t have unrestricted file reading and writing access; this means you cannot save a file when the user presses CTRL+S, or open a series of images from the user’s computer. You can do some of these things, but due to security limitations the Flash platform imposes you, you need absolute clarity for the user when doing so: for example, saving a file is only possible if you ask the user which file he wants to write to – having the equivalent of “Save As” works (since a file dialog is shown), but not a straight, unattended “Save” that writes to the disk with no user intervention. Saving an image sequence is out of question. And you cannot read a series of files from the disk: you have to let the user pick each and every file he wants your application to read.

And as unfortunate as it sounds, this is how it should be; can you imagine visiting a website and it starts saving data to your drive with no restriction? Hence those safety measures.

That’s why Fnk is supposed to have a separate, more advanced implementation layer, which is this standalone version. Since it runs as a more-or-less native application, it will be able to perform better file saving and reading, as well as having some other small but important features that are not available to the web Flash player (like keyboard access on fullscreen, using native OS menus, etc).

As of now, that standalone version is still as limited as the web version. It has no additional features whatsoever, save for a few probable additional bugs. However, in the future, as it gets more mature, it’ll be a good additional step for more serious prototyping, file manipulation, or installation work. The web version will always remain as the main version and a good starting point for Fnk patching, but if the need arrives, the standalone version will be there. It’ll require an installation, but in exchange, it will have further access to the user’s computer. It’s about providing both options.

PS: Right now, the standalone version is only available for Windows and Macintosh computers. The Linux version depends on AIR 1.5 being available for Linux, something that should happen in a few weeks.

Fnk lessons are just a sequence of Patches that aim to teach a user about the editor and its language in a brief way. Since this kind of programming paradigm is a bit out of the ordinary, some people might have trouble wrapping their head around it at first; as such, they’re designed to introduce a topic at a time and go from there to more advanced features. They’re available right from the “File” menu (this may change to the “Help” menu in the future).

Fnk (build 3478) - Lessons menu

Lessons won’t go too far – they’ll end around lesson 20 or so (the current build is at lesson #16 now). They’ll introduce the language’s basic concepts and features, but for more advanced topics, users will have the option to learn from sample Patches or to check the reference for each node. That way, instead of forcing the whole content down the user’s throat, Fnk lets the user decide on what he wants to use or learn next once he got the basics understood.

Finally, as of now, lessons are available in English only. I’m thinking on how to implement localization for patch comments so they can be loaded and displayed using the user’s selected language.

This video showcases interactivity through by reading the mouse state continuously and updating the Display node accordingly. It also uses the Display output itself to compose a new image; on each frame, the patch is adding the new graphics on top of the current Display content, then showing it again. The result is a bit crude, but indicative with what is possible by simply knowing the mouse input state.

The new Checkbox and Slider input nodes are also shown. Check the update logs to see what was changed recently.

As always, the source for this patch – and others – is available here while I don’t add the ability to load online files.

This video doesn’t show a lot of new things, but it was meant to showcase the new comment feature – it lets you create random text on a patch, unrelated to the actual diagram execution – and, near the end of the video, the fullscreen functionality, that lets you transform a Display node into the solo screen output of the program – a sort of a “presentation” mode.