So, what about MarcEdit? The short answer is no, MarcEdit is not and there are no immediate plans to, open source the application in its entirety. This doesn’t mean that a significant amount of the application’s code-base isn’t available — you can find it on my GitHub page (http://github.com/reeset) — but I continue to keep the application development closed. Since this makes MarcEdit unique, as I make most of my other work available via the public domain (rather than via an open source license), why is MarcEdit different. Well, I have a couple of reasons for this.
Support
MarcEdit is currently used by approximately 20-25,000 active users (users that use the program regularly) and is touched by close to 50-60,000 unique users a year (from a 2016 log analysis). That’s a lot of users. These users come from all around the world, all with different needs and different questions. Each morning, I answer close to 60 emails related to MarcEdit (not counting the listserv). Some of these questions are simple questions, some require more thought, some are enhancement requests that may or may not be appropriate for the application. What has allowed the community to develop around this tool, and has allowed me to provide a high level of support has been the unified codebase. It would be impossible for me to answer the volume of questions that I receive today, and answer questions related to code enhancements or evaluate pull requests as well. I just don’t see a way that I could support both sets of communities, and given the availability of so many great open source tools in the community, this isn’t necessarily what the library community needs. MarcEdit fills a specific niche, it’s a professionally developed application suite that doesn’t require any technical knowledge to use or setup across any platform.
Function
One of the reasons MarcEdit has found a large international user community, is that MarcEdit is fiercely MARC agnostic…it doesn’t assume a flavor of MARC. This is one of the core rules that I follow when developing the application. While many MARC editing tools exist, most tend to be Anglo-focused, and tied to the rules and structures found in MARC21. This makes these tools relatively useless when working with UNIMARC or any of the other 50 or so flavors of MARC around the world. Likewise, this means that these tools tend to only support two character encodings: UTF8 and MARC8. However, library metadata is rich and diverse, and by keeping MarcEdit MARC agnostic, the tool can be used in any country, with any language, using any character encoding. By and large, the tool avoids MARC21isms (unless specifically noted) and tries to provide a tool that can be used by anyone utilizing MARC (or a number of other XML encoded formats) as a data structure. This belief that MarcEdit should be a general MARC editing suite, means that I find myself often times explaining to users why certain enhancements cannot be made, as they would break support for the nearly 1/3 of the user community that doesn’t utilize MARC21. It’s a delicate balance — and one that I try to strike through an open source plugin network which enables users to create plugins that can be used with MarcEdit, or allows me to create plugins that can provide dedicated functionality for specific tasks that are really out of scope for the application. But I will admit, a deep concern that I have is that open sourcing the application could potentially splinter the community, and I believe that the MarcEdit community is stronger together.
It’s Personal
I know, you shouldn’t get too attached to things. But in this case, I have. I’ve been working on MarcEdit since 1999, when the program was almost completely coded in Assembly language. This has been a project that I’ve worked on for a very long time, and I have a deep affinity for the MarcEdit and library metadata communities. It’s work that I enjoy, and work that I don’t currently do in my normal day to day job any longer. Today, MarcEdit has become an engine for my research, and a way for me to explore new metadata workflows and formats, while still keeping touch with the metadata community, which has been my home for years. It’s hard to explain, but in some ways, it definitely feels almost like one of my kids. And I’m able to work on MarcEdit (in a part time fashion) because I’m intimately familiar with the codebase. It allows me to easily move into and out of the development of the application. A very real concern I have, is if this changed, I would have to give up working on the project…and I’m not ready to do that yet.
The Future
So, what does this mean for the longevity of the project. Well, that’s a great question. Every couple of years, I re-evaluate what happens to the project without me. And I have specific instructions on how the project should be made available to the community, if something were to happen to me. I’ve also worked with a core group of individuals who I would hope would take the project over…though, I’m thinking about this again. The project is large…larger than many people may realize. MarcEdit, as a project, is made up of close to 2 GBs of source code and support files — it represents over 18 years of work. I very much doubt that this project will be maintained by a single individual in the future, which as I look at the development of MarcEdit 7 and beyond, I’m starting to think about potential organizations that might be a good fit as I update my succession planning. And there is a plan in place. When there comes a time that I’m no longer able to support the project, folks will know, because the project will become open source. And I’ll actively work with the new maintainers, probably for two years, as I transition out of the project. But we aren’t at that point, and hopefully won’t be for a very long time to come.