Hello kku,
Thank you for your suggestion; it means a lot to me, and I really appreciate it!
I don’t think it would be right for me to waste your time:
The concept of witnesses is, I believe, relatively complex. There’s the bidirectional relationship (either at the event level or directly at the individual level), but also the concept of role (witness, declarant) and the related notes.
I thought I read that importing GEDCOM version 7 was planned; it should solve my problem, so there’s no need to do the work twice.
Yes, that posting was disconcerting. A subtle difference is that his point was about pursuing market share rather than growing the community. (And I immediately posted a differing viewpoint but focused on refreshing/deepening the community talent pool.)
But I can understand the OP’s point. No doubt he had had the same experience I’ve had in the tug-of-war between sales/marketing and engineering/support. Where sales and marketing insists on adding anything that is pretty, counters competitor bullet points, or is on the bleeding edge buzzword list. Whether that feature is useful, usable, works, or fits the architecture is irrelevant.
And because selling is their core skill (and money talks), they are better at pitching their ideas to the decision makers in the company.
I believe escaping that frustrating mindset may one of the main motivators of open source developers. And there is a kneejerk reaction to features whose primary purpose is to suck in masses of new users… who might overwhelm our volunteers with novice support load.
This is just not true. The “fork it and do it yourself” response is not a welcoming invitation—it’s a dismissal, especially when aimed at users who don’t code. It’s not encouragement; it’s a rhetorical shutdown. And it’s part of a broader cultural problem in certain open-source circles, where gatekeeping is disguised as empowerment.
Claiming that this phrase “may even be read as saying the concept is interesting” is disingenuous. If developers genuinely found the idea interesting, they’d engage with it—not deflect it with a phrase that implies “your input is irrelevant unless you become one of us.”
This kind of response doesn’t foster community—it fractures it. It sends a clear message: unless you speak our language (Python, Git, etc.), your ideas are second-class. That’s not collaboration. That’s exclusion.
And let’s be honest: the “we’re volunteers, be grateful” mentality is not a shield against critique. It’s a deflection. Volunteerism doesn’t exempt a project from accountability—especially when it invites public participation and feedback. If you ask for engagement, you don’t get to punish people for engaging.
I meant positive from to side of the person who wrote.
They are encouraging people to try something that gives them satisfaction. And many consider coding an artistic expression of creativity. The thought of helping someone find those feelings is alluring. And Python is nearly as accessible as BASIC. (Although the white space sensitivity is a pure bitch.)
Positivity is all about how you choose to interpret it. My interpretation is that people don’t respond if they don’t care. And I choose to believe people honestly want to help.
“Disconcerting”? I think you may have read in things that I didn’t say. My point is that this project has evolved to a certain point. By looking at who actually uses Gramps, perhaps we can develop a future strategy for continued success.
I think the anecdotal data suggests that few people choose Gramps as their first genealogy software. Most Gramps users have experienced limitations with other packages and find Gramps suits their needs better. Since developer resources are limited, if there is a choice, it seems reasonable to focus efforts on features that support actual users.
I’m not saying that we should try to make Gramps hard to use. Far from it. But we don’t have the resources to add all kinds of “wizards” and other training wheels that are solely for the benefit of brand new users. And many such “features” would get in the way for experienced users. (Microsoft Office, anyone?) Reality is that Gramps is never going to be easier to use than any of the commercial options. It is a fool’s game to chase that as a goal.
So let’s make Gramps even better for users frustrated with their current limited software. To me, that’s the healthy way to grow this community.
I don’t want to write a book-length posting but hopefully I’ve clarified things somewhat.
Still not true. “Fork it and do it yourself” is one of the most dismissive and rude phrases used in open source communities.
You might as well just say: “Get the f*** off with your comments and ideas—no one is interested.”
It’s especially toxic when directed at people outside the developer circle who are trying to contribute with ideas or feedback.
Instead of welcoming engagement, it sends a clear message: “Unless you code, your voice doesn’t matter.” That’s not encouragement. That’s exclusion wrapped in pseudo-positivity.
It’s a rhetorical move that, at its core, says: your idea isn’t welcome, and you should shut up and bow politely while leaving.
You defend rude behavior, that is all you do at this point…
I can see your point and agree to some extent. I was very frustrated after proposing an more proactive initial set of Dashboard gramplets with some tweaks.
It was suggested that I do the tweaks and submit them. And I’ve been stumbling along with occasional nudges from @Nick-Hall when I become too frustrated.
The beta What’s Next is to a point where its would really help new users. But I’m afraid its too inefficient in how it expands its scope. It could become a real pig. And I don’t know how to fix something that complex.
So I do grasp the frustration. But I also grasp the love behind the pushes.
You’re deflecting from the actual issue by romanticizing a phrase that’s widely recognized as toxic in open source communities. “Fork it and do it yourself” isn’t some poetic invitation to creative expression—it’s a rhetorical wall. Recasting it as encouragement ignores how it’s routinely used to shut down non-technical contributors and dismiss valid input.
This isn’t about love or artistic coding. It’s about how language is weaponized to exclude. And trying to reframe exclusion as “positivity” is not just misleading—it’s part of the problem.
The Gramps community always welcomes new volunteers and these people do not have to be programmers. We have the need for translators, documentation writers, forum and chat room moderators, website designers and people with a talent for artwork and creating icons.
I totally agree.
Please feel free to contribute on this forum. It is perfectly acceptable to discuss other products and tools and how they can be used in conjunction with Gramps to help with your family history research.
No. Please put forward ideas, suggestions and criticisms. This is how new features start.
I am reminded about how I was eventually convinced to write the hierarchical place structure. Rob Healey kept bringing up the idea on the mailing lists. He did some research and provided examples of how the feature could work. It takes time and some patience, but developers can be encouraged to write a new feature. The case for sub-events is now growing quite strong after @StoltHD has been promoting them for a long time. Perhaps this has now gained enough support to be implemented.
This attitude is a common problem in open source communities.
I encourage civilised discussion. Developers must try to remember that not everyone can code. Equally users must not pressure developers to write a feature for them.
The best way to encourage a developer to do some work for you is to contribute to the community.
If you can’t wait, then the Gramps addon system gives beginners a good place to start. Make a copy of a similar addon or core plugin and try modifying it. Some of our developers are willing to help and encourage new programmers.
@DavidMStraub has an experimental GEDCOM7 to Gramps XML service online and in testing. (see https://gramps-gedcom7.streamlit.app/) I don’t think it will resolve these witness records for 2 reasons:
it will expect witness roles to be recorded in the standard new tag, not a custom tag.
it is not nearly as fault tolerant as the Gramps GEDCOM 5.5.1 importer plugin. I tried the GEDCOM stress test file with both. The 5.5.1 simply logged the incompatible data and stored it as Note. The GEDCOM7 choked and complained that it was not compliant.
Getting back to the original thought of modifying the GEDCOM importer
changing the import failure Notes so they would be still parsable by other GEDCOM utilities. (The re-formatting means only humans and AIs can parse them now.)
changing the Tag and Source during import. I didn’t like that Tagging and citing lost the “last changed” timestamps during import. Could that be reset to the GEDCOM specified timestamp after importing each record? (Perhaps the Gramps object handle generator could be seeded from the record timestamp too? That might make repeatably identical imports compatible with the Gramps Tree comparison tools.) And the Source and Citation seemed like they could be more complete.
Obviously, I never got to that project. But the fork is ready. And Kari’s SuperTool scripts should give us a boost towards the Witness import feature.
There were a lot of reactions to my post. If it’s for the good of the community, all the better; otherwise, rest assured, I’m not worth it.
I learned programming over 40 years ago at school (assembly language under CP/M), then as a hobby and on my own, I had a lot of fun with: Basic under ZX80 (or 81, I can’t remember) Sinclair, Access, Visual Basic + MS SQL Server, PHP + MySQL (MVC), and finally Python (which I really enjoyed).
But it’s no longer fun for me, so “Fork it and do it yourself” → No more,thanks.!!
For over 10 years, I’ve been fine-tuning a stamp collection management program (multi-users in PHP + MySQL) . It has features (scraping, etc.) that no other software of its kind has; it’s a perfect fit for me,
but it couldn’t be used by anyone else because it’s hideous to look at, and I’d have trouble explaining how it works (it seems so natural to me, since it was designed by me and according to my own thought process).
I shudder to think how I’d react if someone told me it is ugly, that this or that needed changing…
but in writing, I’ll try to be at least somewhat polite.
I’m not in a hurry because I came to Gramps for two reasons:
a) My genealogy club needed a software solution (paid or free) that would allow multiple people to work simultaneously on a database of approximately 500,000 individuals, properly manage sources and witnesses, and not require a commercial platform (Geneanet, etc.).
I presented the pro & cons of each solution I found (actually two):
Gramps had, at first glance, the significant advantage of a synchronizable desktop and web interface.
But, it wasn’t chosen because of its interface and the loss of witnesses during GEDCOM import.
The other solution is currently being tested but requires a constant internet connection.
b) My personal need, essentially the same (but only for my family, so with a database of 39,000 individuals).
I have time because I still have hundreds of entries to clean up in my current software, and by transferring the database file, we can all play but not at the same time.
In approx. six months, I’ll see if what I’m waiting for Gramps (forms, GEDCOM 7 import, etc.) is available and makes Gramps acceptable for me and my family.
If not, it’s not a big deal; I’ll use my club’s solution.
My potential contribution to the community is truly limited.
Due to my background, I have no artistic or literary talent.
Programming no longer make me fun.
The only thing I was truly good at was finding software bugs (I was a beta tester for several free genealogy programs), but with Gramps, this wouldn’t make sense since I’m not sure how it works when OK
I don’t think open-source projects are doomed to remain elitist, even if they are limited to specific areas: for example, in 3D, just look at screenshots of Blender from only a few years ago.
I don’t know the context, the history, or the available resources, but reading the various comments, I’ve noticed a lot of disappointment, resignation, and exasperation (and few satisfaction for what is supposed to be a pleasure for most of the participants, I think).
At the risk of being controversial (if so, please delete this passage), I think this may be partly due to misunderstandings.
Would I suggest that the community clearly answer the following two points (based not on what it is now, but on what it should be):
a) Why Gramps?
Is it genealogy software? A tool for learning Python? Both (in which case, what is the priority)?
b) Who is Gramps for?
For all genealogists? For high-level, even professional, genealogists? For programmers?
There is no right or wrong answer, but please be clear with yourselves and others; this will avoid a lot of stress.