Recently, Christoph Pfister, founder of the Fink project, loudly and publicly resigned. There is a lively discussion of this on MacSlash and Slashdot. Advogato would like to use this event as an excuse to discuss some of the strengths and weaknesses of free software.
It is very easy for this cat to sympathize with Christoph. It is the rule, rather than the exception, to put blood, sweat, and tears into a free software project (not to mention long hours), and get precious little in return. Even the satisfaction of knowing that you have given valuable software to many users is tempered by hearing them whine and complain. Even more frustrating is when other people get fame and fortune off the coattails of your work. The fact that all this effort is not rewarded with money is the major shortcoming of the free software process. There have been quite a number of attempts to fix this, but few have been successful, and of those that have, most don't seem to generalize.
That said, these events display one of the strengths of free software, as well. Christoph has created something of value (a package management system for Mac OS X based on Debian's), and a community has formed around it. It's likely that this community has reached critical mass, so that it can continue to thrive even without Christoph's participation. This post from David Morrison points the way for how this might happen in the case of this particular project. There is great resilience in free software, not obvious to those who see only the surface of Linux business failures and public expressions of burnout.
It would appear that a large part of Christoph's frustration are the leeches who sell CD's of the software, but do not adequately credit him or share any of the money. Part of this, no doubt, is the nature of the Mac shareware community, which does not place the same value on attribution as the free software community. However, this problem is certainly present in the Linux community as well. For a while, it was looking as if VC's and other investors in Linux companies would make billions of dollars, while those of us who actually did the work to make Linux so valuable continued to struggle to get paid at all for our efforts. This cat freely admits to Schadenfreude upon learning that these billions turned out not to be real money after all. There may not be as much money floating around, but the money that remains is, in general, far more equitably distributed.
The evanescent rewards of free software are a major factor in the relatively high turnover in projects. This turnover has some advantages and disadvantages. On the plus side, it brings new blood to projects. People who join a project bring their valuable perspectives and experience. Conversely, experience with a number of different free software projects is nourishing to people who work on them. However, in many cases the leaders of projects retain invaluable wisdom and experience. Where would Vorbis be if Monty left the project? It would probably hobble along, because it is so important, but it would be a crippling setback nonetheless.
Free software is particularly hard on leaders. This cat believes that there are many who possess unique skills and talents, but who are turned off by the rough treatment that leaders are subjected to. (Not to be so audacious as to propose myself as an example, but it is true that cats have special talent when it comes to putting colored marks on pieces of paper, and this is an area where free software could really use some leadership). Instead of giving examples, I'll just call attention to the current drought of leaders. Many of the "big names" who would have been listed as leaders a couple of years ago are no longer very active in actual free software development, and there isn't much in the way of new blood. Thank God we've still got Linus.
Mac OS X gives an excellent example of why leadership is so badly needed. Apple could easily have taken a leadership role, and presented a compelling vision of how software should be packaged for OS X. Instead, its own efforts are very weak. The included Installer.app sucks in many small ways and some large ones. In the latter category, it lacks many of the features you'd want from a real package manager, such as keeping track of dependencies, and offering a simple uninstall. In the former category, you have the bonehead decision to use the obscure pax format instead of tar, and the fact that you still need a directory of files rather than a tarball. As such, there's a nontrivial amount of software distributed as a binhex encoded StuffIt archive, containing a disk image of an "installation CD", which in turn contains a pkg directory, of which the meat is in a pax archive. Somebody in Cupertino must have been smoking the good crack.
Apple also provides some links to Unix software, but as far as I can tell makes no effort to ensure that any of it is integrated nicely.
Obviously, such major shortcomings create an opportunity for the free software to step in and do a good job. Indeed, we've accumulated quite a bit of knowledge and wisdom about how to do package management well (as well as quite a bit on how not to!). There are two such well-known projects: Fink and GNU/Darwin, which is based on the BSD ports system. Choice is good, but coherence is also good. What should a user do who simply wants Apache? Use the Apple-provided version, the Fink version, or the GNU/Darwin version? In many cases, they conflict. Will X applications designed for one distribution work well with an X server (and fonts, and libraries, etc.) built for another?
A lot of people lose here. Mac OS X users are reinforced in their perception of Unix software being inaccessible, finicky to install, hard to learn, and generally having horrible usability problems. Developers of software wishing to port to OS X do not have clear guidelines on how to do so. Hopefully, the situation will get better, but it will take time. If someone had stepped up to the plate and led the effort, it would no doubt have happened a lot sooner. It might have been Christoph, but you can hardly blame him for not wanting to take on that responsibility, for so little reward.
How to make things better? For one, take a little time to express your appreciation for those who do donate their leadership to the cause. Advogato would like to thank Christoph, and many others, for their contributions. It is through such humble public service, not flashy pronouncements, that true progress is made. Thank you.
I deal with a few rude users, and some completely clueless ones.
To keep my sanity, I have some rules of thumb for free, voluteer tech support on my personal time:
A very few users are mind-bogglingly clueless and simply cannot be helped. For example, some guy wrote me to ask whether an RPC library could be used for displaying italic fonts under Solaris. I'm not making this up.
Advogato bows his head in shame and apologizes for misspelling Christoph Pfisterer's name. This cat should know better, as it happens all the time to me, as well as my alter ego.
This is why software is best developed by those who need it, not by those looking for some other payoff.
People developing software they need will be satisfied to take the testing, bugfixes, ideas, and occastional new features from the user community as they come. People who do it because they need it find it very easy to ignore idiots.
It's only people who are playing/trying to play a PR game, trying to accumulate more and more users, for some other payoff (ego, money, whatever) who seem to have real difficulties with free software.
Christoph Pfisterer. He rocks. Getting LyX, GIMP, etc. running on MacOS X is so simple with fink that using it makes me all warm and fuzzy inside, not to mention all the other packages.
Fink has/had more potential than any other packaging system including Debian. It combined the download and compile nature of FreeBSD's port collection with the dependancy system of Debian. That is simply awesome.
So, today is a sad day as it seem obvious enough that Christoph was the guy with a vision, and (most importantly) enough skill and determination to make it happen.
I guess what we hope for now is that Christoph starts another successful project in the future, after the frustration has worn off a bit.
Is when people casually mention that "oh, no I don't use XYZ, it's got ABC bug", that they *haven't even bothered reporting*. It drives me crazy, and should be grounds for invoking the Remote Strangulation Protocol.
People who have maintained a free software project for a while usually develop skills to keep the pressure reasonable.
The problem of uncredited distribution is mitigated somewhat by the leeches having to absorb complaints from newbies. Sending newbies who find you anyhow to complain to the leeching distributor, instead, until you get proper credit (& maybe funding) is fair.
Over-demanding users can often be dealt with by the simple formula: "Please send a patch."
Don't forget, users are of value only to the extent that they send useful bug reports or money. They have to earn respect. Asking for money in exchange for special treatment is no insult, and can be a living for some.
This article rings lots of bells for me. It's been a real emotional rollercoaster ride leading the ARM Linux project, and continues to be so. I don't think most people (users and some developers) stop to consider what the project leader(s) have to do in the community, or how much work there is to do building an initial community.
Yes, you do end up putting blood, sweat, and tears into a free software project, and you do end up getting very little return, apart from a mass of users who might send you a bug report from time to time, or if you're really lucky a patch which might have been well thought out.
When it comes to crediting people for their work, there definitely isn't any thought given to who should be credited. Maybe this is down to peoples marketing departments being generally clueless, but there have been many times where I've read press releases about "ARM Linux" with mentions of "Linus Torvalds", but not a word about myself. The alternative is that it goes the other way, and someone else who feeds patches to me gets credited.
Some people even positively don't like it if you do try to get this problem corrected - I'm sure this post will get a few negative replies to it, and yes, it does affect you. This is one reason why I kept the KernelTrap interview generally quiet, especially in the ARM Linux community. Let the sleeping dogs lie.
Obviously, this makes people feel really pissed off and wondering what they're doing spending all their time working on the project. When you raise the problem with developers, they know all about you, they recognise you, but that's about as far as it goes.
As far as users and support goes, I'd recommend to anyone who's thinking about creating a user community to stay away from things like public IRC and chat-based systems. Typically you'd end up with a nonstop stream of questions from people, and they won't email problems - they'd rather wait for you to visit the IRC channel or whatever. Of course, while you're dealing with their problem, you're neglecting the other maintainence requirements of the project. I've found myself in this situation a couple of times, and it's not nice - typically you'll end up alienating those users, but life must go on.
There is another problem though - some developers believe they have the one true solution to a problem, and they're so certain that there's absolutely nothing that is better, and you must take their patch. When this happens, unfortunately, I generally end up in a rather nasty flame war, something which I really hate and regret afterwards. Sometimes you see before hand where it's going and try to ignore the emails or even (ahem) block them, but that can cause more problems as I found out. I'm still not certain what the correct solution to this one is.
Fragmentation of the community caused by new "lets port xyz to this hardware and setup our own mailing lists" can be a major problem - see the handhelds.org mailing lists. It dilutes the usefulness of the main mailing lists (maybe this is their target goal?), reduces the number of visible bug reports, and prevents the free flow of information in the community. It causes confusion for new developers and users, who wonder which mailing lists they should subscribe to or not, and which lists to post their messages to. Of course, the problem of cross posting also happens. Various reasons get quoted for setting up new lists, but the common one is "too high traffic on the main lists", even if the list has 1/20th the traffic of the LKML list.
To be frank, I've been disgusted with the state of the ARM Linux community for the past few years.
Finally, yes, there are lots of things that I'd have done differently had I had prior experience of such projects.
This article rings lots of bells for me. It's been a real emotional rollercoaster ride leading the ARM Linux project, and continues to be so. I don't think most people (users and some developers) stop to consider what the project leader(s) have to do in the community, or how much work there is to do building an initial community.
Yes, you do end up putting blood, sweat, and tears into a free software project, and you do end up getting very little return, apart from a mass of users who might send you a bug report from time to time, or if you're really lucky a patch which might have been well thought out.
When it comes to crediting people for their work, there definitely isn't any thought given to who should be credited. Maybe this is down to peoples marketing departments being generally clueless, but there have been many times where I've read press releases about "ARM Linux" with mentions of "Linus Torvalds", but not a word about myself. The alternative is that it goes the other way, and someone else who feeds patches to me gets credited.
Some people even positively don't like it if you do try to get this problem corrected - I'm sure this post will get a few negative replies to it, and yes, it does affect you. This is one reason why I kept the KernelTrap interview generally quiet, especially in the ARM Linux community. Let the sleeping dogs lie.
Obviously, this makes people feel really pissed off and wondering what they're doing spending all their time working on the project. When you raise the problem with developers, they know all about you, they recognise you, but that's about as far as it goes.
As far as users and support goes, I'd recommend to anyone who's thinking about creating a user community to stay away from things like public IRC and chat-based systems. Typically you'd end up with a nonstop stream of questions from people, and they won't email problems - they'd rather wait for you to visit the IRC channel or whatever. Of course, while you're dealing with their problem, you're neglecting the other maintainence requirements of the project. I've found myself in this situation a couple of times, and it's not nice - typically you'll end up alienating those users, but life must go on.
There is another problem though - some developers believe they have the one true solution to a problem, and they're so certain that there's absolutely nothing that is better, and you must take their patch. When this happens, unfortunately, I generally end up in a rather nasty flame war, something which I really hate and regret afterwards. Sometimes you see before hand where it's going and try to ignore the emails or even (ahem) block them, but that can cause more problems as I found out. I'm still not certain what the correct solution to this one is.
Fragmentation of the community caused by new "lets port xyz to this hardware and setup our own mailing lists" can be a major problem - see the handhelds.org mailing lists. It dilutes the usefulness of the main mailing lists (maybe this is their target goal?), reduces the number of visible bug reports, and prevents the free flow of information in the community. It causes confusion for new developers and users, who wonder which mailing lists they should subscribe to or not, and which lists to post their messages to. Of course, the problem of cross posting also happens. Various reasons get quoted for setting up new lists, but the common one is "too high traffic on the main lists", even if the list has 1/20th the traffic of the LKML list.
To be frank, I've been disgusted with the state of the ARM Linux community for the past few years.
Finally, yes, there are lots of things that I'd have done differently had I had prior experience of such projects.
Well, not all of them. But in almost any collection of people, there will be some jerks. It happens. Worse, jerk-induced problems scale linearly with the number of jerks, while non-jerk induced problems scale sub-linearly (logarithmic? square root?). This means as a free software project (or pretty much any other project/organization) grows, the amount of time you spend dealing with jerks grows. Eventually, you start developing methods of dealing with them. The exact ways you deal with them depends on the project/organization. "send a patch" is a pretty common one in free software. The thng to remember, of course, is that the number of people benefiting is the number of non-jerk users, so when you find that jerks are starting to be a problem, it's probably a sign of success.
I wonder if people who contribute to Free/Open Source software don't have their expectations set too high.
I have answered one metric buttload of public and private comments about Mojo Nation over the years, and actually 90% of people have been very polite and friendly. The remaining 10% have obviously had their hearts in the right place but their mouths in the wrong place, and maybe one or two individuals out of all these thousands have actually been unhappy enough to be actively
trying to be rude.
Maybe Mojo Nation attracts different kinds of users than, say, the Fink project, but after reading this guy's resignation notice and reading a couple of the bug reports that he cites as samples of the tribulations that he has endured, it looks to me like he, and one of the other Fink contributors, not the bug-reporters, were being rude, using all-caps, and so forth.
I wonder if these people who find Free/Open Source software users to be so irritating have ever dealt with lots of semi-strangers in other contexts, like working a service job or being part of a large organization or business. Other human beings are difficult and irritating to deal with at the best of times, and the Open Source community is not, in my experience, worse than average.
Regards,
Zooko
I just finished reading Christoph's letter as well as the reference material he provided and in my opinion he should probably avoid open source software in the future, or at least change licenses. As far as I can tell there is nothing in the GPL which requires credit to be given to the author of GPL'd code, which seems to be one of the main beefs he has with OpenOSX and forked.net.
There are other licenses which do require this, such as the Apache license. Personally I prefer a modified Apache license which includes the following:
In addition, we request (but do not require) that you include in
the end-user documentation provided with the redistribution and/or in
the software itself an acknowledgement equivalent to the following:
"This product includes software developed by Name
(http://yoursite.com)."
Why do I prefer this modified Apache license? Because I write open source software that I need and I don't care whether or not I get credit for it. I would do it whether I release it or not. I prefer to release it because a.) it makes me feel good and b.) I usually get at least one useful comment for each project, and often more. I know that the people whose opinions I value will know that I am the author because they care enough to find out.
Back to Christoph: the tone of his message, along with the tone of his responses to user requests makes me believe that he was having a real bad day/week/month/year when he wrote them. I like the old saying: "If you can't say something nice, don't say anything at all." Perhaps had he ignored these requests or at least delayed his responses long enough to cool down he wouldn't have felt the need to quit as the project lead.
Well I have rambled on long enough. The good news is I still feel that open source software is the way to go regardless of one developer's desire to exit(1).
I think FS/OSS should be about individuals and corporations (non-profit and otherwise) contributing their efforts for their own stable self-interested reasons. Giving something away and expecting too much in return is a formula for burn-out.
We all took a ride on the speculator-fueled Internet rollercoaster which had an extra free-software thrill near the end. Years of softening up peoples logic with Yahoo-like IPO's paved the way for other give-it-away-and-get-rich business models. But that wasn't reality.
Time for a return to original motivations for doing free software, a return to respect and admiration for all parties involved (those who would be crazy enough to produce it, those who would be crazy enough to use it), and a return to the realization that you get what you pay for, so appreciate what you get for free.
Questioning the motivations of someone who has given a huge amount of time to free software and now quit in frustration is, to say the least, impolite. The standard business practice of covering the real reason why you quit is dishonest, unpleasant for the person leaving, and bad for everyone who isn't given fair warning of problems.
Licenses are distinctly a side issue - nowhere in in Pfisterer's resignation did he mention the GPL, ad clauses, or even copyright. He was simply complaining of being overworked and underappreciated, not as a matter of what people are required to do, by law, but what they ought to do, as a matter of common courtesy. Slashdot's blurb is so misleading as to be clearly unethical.
As for pax, rumor has it that a certain well-known free software zealot is very insistent that invoking gnu tar, even as a separate process, during installation would be a violation of the GPL, as a result of which apple has avoided using it.
I can't help but relate this to DeRaadt's departure from the NetBSD group. Both have a tendency to erupt rather abruptly in public forums over seemingly miniscule details. However, I find glaring differences between the two on one major point.
Maybe it's just me, but the exchange between Jeshua Lacock of OpenOSX and Chris demonstrates a whole lot of rudeness coming from Chris, as well as a fundamental misunderstanding of the GPL. He implies that someone taking RedHat's distribution, duplicating the CDs, and selling it without mentioning RedHat would be wrong. He couldn't be farther from the truth (the only thing "wrong" would be not mentioning RedHat -- using their name would probably help your sales!).
As far as "chewing up and spitting out our leaders", do we really want rude, misinformed people like this as "leaders" of the community? He may be a good producer (i.e. coder, designer, packager, whatever), but politics is half the battle (whether you like it or not, you have to get along with other people).
Lastly, and on a separate note, what do you really expect to get out of creating free/open software? Fame, fortune, the admiration of your peers? Or just a piece of software that fulfills whatever need you have? Seriously, if you want to make money from writing software, I'd suggest that you try *SELLING* it instead of giving it away! (Note, it is possible to SELL "free" software, especially with a dual-licensing scheme or with slick packaging and documentation.)
Not sure if Bram was replying to my post, someone elses post, or multiple posts, but I feel is necessary to point out that while Christoph did not mention GPL, ad clauses, or copyrights in his resignation letter, they were the prime topics of his discussions with OpenOSX and forked.net.
Perhaps it was unfair of Slashdot to have said that "Christoph Pfisterer has resigned largely because of GPL violations by openosx and macgimp, as well as macosx.forked.net" because nowhere does he say that these are his primary reasons. The fact that he mentions them in his resignation letter though does make me think that they played a significant role in his frustration.
It would be nice if everyone understood and appreciated all of the work that open source developers put into their projects, but the fact is this will never be the case. Someone will always be ignorant, someone will always be mean. The key is to try to forgive ignorance and ignore meanness and remember the (hopefully) large number of people who use your software but never contact you because your software works fine for them.
Much good stuff is being said here.
Absolutely, there are recipes for being happy doing free software, and recipes for becoming really frustrated. Doing work you love to get stuff you need done is one of the best recipes for happiness.
Unfortunately, this recipe works well for individual efforts, but doesn't really speak to how to work well in a group. I think this is where we face the biggest challenges.
I certainly agree that the GPL license is a side issue. While it seems to me that some of the commercial Fink-based CD's did not completely color inside the lines (the news update "10/24/01 - Working to comply fully with the GPL license." at macosx.forked.net does not inspire much confidence), the bigger issue is attribution. The GPL does not technically require attribution, but it's central to the free software way. I think this principle derives in large part from the academic tradition.
Yeah, Christoph was rude to the bug submitters. That's not nice.
Bram: switching from tar to pax is a definite case of cutting off one's nose to spite one's face. For one, ProjectBuilder invokes gcc, so avoiding invoking GNU executables clearly isn't Apple's policy. Second, even if they did have a legitimate license concern, why not just bring BSD tar up to snuff? Using pax just makes life harder for other people who want to create/analyze/etc packages. Obviously, given the other flaws in Installer.app, the person who designed it just wasn't thinking very clearly.
But your point is well taken. Working well with others is a desirable feature for a leader. But if we require high standards of diplomacy and tact, we might eliminate people who are otherwise well qualified.
It's also entirely plausible that people with normal social interactions are sane enough not to want to be a "free software leader".
This is why software is best developed by those who need it, not by those looking for some other payoff.
Except that in 90% of cases it would be easier, faster and cheaper (opportunity cost) for those people just to buy the proprietary equivalent. I think there has to be some kind of other payoff as well.
This is the computer industry. Everybody gets chewed up and spit out. The entire "Triumph of the Nerds" series could be retitled "People who got chewed up and spit out, volumes one and two". Christoph got off easy. Some people who get chewed up and spit out live with the fact that if they didn't get chewed up and spit out they'd be billionaires ten times over. The late Gary Killdall, Steve Jobs, Sandy Lerner, the guys who wrote DOS, etc. If being chewn up hurts, grow a skin so thick that it breaks your chewer's teeth.
Reading the cat's article felt like it was me and my project being described. I've mostly scratched my itch now, and tidying up loose ends encountered only by whiners who won't lift a finger to help is not the most fun in the world. But it's still my baby, and besides noone else contributes significantly, so there's noone to hand off to. (And life's going to get better in 11 days anyway.)
But that's not what I want to talk about in this reply...
People have noted that while there's certainly a moral requirement for attribution, there's no legal requirement, e.g., in the GPL.
I'm not sure this is true (for interactive programs, at least). From sections 1 and 2(c) of the GPL:
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright noticeIf the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice
In fact, it's not the GPL so much as plain old copyright law! When somebody else is redistributing your work, an appropriate copyright notice has your name on it. Maybe it has their name on it too if they've made significant changes, but they can't remove your name. (Unless there are copyright assignments flying around, as with FSF projects.)
It seems to me that one of Christoph's claims is that some redistributor did just that.
I've been leading the Gimp-Print project for about two years now. While I've come across a handful of jerks, that's about it -- a handful. My experience is that far more people are complimentary, and many of them offer to run test prints to help us out. Quite a number of people have volunteered to help out.
Most people will accept that we're very busy, and that we're not perfect. I don't worry about those few who don't; they will exist no matter what. Keeping a positive attitude toward the community seems to go a long way.
I'm not tied in to the original situation, so I can't speak to it, but I do believe that the attitude of the project team goes a long way toward the success (or failure) of the project.
A chip on my shoulder which I exercise from time to time (metaphor mix anyone?) - is there a place for "professional" admins for some projects? By this I don't mean paying people, but getting people who are trained as project managers, admins, etc. in their professional life to head up some of our OSS projects? I'm not sure whether this would have helped in this case, but these types of people have skills to bring to bear, so let's use them.
Knowing how to run projects, deal with political issues, coordinate different sets of priorities, decide when to slip dates, coming up with milestones, etc. is work that professional managers do everyday. Some of them aren't good enough coders to be main-stream developers, but have lots to offer anyway. And the more of them we get involved, the more of them will tell their friends, and the more people will use OSS, and the more desktops out there in corporate-land will be running Proper Operating Systems[tm].
Oh, and yes, I'm a manager...
Mike, the problem with your suggestion is that it begins to take the fun out of things. For many projects, milestones, dates, etc are not desired by the developers. Being told by another person that I have to spend time to work on something is great if I'm being paid for it, but it's hard to accept in a hobby.
On some projects, it would work. If the developers are already committed to that sort of process, there's definitely some room for someone to keep track of the managerial work, leaving developers to develop. But that person will have to step carefully, cognizant of the fact that they have to manage developer happiness as well as project milestones.
That is exactly why I don't see myself as ever making a career
as a professional programmer, but why I adore working on my
own OSS projects. I can't handle the thought of someone leering over
me with artificial deadlines and req's.
To use an overused cliche, I'm "scratching an itch", and I don't
want someone else touching my
skin.
But that person will have to step carefully, cognizant of the fact that they have to manage developer happiness as well as project milestones.
That is exactly the kind of thing good managers do well: They pay constant attention to people's motivations, pressures, and general happiness, and do their best to make sure people work together harmoniously. Unfortunately, the IT world is rife with bad managers who do just the opposite, giving the very practice of management a bad name.
For a good account of what managers should do, see the classic Peopleware.
Qbert - thanks, I agree whole-heartedly. A good manager should be managing people, not the project, particularly in this sort of context. The project should come out of the people, and as no-one's likely to be getting money, then I (the manager) have to work out ways of making the project work. It may be that someone's had a really dull piece of work to do, so you suggest that they do a fun bit, or that someone else has home problems, or other commitments, so you need to convince others that it's in their best interests to pull a bit harder for a while. This is the sort of area where a good manager can bring benefit to a project - helping people to pull together, and make the most of the - wait for it - synergies between members of the team.
Yes, we need to leverage those synergies.
(-8
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank