The GEDCOM 7.0.1 specification was officially released at the beginning of last week. It has lasted longer than February’s 7.0rc that was pulled within hours. It is an evolution of the 5.5.1 specification, not a radical shift towards XML nor towards JSON.
It’s limits and the impact of the incompatibilities are being hotly discussed.
This is why I say there will not be a version 7.x or “X” version, because neither of them evolve away from the one focus LDS have.
And I really can’t understand why Open Source Projects like Gramps don’t go being that limited, locked in format when the potential is so enormous to get more developers with both knowledge about historical research and python coding interested in the project…
I seriously think Gramps as a project is aged and on its way to the grave… sadly
If people shall be interested in a project and support it, it need to give something unique, and something that other software do not have, it’s no longer enough to have a xml format or be “a linux program”, there is at least 3 other genealogy software with distros for linux.
And developers and others need to be more positive to changes that actually evolve the software and add useful features to the software.
There have been to many “invent the wheel over and over again” sub projects and most of them have not even seen the light of day.
One of the most useful of them for interoperability was the mongodb backend, but since it’s not updated or even halfhearted supported, it can’t be used in a production environment.
Moreover, even before that, every screen could already be exported to CSV, so even in Gramps 3.4.9. which I still use, you can export a comma separated list of Repos, and you don’t need a special add-on for that.
Yeh, and some of us use it for some things, but it is a extremely limited list of data you get from it, and it cant be used for very much at all, other that making lists.
The strange thing is that Gramps export to json already, but that json file is useless in any other software that support json without manually changing the format… why not use some effort making it a json export that actually can be used, i.e. a graph json format or similar, even json-LD would have been useful for a lot of analyzing. And why have and maintain 8 other none standard export formats that only one or two users ever use, but refuse to make an export that actually can be useful for more than only lineage-linked researchers?
You don’t seem to understand the nature of most open source software.
Most open source projects are written by volunteers to satisfy the needs
of the developer. If other people find the program to be useful for
their own purposes, that is great, but unlike commercial software, that
is usually not the concern of the open source developers.
Because it is open source, if there are features that you would like to
see added, you are free to develop them yourself and contribute them to
the project. You might be expected to meet some standards in order to
get your modifications/additions added, but that should not be a big
hindrance.
If you are not a developer, you can seek out a developer who is willing
to work with you to implement your ideas. That means finding a
developer who has the same interests or someone who wants to contribute
to the project but needs someone else to define a task that would be
useful to users.
I suspect that there is no objection to extending the usage of Gramps,
but extending it requires developers with time, interest, and expertise
to implement the extensions.
So rather than criticizing the Gramps developers for not providing what
you want, find a way to get involved in the development and help add
those features. But if you choose to do so, try to make sure that the
new features do not impede the usage of existing features by those who
have no need for the new features.
Allen Crider
I ran another test with Zotero, which I last used years ago, and found that it does not record the meta data that I need, for example to point me to a specific document in a collection, or even better, a particular page, or a couple of lines on a page, of a document in a collection.
When I look up the birth record of one my grandmothers, all data that Zotero records is the name and URL of the web page where the record was found, which means that it becomes useless when the portal moves to another domain, or just disappears, except when I let Zotero save the whole page.
In this particular case, there are 6 variables of meta data that are not recorded, which are:
Aktenummer: 808
Aktedatum: 26-09-1905
Akteplaats: Apeldoorn
Toegangsnummer: 0207 Burgerlijke stand Gelderland, dubbelen
Inventarisnummer: 11004
Organisatie: Gelders Archief
And the same goes for an entry on a German archive site, where the meta data are:
Verzeichnungseinheit
Landesarchiv NRW Abteilung Westfalen
U 172u / Familie von Ledebur-Crollage / Urkunden, Nr. 238
For these cases, the semantics are quite similar, meaning that in both you can find the name of the repository, a name and number of a data collection, and a document number. And for my grandmother, there are also a record number, place, and date, all variables that can be easily stored in a way that can be easily translated to all languages that we support in Gramps, and could be standardized in GEDCOM 7.1, or the next version of CSL, as a sort of extension for genealogists, or better, archivists. It is in fact quite likely that most of these are already covered by the Encoded Archival Description (EAD):
The essence of all this is that it is possible to record a decent amount of variables (or meta data) which make it possible to find (and cite) any source, without relying on any sort of formatted citation like you find in bibliographic references that are generated by these tools that are so popular among scientists. And note that I am a scientist myself, so I know the conventions, or at least the versions that were en vogue in the 1980’s.
Relying on references formatted by Zotero and other tools is like thinking that the whole world speaks English, which may be true for us, but is quite ignorant in reality.
Look at the Gramps Data Model. Most of that data is inaccessible from the Views export to CSV. If you want things like Attributes, Internal Handles… or more than the first couple sentences previewed from a note, the view export is insufficient.
It is (almost) OK for a bit of superficial sorting & counting… but nothing more strenuous.
AND AGAIN you prove that you DO NOT READ WHAT YOU COMMENT ON!
Its no point trying one more time to explain that it is a big difference supporting read write to a CSL JSON or BibliaTeX and to create an interface to Gramps.
But all you write over here is easily done in Zotero, if you care to think a little instead of trying to find arguments against something noone writes about !!!
Learn to use the software before you conclude.
AND PLEASE START TO READ what you comment on BEFORE you write your comments !!!
AGAIN ! Its a big diffence between supporting a read/Write from/to CSL JSON and making an interface to one specific software.
So none of your arguments hold up in this discussion !
And you come with the standard aged “it’s open source, forge it and do it yourself” BS!
It’s no point wasting time on your comment!
That attitude is what deprecate open source projects, specially when there is a strict regime for getting those enhancements implemented in the software, meaning that every time there (if it happens) is a new version, you need to update your own installation manually. it’s about as user-friendly as your standard “fork it and do it yourself” answer.
And don’t think that people don’t know how things work just because they ask for it to be different…
It’s that type of stoneage attitude that makes software project like Gramps die.
The only thing an answer like that does is to chase potential new users away from the project.
And if that is the attitude among the developers in the project it is not strange that there is few new developers comming to the project.
If that’s the case, strange Zotero is used in so many countries outside USA and other English speaking countries.
Problem with you is that you desperately try to defend your own arguments, even though you argue about something no one has ever wrote!
You really need to read what I write before you keep on commenting because you talk about something totally different than me!
As a big Zotero user, let me second this sentiment. The Zotero team is in fact multi-national and the tool is used world-wide in various languages.
Hey StoltHD, if you really want to find people help you adding any of your ideas to Gramps, just attacking everyone who disagree with you and complaining how bad Gramps is, is a terrible strategy.
Also as I already mentioned Gramps is a software primarily for lineage-linked genealogy and it will not become something entirely else, just because you wish it and complain lengthy about. There is a lack of Devs, not in ideas and feature requests.
I hear this a lot in these fora, but not in other OS-project-related places I frequent.
I guess my objection would be that, while it may be true that most OS projects are done for the convenience of the maintainers, big and popular OS projects take account of their users’ needs and desires. Have a look at pandoc, for example, where the main developer seems very much user-driven and makes fixes and additions based on user feedback. Of course what the users want isn’t always feasible, but I think there’s great respect for everyone who does the coding and they often do it based not on what they want, but what users ask for.
My sense is that that happens less with gramps, unfortunately.
It actually happens a LOT with Gramps. The big ugly “under the hood” projects the developers take on are all about the needs of the users.
But the slim number of programmers keep getting buried by the changes from 3 major OS teams & the Python & GraphViz projects. And, for the first time in 20 years, a major GEDCOM evolution. Just treading water would be an accomplishment. They are actually making progress. For those of us watching the bug reports, dev channel & GitHub; it’s huge.
Converting to a DB API from Berkeley for version 5.0 wasn’t because they enjoy ripping the guts out… it was because the users needed fewer weird corruptions and because it removed barrier to other features… The Place hierarchy has been causing complaint for years. And the work towards eliminating pickled Blobs is the same. With those gone, it opens host of option for using a broad array of database utilities & exporters. The conversion to newer libraries is critical to keep Gramp compatible with new OS innovations. The switch to Weblate support drastically improves the Translation quality.
There have been a huge number of changes since 5.1.3 to help onboard new users. (Those won’t gain the kudos they deserve because people don’t notice that things that made them curse don’t hit them as often.) I still recall the efforts put in to clean up Custom types! Before the last major version, it was a real mess that caused loads of support traffic.
And bug reports are attacked vigorously.
The Discourse site has made these discussion MUCH better… we can eliminate those embarrassing typos & link to the answers in the wiki.
That’s not highlights… just stream of consciousness. I can’t even begin to cover all the ‘good stuff’ I’ve seen since getting involved with doing support & wiki edits. (Those aren’t ‘fun’ either.)
As others have pointed out, I think the Gramps developers have done a
good job of satisfying many reasonable requests and making improvements
that are good for everyone. I did take a look at pandoc and came away
with several conclusions as a former developer myself:
I have been using Gramps for over 15 years and have seen a lot of
progress in that time. I’m sure some of those changes would not have
occurred if a small number of developers were ONLY developing for
themselves without taking other users into account. But ALL software
projects are constrained by the number of developers available and the
amount of time they have available, and as far as I know, all of the
developers on Gramps are volunteers and will establish their own
priorities for the time they have available to work on Gramps. I would
hate to try to guess how many thousands of hours have gone into the
development of Gramps, and I am grateful for all of the work that has
been done.
For those and other reasons, I would consider it unreasonable to demand
any change to Gramps (or any open source project) unless I was in a
position to offer support for the development effort (that support could
come in the form of developing it myself, paying a developer to do it
for me, or just providing a detailed specification and design that could
be followed by a developer with little or no experience related to the
change). There is nothing wrong with suggesting a change or asking how
many others would be interested in such a change, but unless you are
paying for it or doing the development yourself, you should be willing
to accept it if the developers choose not to do it. I have made several
requests for changes to Gramps over the years with varying degrees of
success, but I am willing to accept the decision of the developers.
Some of the requests I have submitted with respect to web reports have
been implemented by the developers and others have not. I made a
request for a change to the census gramplet several years ago, but the
developer didn’t have time for it, so I implemented it myself and
submitted it to the developer and it was included in the gramplet (with
minor changes to meet coding standards). There is another minor change
(one or two lines of code) to the GUI that I suggested years ago and
would still like to see, but as far as I know, no developers were
interested in it and I haven’t pursued it. (I did modify my copy of
Gramps to implement it at one point, but I decided it wasn’t worth the
effort to continue doing so as new versions were released.)
I really suspect that Gramps is not really that much different than
other open source projects developed entirely by volunteers (projects
like Linux and LibreOffice that have sponsorship from corporations and
foundations are a different matter). In those cases where the
developers seem to be very responsive to user requests, I suspect it is
because the developer sees some personal benefit to making those fixes
and additions (I’ve never known a good developer who doesn’t want his or
her code to be as bug free as possible, even if the bug is something
that can be lived with). Also, on a small tightly-defined project, it is
less likely that users will make requests that are outside the scope of
the project or the expertise of the developer(s). I rarely get involved
in such discussions, but I do see lots of discussions on the Gramps
lists of features that I suspect most users would not care about and
that would require lots of research on the part of the developers before
they could attempt to implement them. Those are not going to spark the
interests of developers who have higher priority tasks for the time
available.
Attitudes like that are more likely to get you ignored by developers.
If you don’t like the way open source projects are developed, you can
always try to find a commercial project that gives you what you want,
but you will probably have to pay for it. If anything, open source is
the one big exception to the rule that you get what you pay for, because
there are very few open source projects that require any payment. I’ve
never found any endeavor where volunteers put up with demands and
criticism for very long, and except for very large projects useful to
corporations, nearly all open source projects are made up of volunteers.
That is a difference between Microsoft Windows users and long-time Unix
users. The Unix philosophy for many years was that tools should do one
thing very well, and that if you needed additional capability, you would
feed the output of one tool into another tool to perform another
function and it might be necessary to use several tools to accomplish
what was needed. In the days before GUIs, pipes and redirection of
standard input and standard output made this easy, and shell scripts
could automate the process if it needed to be done frequently. And most
developers consider it foolish to reinvent the wheel. So if there is a
tool that can convert an output of Gramps to an input for another
program, it would be foolish for the Gramps developers to expend the
effort to duplicate and maintain the functionality of that tool (unless
you can find a developer who is sufficiently bored that they would be
willing to do it).
That is not strange, as long as the attitude to new ideas and discussions is like we see it here…
You really need to stop the “fork it and do it yourself” mentality, and you also need to stop the “Since it wasn’t me that come with the idea, I will be negative to it” attitude.
And your atttitude “it is only this and will never be anything else” might be a big part of WHY there is a lack of devs.
Developers don’t care much about using time on a project that do not eveolve.
You are really starting to be boring.
If you don’t like how the gramps project evolve, learn python and develop you own module which really do what you want.
For me zotero is not the solution. When we’ll have a citation standard, we’ll develop one solution based on this standard. So be patient. All the citations managment used for the moment by gramps do 99.999 % of my needs.
But perhaps you doing something which is not related to the genealogy ?
What most people seem to not understand is that it’s a big difference between discussion and demanding, a discussion about a new enhanced feature can end up in a good solution for a new feature, but when the negativity against that new feature is the only answer, including standard answer like “fork and do it yourself”, two things happen, new users get scared and stop getting involved, and with that potentially new developers.
and a software that do not have interchangeability with other formats, will always be a niche software, and will not get new users as long as there is other better software out there.
The best way Gramps can get new developers is if there are features in Gramps that can be used by more than some genealogists using linux.
Gramps is a great software for a lot more than register some family relations, but to attract more advanced users that as well may have python experience, it need to provide features that make it a more versatile software. One of the areas where there is a lot of python experience is in humanity research, and by adding a few useful features that add interoperability in Gramps, i.e. support for interoperate with Reference Managers that most of the worlds research labs use, or a network graph format that provide an easy way to analyze data outside Gramps, will actually make Gramps software that can be used for a wide range of research projects.
It’s only a few days since a person starting with a humanity research doctoral dissertation asked me if Gramps could be used for that project, and I had to answer no, Gramps would have been perfect for that project, except for one major thing, and that was that there was no way to get the data out of gramps in any format needed, and there is no analyzing functionality in Gramps, and since there is no way to write queries directly against the database without a lot of python experience, there was no other options that recommend another software for that project.